Competenza · CRM e vendite

Un sistema in cui si vede chi è stato raggiunto, attraverso quale canale e cosa segue.

Costruiamo il sistema commerciale di un'organizzazione: organizzazioni e contatti, un percorso di stadi, i canali che portano dati da soli — chiamata, email, modulo, voice agent — e i freni che bloccano gli invii prima che diventino un problema. Non vendiamo il nostro CRM; ne costruiamo uno per il modo in cui lavori tu.

Parliamo di un progetto

Già costruitoDouă 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”.

La maggior parte delle aziende non ha un problema di CRM, ha un problema di registrazione: non si sa chi è stato contattato, tramite quale canale, cosa è stato detto e cosa segue. Uno strumento pronto risolve questo quando il suo lavoro somiglia al lavoro per cui lo strumento è stato pensato. Quando non somiglia — perché lavorate con amministrazioni pubbliche e con aziende private allo stesso tempo, o perché metà dei contatti arriva da un voice agent — finite per forzare lo strumento, e il team tiene la verità in un file separato. Allora vale la pena costruire qualcosa.

Il sistema che mostriamo come prova è quello con cui lavoriamo noi. È strutturato su progetti separati, ciascuno con il suo tipo di organizzazione e con il suo schema di campi, così la stessa applicazione funziona sia per un municipio, sia per un'azienda privata, senza nuove colonne nel database a ogni nuovo tipo. Sotto l'organizzazione stanno i contatti, sopra stanno le campagne. Un lead sale lungo un percorso di sette stadi, da «non contattato» fino a «contratto firmato», e può essere raggiunto tramite nove canali diversi, dalla chiamata del voice agent fino alla visita.

La parte difficile, e quella che si impara sulla propria pelle, non è l'invio. È l'arresto. Il sistema ha orari di lavoro scritti nel codice, liste di esclusione, deduplicazione sull'indirizzo scritto in minuscolo — non sull'organizzazione —, un periodo di raffreddamento tra campagne, un tetto giornaliero ripartito tra le campagne e un interruttore che rifiuta di avviare l'orchestrator, senza possibilità di aggiramento. Ognuno di questi è stato aggiunto dopo che una volta è mancato. Li elenchiamo non come lista di funzioni, ma come lista di lezioni.

La seconda cosa che costruiamo quasi ogni volta è l'alimentazione automatica. Un CRM in cui i dati vengono scritti a mano si svuota in tre settimane. Da noi, la chiamata del voice agent si scrive da sola sulla scheda dell'organizzazione, con transcript e riepilogo, e sposta il lead più avanti nel percorso se l'esito della chiamata lo giustifica. Le risposte alle email vengono raccolte dalla casella di posta ogni dieci minuti e collegate all'invio che le ha provocate. Le aperture e i clic vengono tracciati separatamente. L'uomo interviene per decidere, non per inserire dati.

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!

Cosa comprende

Il lavoro, per componenti

I dati entrano nel flusso, con deduplicazione su tre chiavi

Un file fino a 50 MB viene caricato e processato in flusso, in batch da 200 righe, così da non superare il timeout del database, e l'avanzamento viene restituito in tempo reale, una riga per ogni passaggio. Prima dell'importazione viene costruito un indice di deduplicazione su tre chiavi — codice fiscale, indirizzo email e telefono — e vengono validati gli indirizzi: formato, domini usa e getta, pattern non validi. La stessa organizzazione non entra due volte con due denominazioni scritte in modo diverso.

Ogni contatto viene scritto sulla scheda dell'organizzazione

Nove canali di comunicazione, dal voice agent e dalla chiamata umana fino alla visita, e un percorso di sette stadi con etichette reali: non contattato, contattato, risposta ricevuta, offerta inviata, interessato attivo, negoziazione, contratto firmato. Accanto a ogni stadio è scritto quale percentuale dovrebbe passare oltre — non come promessa, ma come riferimento per chi guarda il funnel e vuole sapere dove si perde.

