Expertiză · CRM și vânzări

Un sistem în care se vede cine a fost atins, prin ce canal și ce urmează.

Construim sistemul comercial al unei organizații: organizații și contacte, un traseu de stadii, canalele care aduc date singure — apel, email, formular, agent vocal — și frânele care opresc trimiterile înainte să devină o problemă. Nu vindem CRM-ul nostru; construim unul pentru cum lucrezi tu.

Discută un proiect

Construit dejaDouă implementări proprii, în producție, citate mai jos. (1) MEGA CRM — sistemul cu care echipa noastră își ține propria activitate comercială: `server.js` are 9.516 linii și 99 de rute HTTP, în depozit sunt 96 de migrări SQL și circa 95.000 de linii de TypeScript în interfață, iar ultimul commit e din 18 august 2026. (2) Conectorii de CRM din platforma Kallina: 12 funcții de server pentru amoCRM, 4 pentru Bitrix24, plus un flux OAuth documentat pentru Zoho CRM și 10 funcții pentru Google Sheets. Precizarea care contează: **MEGA CRM nu e de vânzare.** Îl arătăm ca dovadă de meserie, nu ca produs — nu are izolare strictă a datelor între clienți și nu are un flux de instalare care să nu presupună acces la server. Serviciul e „construim un sistem ca acesta pentru tine”, nu „îți dăm o licență la al nostru”.

Cele mai multe firme nu au o problemă de CRM, au o problemă de evidență: nu se știe cine a fost contactat, prin ce canal, ce s-a spus și ce urmează. Un instrument gata făcut rezolvă asta când munca ta seamănă cu munca pentru care a fost gândit instrumentul. Când nu seamănă — pentru că lucrezi cu administrații publice și cu firme private în același timp, sau pentru că jumătate din atingeri vin dintr-un agent vocal — ajungi să chinui instrumentul, iar echipa ține adevărul într-un fișier separat. Atunci merită construit ceva.

Sistemul pe care îl arătăm ca dovadă e cel cu care lucrăm noi. E structurat pe proiecte separate, fiecare cu tipul lui de organizație și cu schema lui de câmpuri, ca aceeași aplicație să funcționeze și pentru o primărie, și pentru o firmă privată, fără coloane noi în bază la fiecare tip nou. Sub organizație stau contactele, deasupra stau campaniile. Un lead urcă printr-un traseu de șapte stadii, de la „necontactat” până la „contract semnat”, și poate fi atins prin nouă canale diferite, de la apelul agentului vocal până la vizită.

Partea grea, și cea care se învață pe pielea proprie, nu e trimiterea. E oprirea. Sistemul are ore de lucru scrise în cod, liste de excludere, deduplicare pe adresa scrisă cu litere mici — nu pe organizație —, o perioadă de răcire între campanii, un plafon zilnic împărțit între campanii și un întrerupător care refuză să pornească orchestratorul, fără cale de ocolire. Fiecare dintre ele a fost adăugat după ce a lipsit o dată. Le enumerăm nu ca listă de funcții, ci ca listă de lecții.

Al doilea lucru pe care îl construim aproape de fiecare dată e alimentarea automată. Un CRM în care datele se scriu cu mâna se golește în trei săptămâni. La noi, apelul agentului vocal se scrie singur pe fișa organizației, cu transcript și rezumat, și mută leadul mai departe pe traseu dacă rezultatul apelului o justifică. Răspunsurile la emailuri se culeg din cutia poștală la fiecare zece minute și se leagă de trimiterea care le-a provocat. Deschiderile și clicurile se urmăresc separat. Omul intervine ca să decidă, nu ca să introducă date.

Prevenirea spamului în CRM — cererile care merită urmărite · video în română, cu subtitrare și transcriere

Transcrierea completă

