A system where you can see who has been reached, through which channel, and what comes next.

Nu, și motivul e tehnic, nu comercial. Sistemul nostru e croit pentru o singură echipă: nu are separare strictă a datelor între clienți și nu are un flux de instalare care să nu presupună acces la server. Ca să fie dat cuiva, ar trebui rescrise exact acele două lucruri. Îl arătăm din același motiv pentru care un tâmplar își arată atelierul — spune mai mult despre meserie decât o broșură. Ce vindem e construcția unui sistem pentru cum lucrezi tu.

De cele mai multe ori nu ar trebui, și ți-o spunem noi. Un instrument gata făcut e răspunsul corect când munca ta seamănă cu ipoteza pentru care a fost gândit. Construcția devine justificată în trei situații concrete: ai tipuri de organizații fundamental diferite care nu încap în același set de câmpuri; jumătate din atingeri vin din sisteme automate care trebuie să scrie singure în fișă; sau ai nevoie de reguli de trimitere pe care instrumentul nu ți le dă și pe care nu-ți permiți să le încalci. Dacă niciuna nu se aplică, îți spunem să cumperi.

Da. Avem scris și rulat conectorul pentru amoCRM — 12 funcții de server, cu fluxul OAuth, reîmprospătarea jetonului, aducerea leadurilor și verificarea stării — și pentru Bitrix24, cu OAuth și webhook. Pentru Zoho CRM avem parcursul OAuth documentat pe regiuni de centru de date. Iar când sursa reală de adevăr a echipei e o foaie de calcul, avem zece funcții pentru Google Sheets, de la citirea structurii foii până la import și actualizare de contacte.

Printr-un webhook semnat, trimis la sfârșitul apelului. Sistemul ia numărul de telefon și caută organizația printr-o funcție scrisă în bază pentru formatele în care apar numerele în date reale — nu printr-o comparație de șiruri, care ar rata jumătate din cazuri. Apelul se salvează cu transcript, rezumat, sentiment, adresa înregistrării și durată, legat de fișă, iar regula din cod poate urca leadul pe traseu în funcție de rezultatul apelului.

Prin șase mecanisme care se verifică unul pe altul, nu printr-o intenție bună: ore de trimitere, liste de excludere pe tip de instituție, deduplicare pe adresă scrisă cu litere mici, răcire de cinci zile pentru aceeași adresă, plafoane zilnice și per rulare, și un întrerupător care oprește orchestratorul fără cale de ocolire. Mai jos e cazul concret care ne-a învățat de ce deduplicarea trebuie făcută pe adresă, nu pe organizație.

Are trei trepte, toate protejate cu un jeton legat de destinatar. Dezabonarea într-un clic, direct din antetul emailului, conform RFC 8058. Un centru de preferințe, unde decizia se poate și anula. Și ștergerea completă, care scoate adresa din șase tabele și o adaugă pe o listă permanentă de blocare — astfel încât un import făcut peste șase luni să nu o readucă înapoi. Ultima parte e cea pe care majoritatea sistemelor o ratează.

Într-o bază PostgreSQL, pe infrastructura convenită la începutul proiectului, cu migrări versionate — adică fiecare schimbare de structură e un fișier, nu o intervenție manuală. Accesul e pe roluri distincte, cu un rol separat pentru agenții automați, pentru că un sistem care scrie în bază nu trebuie să aibă drepturile unui om. Nu există înregistrare deschisă și nu există suprafață publică.

Da, și tocmai dublurile sunt motivul pentru care importul e construit așa. Fișierul se procesează în flux, în loturi de 200 de rânduri, cu un index de deduplicare pe cod fiscal, email și telefon construit înainte de scriere, plus validarea adreselor: format, domenii de unică folosință, tipare invalide. Ce nu se potrivește nu se aruncă tăcut — se raportează, ca să decizi tu.

Nu. Putem garanta că vei ști cine a fost atins, prin ce canal, ce s-a spus și ce urmează — și că sistemul se oprește singur când ar trebui. Cifrele de rezultat depind de ofertă, de piață și de echipa care sună, adică de lucruri pe care nu le controlăm. Nu publicăm procente de îmbunătățire pe care nu le-am măsurat, nici pentru noi, nici pentru altcineva.