La chiamata del voice agent sposta il lead da sola

Quando l'agent termina una chiamata, il risultato entra nel sistema tramite un webhook la cui firma viene verificata: transcript, riepilogo, sentiment, indirizzo della registrazione, durata. L'organizzazione viene identificata tramite il numero di telefono, attraverso una funzione scritta nel database per i formati in cui i numeri compaiono nei dati reali, e la chiamata viene collegata alla sua scheda. Se l'esito è «interessato» o «incontro programmato», il lead sale automaticamente nel percorso e gli viene aggiornata la data dell'ultimo contatto.

L'invio ha freni, non solo accelerazione

Orari di lavoro scritti nel codice: 08:00–18:00, fuso orario Chisinau, da lunedì a sabato. Liste di esclusione per scuole, licei, asili, ambasciate e consolati. Deduplicazione sull'indirizzo scritto in minuscolo — non sull'organizzazione, distinzione che conta enormemente quando più aziende usano la stessa casella postale. Raffreddamento di cinque giorni tra campagne per lo stesso indirizzo. Tetto giornaliero globale, ripartito proporzionalmente tra le campagne, più un tetto per esecuzione, così gli invii si distribuiscono su più ore, non in blocco.

Un interruttore che non si può aggirare

L'orchestrator delle campagne verifica una variabile d'ambiente prima di ogni altra cosa. Se è impostata, rifiuta di avviarsi ed esce — non esiste argomento da riga di comando che possa bypassarlo, non esiste «forza». È stato aggiunto il 1 maggio 2026, dopo un incidente di invii duplicati. Un sistema che invia al tuo posto ha bisogno di un arresto che possa premere qualcuno che non è programmatore.

Disiscrizione in un solo clic, in tre fasi

La prima fase è l'intestazione standard di disiscrizione in un clic, conforme a RFC 8058 — il requisito imposto dai grandi provider di email per gli invii in volume. La seconda è un centro preferenze, dove la disiscrizione può anche essere annullata. La terza è la cancellazione completa su richiesta, che elimina l'indirizzo da sei tabelle, lo aggiunge a una lista permanente di blocco e lascia una traccia nel registro. Tutte e tre sono protette con un token legato al destinatario, così nessuno può disiscrivere qualcun altro.

Le risposte e le reazioni vengono raccolte da sole

Le risposte alle email vengono lette dalla casella postale tramite Microsoft Graph, ogni dieci minuti, e collegate automaticamente all’invio che le ha generate. Lo stato della consegna viene sincronizzato dal fornitore di invio. Le aperture sono tracciate con pixel, i clic tramite redirect, mentre i pannelli di deliverability mostrano i domini con problemi. Un servizio separato monitora il credito residuo presso i fornitori a pagamento e invia un avviso prima che finisca — non dopo.

Ricerca per ciò che fa un’organizzazione, non solo per come si chiama

Oltre alla ricerca nel testo completo, la domanda viene trasformata in un vettore con un modello di embedding e la corrispondenza viene eseguita nel database tramite una funzione proprietaria, con soglia di similarità regolabile (predefinita 0,25) e con limitazione per progetto. In pratica: «aziende che fanno trasporto refrigerato» trova anche organizzazioni che non hanno nessuna di quelle parole nella denominazione.

Collegamento al CRM di cui disponete già

Se il Suo team lavora già in un CRM, non lo sostituiamo per riflesso. Abbiamo scritto ed eseguito il connettore per amoCRM — 12 funzioni server, incluso il flusso OAuth completo, il refresh del token e la verifica dello stato — più Bitrix24 con OAuth e webhook, una guida OAuth per Zoho e dieci funzioni per Google Sheets, dalla lettura della struttura di un foglio fino all’importazione dei contatti.

Come si presenta

Il percorso, passo dopo passo.

Prima il modello, poi l’interfaccia