Salutare! În analiza de astăzi disecăm o problemă pe care absolut orice afacere care vrea să scaleze ajunge să o întâlnească la un momentat. Cum exact automatizăm prospectarea comercială fără ca totul să se transforme bine într-un spam enervant și agresiv? Vrem să creștem, vrem să eficientizăm, clar. Dar astăzi ne uităm sub capota unui material tehnic fascinant ca să vedem cum se previne spam-ul prin exact 6 mecanisme clare, inelare, integrate într-un sistem ceremic cu adevărat sigur. Nu e vorba doar de setările standard pe care le bifăm și uităm de ele, ci de arhitecturi reale, fapte și cifre. Haide să intrăm în date! Bun, pe scurt, iată structura discuției noastre. Începem cu problema accelerației fără frâne, apoi analizăm un studiu de caz, incidentul celor 42 de mesaje, trecem la nucleul analizei, adică cele 6 mecanisme de protecție, vorbim despre gestionarea corectă a dezabonărilor și încheiem cu dilema clasică, când e cazul să construim un sistem și când e mai bine să-l cumpărăm. Să începem! Deci, întrebarea esențială cu care pornim la drum este asta. Cum ne asigurăm că automatizarea pe care o implementăm nu devine pur și simplu spam? E o linie incredibil de fin aici. Intenția din spate e mereu bună, vrem să contactăm oameni, să generăm vânzări, dar, dacă sistemul e lăsat să accelereze orbește, fără niște verificări tehnice foarte stricte codate direct în structura sa, impactul asupra brand-ului poate fi dezastros. Ajungem la secțiunea 1, accelerație fără frâne. Să ne uităm la problema fundamentală a evidenței în aceste sisteme automate. Gândiți-vă la asta ca la o mașină foarte puternică, dar fără un sistem de frânare. Când un soft standard nu se alinează cu realitatea zilnică a muncii, lucrurile o iau razna rapid. De exemplu, să zicem că echipa interacționează și cu administrații publice, dar și cu firme private. Structuri de decizie complet opuse, nu? Datele lor pur și simplu nu încap în aceleași câmpuri rigide dintr-un CRM generic. Și ce se întâmplă în practică? Oamenii încep să țină adevărul separat, prin fișiere Excel sau notițe pe birou, în timp ce automatizarea principală continuă să ruleze în gol pe date greșite. Asta înseamnă pur și simplu haos. Și sursa noastră are un citat absolut genial aici, un adevăr brutal din industrie. Un CRM în care datele se scriu cu mâna se golește în 3 săptămâni. E foarte logic. Oamenii obosesc, apare rori, iar moralul scade. Oamenii de vânzări trebuie să construiască relații, nu să fie roboți de introdus date. Fie că vorba de un agent vocal inteligent care transcriu automat apelurile, sau e-mail-uri care se sincronizează singure în fundal la fiecare 10 minute, ideea e clară. Alimentarea automată a datelor nu mai e un lux. E fundația obligatorie a oricăi sistem funcțional. Trecem la secțiunea a doua, incidentul celor 42 de mesaje. Haideți să disecăm anatomia unui eșec real. 42. Nu e doar un număr oarecare, ci o poveste reală dintr-o campanie de prospectare care a declanșat o adevărată reformă tehnică. Vă dați seama? O singură cutie poștală a primit fix 42 de mesaje în decurs de câteva ore, în aceiași zi. Evident, echipa tehnică s-a gândit prima oară, ok, e un bug, o banală buclă în cod care trimite la nesfârșit. Dar când s-a uitat mai atent în baza de date, realitatea era mult mai complexă de atât. Explicația? Sistemul fusese setat să extragă și să trimită mesaje per organizație, nu per adresă de e-mail. Așadar, din punctul de vedere logic, algoritmul își făcuse treaba perfect. Găsise 42 de firme distincte juridic. Problema, și e o realitate pe care o vedem des în piața locală, era că toate aceste 42 de entități foloseau exact aceeași adresă de e-mail. Fie că era a firmei mamă, fie a celuiași contabil extern care administra zeci de firme. Entitățile erau unice pe hârtie, dar destinația finală a mesajului era una singură. Și ca să punem lucrurile în perspectivă, știți câți oameni reali, în carne și oase, au fost afectați de avalanșa asta de mesaje? Doar 11. 11 persoane care administrau aceste zeci de afaceri. Acest incident a dovedit un lucru foarte clar. Intențiile bune și un cod care pare corect la prima vedere nu sunt niciodată suficiente. Baza de date are mereu asocieri invizibile, iar sistemul trebuie să le anticipeze. Ceea ce ne aduce la partea cea mai importantă, secțiunea a 3-a. Cele șase mecanisme de protecție, adică frânele codate direct în inima sistemului. Aici e soluția. Sursa detaliază un inel de protecție format din șase mecanisme distincte care se verifică unele pe altele. 1. Setarea unor ore de lucru stricte, între 8 și 18. Nimeni nu vrea un e-mail de vânzări duminica la ora 3 dimineața. 2. Liste de excludere permanente, adică blocarea instituțiilor sensibile, precum școlile sau ambasadele. 3. Și asta ar fi prevenit incidentul de mai devreme, deduplicarea obligatorie pe adresa de e-mail transformată în litere mici, nu pe numele companiei. 4. O perioadă de răcire de 5 zile pentru orice adresă contactată, ca să evităm sufocarea audienței. 5. Plafoane zilnice rigide pentru a nu supăra filtrele globale anti-spam. Și, în sfârșit, al șaselea mecanism, butonul de panică. Dintre toate, acest mecanism șase, adică kill switch-ul, sau întrerupătorul de urgență, este o piesă de rezistență. A fost implementat exact după acel incident cu cele 42 de mesaje. Ce este el de fapt? O variabilă simplă care, dacă e activată, pur și simplu interzice sistemului central să mai pornescă. Fără excepții, fără vreo comandă ascunsă de suprascriere în cod. Orice arhitectură serioasă de automatizare are nevoie de un astfel de buton fizic, figurat vorbind, pe care absolut oricine din management să poată apăsa fără să aibă cunoștință de programare. Mergem la secțiunea a patrea, gestionarea corectă a dezabonărilor. Pentru că, atenție, înseamnă mult mai mult decât un simplu link pus la finalul paginii. Odată ce ai trimis mesajul, dacă omul vrea să iasă din bază, procesul trebuie să fie ireproșabil și blindat. Analiza ne arată un proces solid în trei trepte. Pasul 1. Dezabonarea din Antet cu un singur click, care fie conform noilor standarde globale, cum este RFC 8058. Pasul 2. Un centru de preferințe vizual, unde omul poate alege ce tip de mesaj nu mai vrea. Dar pasul 3 e, de fapt, cel mai critic și cel la care multe sisteme dau greși. Ștergerea completă. Asta nu înseamnă să pui o bifă cu inactiv. Înseamnă ștergerea adresei din, atenție, 6 tabele diferite de bază de date, plus trecerea ei pe o listă neagră permanentă. Doar așa te asiguri că acea adresă nu reapare ca prin magie la următorul import masiv de date. Și nu vorbim doar de tehnologie. Vorbim de respect și conformitate legale direct în subsolul e-mail-ului. Cine sunteți? Cine este ofițărul DPO? Care e temeiul legal exact în baza căruia ați trimis mesajul? Și mai ales, din ce registru public ați extras datele inițial? Sursa noastră sublinează o regulă de aur. Aceste temeiuri trebuie reverificate la fiecare modificare legislativă. De ce? Pentru că poți să ai tu cel mai scump sistem din lume. Dacă pe bază a unei legi abrogate ai transformat tehnologia într-un risc financiar major pentru companie. Ajungem la ultima secțiune, a cincea. Când construiești vs. când cumperi? Haideți să vedem răspunsul corect pentru o infrastructură comercială matură. Documentația abordează această decizie extrem de obiectiv. Un CRM gata făcut, la cheie, este absolut ideal. Cu o singură condiție majoră. Ca fluxul vostru de lucru să se muleze perfect pe logica gândită de creatorii platforme. Însă, decizia de a construi o soluție personalizată devine singura cale în trei situații clare. Când interacționați cu tipuri foarte diferite de organizații, când aveți un volum masiv de automatizări în care munca manuală devine imposibilă și, cel mai important, când aveți reguli de protecție stricte, precum acele șase mecanisme pe care un soft de pe raft pur și simplu nu vi le poate garanta la un nivel atât de profund. Vestea bună? A construi ceva sigur în spate nu înseamnă să aruncați pe fereastră uneltele pe care echipa deja le știe. Aceste mecanisme de protecție pot rula silențios ca un strat invizibil de siguranță, în timp ce se conectează la interfețele obișnuite. Există arhitecturi demonstrabile care au conectori ce rulează zeci de funcții bidirecționale cu sisteme populare precum Amos ERM, Bitrix24, Zohos ERM sau chiar clasicele tabele Google Sheets. Pe scurt, nucleul de securitate rămâne intact, dar experiența utilizatorului e la fel de prietenoasă. Și astfel, materialul ne lasă o temă de reflexie destul de incomodă pe care merită să o luăm cu noi. Un sistem comercial super avansat pe care doar programatorul care l-a scris mai știe cum să-l oprească este el oare un super activ pentru companie sau de fapt un risc inacceptabil? La finalul zilei, transparența, acel întrerupător de urgență pus la vedere și documentația clară sunt lucrurile care diferențiază o simplă mașinărie oarbă de un sistem de afaceri cu adevărat scalabil, profesionist și responsabil. Sper că această disecție a mecanismelor a dus un pic mai multă lumină asupra felului în care ar trebui să arate o automatizare corectă. Pe curând!

