Slanje na 24 tisuće kontakata prestalo je biti rizik

Što je radilo prije

Izvorni sustav za outbound sastojao se od desetak Make.com scenarija povezanih preko Google tablica. Svaki scenarij obavljao je jedan korak: preuzimanje kontakta, dopunu podataka, pripremu poruke, slanje i upis rezultata. Sustav je radio i neko je vrijeme uspješno podržavao kampanju. Prototip je obavio svoj posao: dokazao je da postupak ima smisla i da se poruke mogu pripremati i slati bez ručnog rada.

Gdje je prestao rasti

S rastom baze pokazale su se granice takvog pristupa. Podaci su bili podijeljeni između scenarija i tablica, pa ni za jedan kontakt nije postojao potpun zapis svega što se dogodilo. Svaka izmjena zahtijevala je uređivanje više tokova rada, a jedna se promjena provjeravala kroz nekoliko različitih sučelja. Kvar je mogao proći nezapaženo. Ponašanje nastavnih poruka bilo je teško provjeriti, a podaci o slanju i isporuci nisu se dosljedno vraćali u zapis kontakta. Kada primatelj postavi pitanje na koje svaki pošiljatelj mora znati odgovoriti — zašto ste mi pisali, kada i na temelju kojih podataka — takav sustav nema odgovor.

Što je izgrađeno

Cijeli je proces preseljen u Python, jednu Airtable bazu i jedan raspored izvršavanja na jednom VPS-u. Airtable čuva stanje svakog od gotovo 24 tisuće kontakata: tvrtku, osobu, e-adresu, korak sekvence i bilješke u koje se redom upisuje sve što se dogodilo. Prije pripreme poruke sustav provjerava podatke o tvrtki i kontaktu, među ostalim i to pripada li e-adresa doista tvrtki kojoj je kontakt pripisan. Poruke se pripremaju iz tih provjerenih podataka, šalju se prema lokalnom radnom vremenu primatelja, a nastavne poruke — podsjetnik nakon šest dana i završna poruka nakon četrnaest — idu tek nakon potvrđene isporuke prethodnog koraka. Telegram javlja kvarove, šalje jutarnji sažetak prethodnog dana i omogućuje ručno pokretanje pojedine serije kada nema smisla čekati sljedeći termin.

Kako radi u praksi

Radnim danima sustav pripremi i pošalje između 200 i 500 poruka, bez nadzora. Otvaramo ga kada se dogodi incident, tijekom tjednog pregleda ili kada je ručno pokretanje brže od čekanja. Događaji isporuke vraćaju se u zapis kontakta, pa povijest u Airtableu zamjenjuje zasebnu nadzornu ploču.

STANJE SUSTAVA

KONTAKATA U AKTIVNOJ BAZI ....... ~24.000
PRIPREMLJENO I POSLANO DNEVNO ... 200 – 500
TRAJNO NEISPORUČENO ............. 0,7 %
RIJEŠENIH INCIDENATA ............ 8

Stope otvaranja i klikova pratimo, ali ih ne prikazujemo kao poslovni rezultat: dio tih događaja stvaraju automatski sigurnosni sustavi primatelja, pa nam služe isključivo kao dijagnostika isporuke.

Što nas je naučila produkcija

Sustav nije od prvog dana radio bez pogreške. Stabilan je postao kroz osam produkcijskih incidenata koji su otkriveni, objašnjeni i pretvoreni u pravila. Četiri su lekcije važne i izvan ovog projekta.

Prvo, pravila poput radnih dana moraju živjeti u kodu koji šalje poruke, ne samo u rasporedu pokretanja. Nastavne su se poruke jednom poslale u nedjelju jer je provjera radnog dana postojala samo u rasporedu; sada stoji na početku svake skripte koja šalje.

Drugo, podaci koji iz vanjskih servisa stižu u velikom broju moraju se obrađivati skupno. Sinkronizacija rezultata dohvaćala je događaje poruku po poruku i s porastom volumena počela je padati; prelazak na skupni dohvat smanjio je opterećenje približno deset puta i ti su kvarovi prestali.

Treće, potrošena kvota ili nevažeći pristupni podaci moraju odmah zaustaviti seriju i podići upozorenje. Jedne je večeri kvota vanjske usluge potrošena na polovici serije, dio kontakata ostao je bez pripremljene poruke, a problem se vidio tek sljedeće jutro. Danas se na prvi takav odgovor cijeli postupak zaustavlja i Telegram odmah javlja kvar.

Četvrto, podaci o kontaktu i tvrtki provjeravaju se prije pripreme ili slanja. Odgovor jednog primatelja potaknuo je provjeru koja je pokazala da je gotovo dva posto zapisa u bazi bilo pripisano pogrešnoj tvrtki; oko 450 potvrđeno pogrešnih zapisa uklonjeno je iz aktivnog procesa, a provjera podataka sada se izvodi prije pripreme svake poruke.

Što migracija pokazuje

Rezultat treba pošteno razdvojiti. Sustav pouzdano obrađuje navedeni volumen, kvaliteta isporuke je mjerljiva, a kvarovi više ne prolaze nezapaženo. To je učinak sustava. To, međutim, ne dokazuje da je hladni outbound prava prodajna strategija niti da poruke same po sebi donose prodaju — to se mjeri odgovorima i dogovorenim razgovorima, a ne radom infrastrukture.

Ono što migracija pokazuje jest razlika između prototipa i sustava koji se može voditi: jedno mjesto s važećim podacima, potpuna povijest po kontaktu, pravila zapisana u kodu koji ih provodi i kanal koji javi kvar prije nego što itko primijeti da se ništa ne događa. Ako Vaš outbound danas radi na sličnom skupu povezanih alata, granica najčešće nije u alatima, nego u trenutku kada više nitko ne može sa sigurnošću reći što je kome, kada i zašto poslano.

PythonAirtableBrevoGPT-4oPerplexity SonarcronTelegram