Che cos’è per Lei un’organizzazione, che cos’è un contatto, che cos’è un’opportunità, quali campi sono obbligatori e quali sono solo utili. Questa discussione sembra lenta ed è l’unica che non si può recuperare più tardi: un modello sbagliato si paga in ogni report che chiede in seguito.

Il percorso e gli stadi, scritti come regole, non come abitudine

Gli stadi attraverso cui passa un lead, cosa lo fa avanzare e cosa lo fa tornare indietro, chi è responsabile in ciascuno. Scriviamo anche le regole automatiche — quale esito di chiamata fa salire il lead, quale inattività lo fa scendere — perché un percorso che si muove solo quando qualcuno si ricorda di premere non è un percorso, è un elenco.

I canali che portano i dati da soli

Le chiamate dalla telefonia o dall’agente vocale, le risposte dalla casella postale, i moduli dal sito, i webhook da altri sistemi. Ogni canale viene connesso e testato separatamente, e per ciascuno stabiliamo cosa accade con i dati che non corrispondono a nulla nel database — perché quelli sono quelli che si perdono in silenzio.

I freni prima dell’accelerazione

Orari di invio, liste di esclusione, deduplicazione, raffreddamento, limiti, disiscrizione, arresto di emergenza. Li inseriamo prima della prima campagna, non dopo il primo reclamo. È la parte in cui la nostra esperienza costa meno e vale di più, perché è fatta di errori già pagati.

Consegna: procedure, ruoli, documentazione

Chi ha quale ruolo, come si aggiunge una persona, come si interrompe una campagna, dove guardare quando qualcosa non è partito, cosa fare in caso di richiesta di cancellazione. Un sistema commerciale che solo il costruttore sa fermare è un rischio, non un asset.

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.

I dati

Cosa tocchiamo, dove risiedono e quanto rimangono

Le domande che pone chiunque abbia un responsabile della protezione dei dati — poste qui prima che le ponga lui.

Dove risiedono i dati e come sono strutturati: PostgreSQL tramite Supabase, con 96 migrazioni versionate. La struttura è gerarchica: progetti, sotto di essi organizzazioni con campi flessibili in JSONB e vettore di ricerca nel testo completo, sotto di essi contatti, mentre le campagne dipendono dal progetto. Ogni progetto definisce il proprio schema di campi — per questo la stessa applicazione gestisce sia amministrazioni pubbliche sia aziende private, senza che il database cresca a ogni nuovo tipo di organizzazione.
Cosa compare nel piè di pagina di ogni email inviata: L’identità completa dell’azienda — denominazione, codice fiscale, sede legale — l’indirizzo del responsabile della protezione dei dati, il fondamento giuridico invocato e da dove proviene l’indirizzo: registri pubblici e profili pubblici, detto esplicitamente, non sottinteso. In più, disiscrizione in un clic e una variante di riserva, con risposta in una sola parola. Ciò che riguarda il fondamento giuridico viene ricontrollato a ogni modifica della legge — un invio massivo che cita un fondamento superato è un problema anche se il resto è impeccabile.
Chi vede cosa: L’accesso avviene tramite autenticazione, i percorsi dell’applicazione sono chiusi dietro un gate, e l’area di amministrazione ha un gate in più. I ruoli sono separati: amministrazione, proprietario, vendite, prospezione e un ruolo distinto per l’agent automatizzato — perché un agent che scrive nel sistema non deve avere i diritti di un uomo. Non esiste registrazione aperta.
Cosa verifichiamo esplicitamente all’installazione: Che ogni secret sia effettivamente impostato sul server: il secret con cui si firmano i webhook in ingresso e il secret con cui si firmano i token di disiscrizione. Sono verifiche che sembrano formali finché non lo sono più: una verifica di firma non ha cosa confrontare se il secret manca, e un token prevedibile è un token che non protegge nessuno. Le inseriamo nell’elenco di consegna, non nelle supposizioni.
Cosa viene cancellato su richiesta e cosa rimane: La cancellazione completa rimuove l’indirizzo da sei tabelle e lo inserisce in una lista permanente di blocco, così che un import successivo non lo riporti indietro. Rimane una traccia nel journal, con il motivo — perché bisogna poter dimostrare, dopo un anno, che la richiesta è stata soddisfatta. Restano anche gli aggregati statistici, che non identificano nessuno.