Ce cuprinde

Lucrarea, pe componente

Datele intră în flux, cu deduplicare pe trei chei

Un fișier de până la 50 MB se încarcă și se procesează în flux, în loturi de 200 de rânduri, ca să nu depășească termenul de execuție al bazei, iar progresul se întoarce în timp real, câte o linie pentru fiecare pas. Înainte de import se construiește un index de deduplicare pe trei chei — codul fiscal, adresa de email și telefonul — și se validează adresele: format, domenii de unică folosință, tipare invalide. Aceeași organizație nu intră de două ori sub două denumiri scrise diferit.

Fiecare atingere se scrie pe fișa organizației

Nouă canale de comunicare, de la agentul vocal și apelul uman până la vizită, și un traseu de șapte stadii cu etichete reale: necontactat, contactat, răspuns primit, ofertă trimisă, interesat activ, negociere, contract semnat. Fiecare stadiu are scris lângă el ce procent ar trebui să treacă mai departe — nu ca promisiune, ci ca reper pentru cel care se uită la pâlnie și vrea să știe unde se pierde.

Apelul agentului vocal mută leadul singur

Când agentul termină un apel, rezultatul intră în sistem printr-un webhook a cărui semnătură se verifică: transcript, rezumat, sentiment, adresa înregistrării, durata. Organizația se identifică după numărul de telefon, printr-o funcție scrisă în bază pentru formatele în care apar numerele în date reale, iar apelul se leagă de fișa ei. Dacă rezultatul e „interesat” sau „întâlnire programată”, leadul urcă automat pe traseu și îi este actualizată data ultimului contact.