Un caso

Un indirizzo ha ricevuto 42 email in un giorno. Non era un loop.

La situazione

In una campagna di prospezione su organizzazioni, una sola casella postale ha ricevuto 42 messaggi nello stesso giorno. La prima ipotesi, quella comoda, è un loop nel codice. Non lo era.

Cosa abbiamo costruito

L’estrazione dei destinatari era fatta per organizzazione, non per indirizzo. Quarantadue organizzazioni usavano la stessa casella postale — situazione assolutamente comune nell’ambiente d’affari locale, dove un commercialista, una società madre o un amministratore servono più entità. Ogni organizzazione era, correttamente, un destinatario unico; l’indirizzo no. Il numero totale di persone coinvolte in quell’incidente è stato 11. La correzione è stata in tre parti, non in una: la deduplicazione è stata spostata sull’indirizzo scritto in minuscolo, è stato introdotto un raffreddamento di cinque giorni tra campagne per lo stesso indirizzo, e tutti gli script di invio sono stati obbligati a passare attraverso un modulo comune di protezione — quello che rifiuta di registrare un invio senza identificatore della campagna. Lo stesso giorno è stato aggiunto anche l’interruttore che ferma completamente l’orchestrator, senza possibilità di aggiramento.

Cosa è emerso

Oggi, la deduplicazione per indirizzo, la lista delle disiscrizioni, i filtri di dominio e il raffreddamento di cinque giorni sono garanzie del modulo comune, non abitudini dello script che capita di essere eseguito. Uno script manuale scritto in fretta non può più aggirare le protezioni, perché non ha più il permesso di inviare da solo.

Cosa non dice il caso

La lezione non si trasferisce automaticamente: ogni database ha la propria forma di duplicato. In uno è l’indirizzo email, in un altro è il numero di telefono di un gruppo di aziende, nel terzo è una persona con due funzioni. La prima cosa che facciamo in un nuovo import è cercare qual è lì la forma di duplicato — non presumiamo che sia la stessa.

Domande

Cosa ci chiedono le persone prima di chiamare

Mi vendete il CRM con cui lavorate voi?

No, e il motivo è tecnico, non commerciale. Il nostro sistema è costruito per un solo team: non ha una separazione rigorosa dei dati tra clienti e non ha un flusso di installazione che non presupponga l’accesso al server. Per poterlo dare a qualcuno, bisognerebbe riscrivere esattamente queste due cose. Lo mostriamo per lo stesso motivo per cui un falegname mostra il proprio laboratorio — dice più del mestiere di quanto faccia una brochure. Quello che vendiamo è la costruzione di un sistema per il modo in cui lavorate voi.

Perché dovrei costruire, invece di comprare un CRM già pronto?

Nella maggior parte dei casi non dovrebbe, e glielo diciamo noi. Uno strumento già pronto è la risposta corretta quando il Suo lavoro assomiglia all’ipotesi per cui è stato pensato. La costruzione diventa giustificata in tre situazioni concrete: ha tipi di organizzazioni fondamentalmente diversi che non entrano nello stesso insieme di campi; metà delle interazioni arriva da sistemi automatici che devono scrivere da soli nella scheda; oppure ha bisogno di regole di invio che lo strumento non Le dà e che non può permettersi di violare. Se non si applica nessuna di queste situazioni, Le diciamo di acquistare.

Potete collegare il sistema al CRM che usiamo già?