Trimiterea are frâne, nu doar accelerație

Ore de lucru scrise în cod: 08:00–18:00, fus orar Chișinău, luni până sâmbătă. Liste de excludere pentru școli, licee, grădinițe, ambasade și consulate. Deduplicare pe adresa scrisă cu litere mici — nu pe organizație, distincție care contează enorm când mai multe firme folosesc aceeași cutie poștală. Răcire de cinci zile între campanii pentru aceeași adresă. Plafon zilnic global, împărțit proporțional între campanii, plus un plafon per rulare, ca trimiterile să fie împrăștiate pe mai multe ore, nu în bloc.

Un întrerupător care nu se poate ocoli

Orchestratorul de campanii verifică o variabilă de mediu înainte de orice altceva. Dacă e pusă, refuză să pornească și iese — nu există argument de linie de comandă care să treacă peste, nu există „forțează”. A fost adăugat pe 1 mai 2026, după un incident de trimiteri duplicate. Un sistem care trimite în numele tău are nevoie de o oprire pe care o poate apăsa cineva care nu e programator.

Dezabonare într-un singur clic, în trei trepte

Prima treaptă e antetul standard de dezabonare într-un clic, conform RFC 8058 — cerința pe care furnizorii mari de email o impun pentru trimiteri în volum. A doua e un centru de preferințe, unde dezabonarea se poate și anula. A treia e ștergerea completă la cerere, care șterge adresa din șase tabele, o adaugă pe o listă permanentă de blocare și lasă o urmă în jurnal. Toate trei sunt protejate cu un jeton legat de destinatar, ca nimeni să nu poată dezabona pe altcineva.

Răspunsurile și reacțiile se culeg singure

Răspunsurile la emailuri se citesc din cutia poștală prin Microsoft Graph, la fiecare zece minute, și se leagă automat de trimiterea care le-a provocat. Starea livrării se sincronizează de la furnizorul de trimitere. Deschiderile se urmăresc cu pixel, clicurile prin redirect, iar panourile de livrabilitate arată domeniile cu probleme. Un serviciu separat urmărește creditul rămas la furnizorii plătiți și dă alertă înainte să se termine — nu după.

Căutare după ce face o organizație, nu doar după cum se numește

Pe lângă căutarea în text integral, întrebarea se transformă într-un vector cu un model de înglobare și potrivirea se face în bază printr-o funcție proprie, cu prag de similaritate reglabil (implicit 0,25) și cu limitare pe proiect. Practic: „firme care fac transport frigorific” găsește și organizații care nu au niciunul din cuvintele acelea în denumire.

Conectare la CRM-ul pe care îl ai deja

Dacă echipa ta lucrează deja într-un CRM, nu îl înlocuim din reflex. Avem scris și rulat conectorul pentru amoCRM — 12 funcții de server, inclusiv fluxul OAuth complet, reîmprospătarea jetonului și verificarea stării — plus Bitrix24 cu OAuth și webhook, un ghid OAuth pentru Zoho și zece funcții pentru Google Sheets, de la citirea structurii unei foi până la importul de contacte.

Cum arată

Traseul, pas cu pas.

Întâi modelul, apoi interfața

Ce e o organizație la tine, ce e un contact, ce e o oportunitate, ce câmpuri sunt obligatorii și care sunt doar utile. Discuția asta pare lentă și e singura care nu se poate recupera mai târziu: un model greșit se plătește la fiecare raport pe care îl ceri după aceea.

Traseul și stadiile, scrise ca reguli, nu ca obicei

Stadiile prin care trece un lead, ce le mută mai departe și ce le mută înapoi, cine e responsabil în fiecare. Scriem și regulile automate — ce rezultat de apel urcă leadul, ce inactivitate îl coboară — pentru că un traseu care se mișcă doar când cineva își aduce aminte să apese nu e un traseu, e o listă.

Canalele care aduc date singure

Apelurile din telefonie sau de la agentul vocal, răspunsurile din cutia poștală, formularele de pe site, webhookurile din alte sisteme. Fiecare canal se conectează și se testează separat, iar pentru fiecare stabilim ce se întâmplă cu datele care nu se potrivesc cu nimic din bază — pentru că acelea sunt cele care se pierd tăcut.

Frânele înainte de accelerație

Ore de trimitere, liste de excludere, deduplicare, răcire, plafoane, dezabonare, oprire de urgență. Le punem înainte de prima campanie, nu după prima reclamație. E partea în care experiența noastră costă cel mai puțin și valorează cel mai mult, pentru că e făcută din greșeli deja plătite.

Predarea: proceduri, roluri, documentație

Cine are ce rol, cum se adaugă un om, cum se oprește o campanie, unde se uită când ceva nu a plecat, ce se face la o cerere de ștergere. Un sistem comercial pe care doar constructorul știe să-l oprească e un risc, nu un activ.

Canalele care converg spre aceeași fișă: apelul agentului vocal, apelul uman, emailul și răspunsul din cutia poștală, formularul de pe site, webhookul din alt sistem — și frânele care decid ce pleacă înapoi.

Datele

Ce atingem, unde stau și cât rămân

Întrebările pe care le pune oricine are un responsabil cu protecția datelor — puse aici înainte să le pună el.