Sì. Abbiamo scritto ed eseguito il connettore per amoCRM — 12 funzioni di server, con flusso OAuth, refresh del token, recupero dei lead e controllo dello stato — e per Bitrix24, con OAuth e webhook. Per Zoho CRM abbiamo documentato il percorso OAuth per le regioni dei data center. E quando la source of truth reale del team è un foglio di calcolo, abbiamo dieci funzioni per Google Sheets, dalla lettura della struttura del foglio fino all’importazione e all’aggiornamento dei contatti.

Come arrivano concretamente le chiamate nel CRM?

Tramite un webhook firmato, inviato alla fine della chiamata. Il sistema prende il numero di telefono e cerca l’organizzazione tramite una funzione scritta apposta per i formati in cui compaiono i numeri nei dati reali — non tramite un confronto di stringhe, che perderebbe metà dei casi. La chiamata viene salvata con transcript, riepilogo, sentiment, indirizzo della registrazione e durata, collegata alla scheda, e la regola nel codice può far avanzare il lead nel percorso in base all’esito della chiamata.

Come vi assicurate di non finire per inviare spam?

Con sei meccanismi che si controllano a vicenda, non con una buona intenzione: orari di invio, liste di esclusione per tipo di istituzione, deduplicazione per indirizzo scritto in minuscolo, raffreddamento di cinque giorni per lo stesso indirizzo, limiti giornalieri e per esecuzione, e un interruttore che ferma l’orchestratore senza possibilità di aggiramento. Sotto c’è il caso concreto che ci ha insegnato perché la deduplicazione va fatta per indirizzo, non per organizzazione.

Cosa succede quando qualcuno chiede di non essere più contattato?

Ha tre livelli, tutti protetti con un token legato al destinatario. La disiscrizione con un clic, direttamente dall’intestazione dell’email, in conformità con RFC 8058. Un centro preferenze, dove la decisione può anche essere annullata. E la cancellazione completa, che rimuove l’indirizzo da sei tabelle e lo aggiunge a una lista permanente di blocco — così che un import fatto sei mesi dopo non lo riporti indietro. L’ultima parte è quella che la maggior parte dei sistemi non riesce a fare.

Dove stanno i dati e chi può vederli?

In un database PostgreSQL, sull’infrastruttura concordata all’inizio del progetto, con migrazioni versionate — cioè ogni modifica della struttura è un file, non un intervento manuale. L’accesso è basato su ruoli distinti, con un ruolo separato per gli agenti automatici, perché un sistema che scrive nel database non deve avere i diritti di una persona. Non esiste registrazione aperta e non esiste una superficie pubblica.

Potete importare il nostro vecchio database, comprese le duplicazioni?

Sì, e proprio le duplicazioni sono il motivo per cui l’importazione è costruita così. Il file viene elaborato in streaming, in lotti da 200 righe, con un indice di deduplicazione su codice fiscale, email e telefono costruito prima della scrittura, più la convalida degli indirizzi: formato, domini usa e getta, pattern non validi. Ciò che non coincide non viene scartato in silenzio — viene segnalato, così decidi tu.

Mi garantite una crescita delle vendite?

No. Possiamo garantire che saprai chi è stato raggiunto, tramite quale canale, cosa è stato detto e cosa segue — e che il sistema si ferma da solo quando dovrebbe. I numeri di risultato dipendono dall’offerta, dal mercato e dal team che chiama, cioè da cose che non controlliamo. Non pubblichiamo percentuali di miglioramento che non abbiamo misurato, né per noi né per altri.

Su cosa si basano le affermazioni sopra (24 fonti)

24 di esse sono codice e file dei nostri repository. Non ne pubblichiamo il nome né la riga: insieme, in un'unica pagina, descriverebbero con troppa precisione come sono costruiti sistemi che non sono solo nostri. Le esaminiamo con te, nel repository, su richiesta — la verifica resta possibile, solo che avviene in una discussione.

Come lavoriamo Tutti i servizi

Cosa vorresti che funzionasse meglio?

Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.

Parliamone