Unde stau datele și cum sunt structurate: PostgreSQL prin Supabase, cu 96 de migrări versionate. Structura e ierarhică: proiecte, sub ele organizații cu câmpuri flexibile în JSONB și vector de căutare în text integral, sub ele contacte, iar campaniile atârnă de proiect. Fiecare proiect își definește propria schemă de câmpuri — de aceea aceeași aplicație ține și administrații publice, și companii private, fără să crească baza la fiecare tip nou de organizație.
Ce scrie în subsolul fiecărui email trimis: Identitatea completă a firmei — denumire, cod fiscal, sediu înregistrat — adresa responsabilului cu protecția datelor, temeiul legal invocat și de unde provine adresa: registre publice și profiluri publice, spus explicit, nu subînțeles. Plus dezabonare într-un clic și o variantă de rezervă, cu răspuns într-un cuvânt. Ce ține de temeiul legal se reverifică la fiecare schimbare de lege — o trimitere în masă care citează un temei depășit e o problemă chiar dacă restul e impecabil.
Cine ce vede: Accesul e prin autentificare, rutele aplicației sunt închise în spatele unei porți, iar zona de administrare are o poartă în plus. Rolurile sunt separate: administrare, proprietar, vânzări, prospectare și un rol distinct pentru agentul automat — pentru că un agent care scrie în sistem nu trebuie să aibă drepturile unui om. Nu există înregistrare deschisă.
Ce verificăm explicit la instalare: Că fiecare secret e efectiv setat pe server: secretul cu care se semnează webhookurile care intră și secretul cu care se semnează jetoanele de dezabonare. Sunt verificări care par formale până când nu sunt: o verificare de semnătură nu are ce compara dacă secretul lipsește, iar un jeton previzibil e un jeton care nu protejează pe nimeni. Le trecem pe lista de predare, nu în presupuneri.
Ce se șterge la cerere și ce rămâne: Ștergerea completă scoate adresa din șase tabele și o pune pe o listă permanentă de blocare, astfel încât un import ulterior să nu o readucă. Rămâne o urmă în jurnal, cu motivul — pentru că trebuie să poți demonstra, peste un an, că cererea a fost onorată. Agregatele statistice, care nu identifică pe nimeni, rămân și ele.

Un caz

O adresă a primit 42 de emailuri într-o zi. Nu era o buclă.

Situația

Într-o campanie de prospectare pe organizații, o singură cutie poștală a primit 42 de mesaje în aceeași zi. Prima ipoteză, cea comodă, e o buclă în cod. Nu era.

Ce am construit

Extragerea destinatarilor era făcută per organizație, nu per adresă. Patruzeci și două de organizații foloseau aceeași cutie poștală — situație absolut obișnuită în mediul de afaceri local, unde un contabil, o firmă-mamă sau un administrator deservesc mai multe entități. Fiecare organizație era, corect, un destinatar unic; adresa nu era. Numărul total de persoane afectate în acel incident a fost 11. Reparația a fost în trei părți, nu în una: deduplicarea s-a mutat pe adresa scrisă cu litere mici, s-a introdus o răcire de cinci zile între campanii pentru aceeași adresă, iar toate scripturile de trimitere au fost obligate să treacă printr-un modul comun de protecție — cel care refuză să înregistreze o trimitere fără identificatorul campaniei. În aceeași zi a fost adăugat și întrerupătorul care oprește complet orchestratorul, fără cale de ocolire.

Ce a ieșit

Astăzi, deduplicarea pe adresă, lista de dezabonări, filtrele de domeniu și răcirea de cinci zile sunt garanții ale modulului comun, nu obiceiuri ale scriptului care se întâmplă să ruleze. Un script manual scris în grabă nu mai poate ocoli protecțiile, pentru că nu mai are voie să trimită singur.

Ce nu spune cazul

Lecția nu se transferă automat: fiecare bază de date are propria formă de duplicat. La una e adresa de email, la alta e numărul de telefon al unui grup de firme, la a treia e o persoană cu două funcții. Primul lucru pe care îl facem la un import nou e să căutăm care e forma de duplicat acolo — nu presupunem că e aceeași.

Întrebări

Ce ne întreabă oamenii înainte să sune

Îmi vindeți CRM-ul cu care lucrați voi?

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 ce aș construi, în loc să cumpăr un CRM gata făcut?

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.

Puteți lega sistemul de CRM-ul pe care îl folosim deja?

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.

Cum ajung apelurile în CRM, concret?

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.

Cum vă asigurați că nu ajungem să trimitem spam?

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.

Ce se întâmplă când cineva cere să nu mai fie contactat?

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ă.

Unde stau datele și cine le poate vedea?

Î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ă.

Puteți importa baza noastră veche, cu tot cu dubluri?

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.

Îmi garantați o creștere a vânzărilor?

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.

Pe ce se sprijină afirmațiile de mai sus (24 surse)

24 dintre ele sunt cod și fișiere din depozitele noastre. Nu le publicăm numele și nici linia: împreună, pe o singură pagină, ar descrie prea exact cum sunt construite sisteme care nu sunt doar ale noastre. Le parcurgem cu tine, în depozit, la cerere — verificarea rămâne posibilă, doar că se face într-o discuție.

Cum lucrăm Toate serviciile

Ce ai vrea să funcționeze mai bine?

Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.

Hai să discutăm