Especialização · CRM e vendas

Um sistema em que se vê quem foi contactado, por que canal e o que vem a seguir.

Construímos o sistema comercial de uma organização: organizações e contactos, um percurso de estágios, os canais que trazem dados por si só — chamada, email, formulário, agente vocal — e os travões que param os envios antes de se tornarem um problema. Não vendemos o nosso CRM; construímos um para a forma como você trabalha.

Fale sobre um projeto

Já construídoDouă 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”.

A maioria das empresas não tem um problema de CRM, tem um problema de registo: não se sabe quem foi contactado, por que canal, o que foi dito e o que vem a seguir. Um instrumento pronto a usar resolve isso quando o seu trabalho se parece com o trabalho para o qual o instrumento foi pensado. Quando não se parece — porque você trabalha ao mesmo tempo com administrações públicas e com empresas privadas, ou porque metade dos contactos vem de um voice agent — você acaba por forçar o instrumento, e a equipa guarda a verdade num ficheiro separado. Nessa altura, vale a pena construir algo.

O sistema que mostramos como prova é aquele com que trabalhamos nós. Está estruturado em projetos separados, cada um com o seu tipo de organização e com o seu esquema de campos, para que a mesma aplicação funcione tanto para uma câmara municipal como para uma empresa privada, sem novas colunas na base para cada novo tipo. Abaixo da organização estão os contactos, acima estão as campanhas. Um lead sobe por um percurso de sete estádios, de «não contactado» até «contrato assinado», e pode ser alcançado por nove canais diferentes, desde a chamada do voice agent até à visita.

A parte difícil, e aquela que se aprende na prática, não é o envio. É a paragem. O sistema tem horários de trabalho escritos no código, listas de exclusão, deduplicação pelo endereço escrito em minúsculas — não pela organização —, um período de arrefecimento entre campanhas, um limite diário repartido entre campanhas e um interruptor que se recusa a arrancar o orchestrator, sem caminho de contorno. Cada um deles foi adicionado depois de ter faltado uma vez. Enumeramo-los não como lista de funcionalidades, mas como lista de lições.

A segunda coisa que construímos quase sempre é o abastecimento automático. Um CRM em que os dados são escritos à mão esvazia-se em três semanas. Connosco, a chamada do voice agent é escrita automaticamente na ficha da organização, com transcript e resumo, e faz o lead avançar no percurso se o resultado da chamada o justificar. As respostas a emails são recolhidas da caixa de correio de dez em dez minutos e ligadas ao envio que as provocou. As aberturas e os cliques são acompanhados separadamente. A pessoa intervém para decidir, não para introduzir dados.

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!

Qué incluye

El trabajo, por componentes

Os dados entram em fluxo, com deduplicação por três chaves

Um ficheiro de até 50 MB é carregado e processado em fluxo, em lotes de 200 linhas, para não ultrapassar o tempo de execução da base, e o progresso volta em tempo real, uma linha por cada passo. Antes da importação é construído um índice de deduplicação com três chaves — código fiscal, endereço de email e telefone — e os endereços são validados: formato, domínios descartáveis, padrões inválidos. A mesma organização não entra duas vezes com duas denominações escritas de forma diferente.

Cada contacto é escrito na ficha da organização

Nove canais de comunicação, desde o voice agent e a chamada humana até à visita, e um percurso de sete estádios com etiquetas reais: não contactado, contactado, resposta recebida, proposta enviada, interessado ativo, negociação, contrato assinado. Cada estádio tem escrito ao lado que percentagem deverá passar para a frente — não como promessa, mas como referência para quem olha para o funil e quer saber onde se perde.

A chamada do voice agent faz o lead avançar sozinha

Quando o agente termina uma chamada, o resultado entra no sistema através de um webhook cuja assinatura é verificada: transcript, resumo, sentimento, endereço da gravação, duração. A organização é identificada pelo número de telefone, através de uma função escrita na base para os formatos em que os números aparecem em dados reais, e a chamada é ligada à sua ficha. Se o resultado for «interessado» ou «reunião agendada», o lead sobe automaticamente no percurso e a data do último contacto é atualizada.

O envio tem travões, não só aceleração

Horários de trabalho escritos no código: 08:00–18:00, fuso horário de Chisinau, de segunda a sábado. Listas de exclusão para escolas, liceus, jardins de infância, embaixadas e consulados. Deduplicação pelo endereço escrito em minúsculas — não pela organização, uma distinção que conta imenso quando várias empresas usam a mesma caixa de correio. Arrefecimento de cinco dias entre campanhas para o mesmo endereço. Limite diário global, repartido proporcionalmente entre campanhas, mais um limite por execução, para que os envios sejam espalhados por várias horas, não em bloco.

Um interruptor que não pode ser contornado

O orchestrator de campanhas verifica uma variável de ambiente antes de qualquer outra coisa. Se estiver definida, recusa-se a arrancar e sai — não existe argumento de linha de comandos que a ultrapasse, não existe «forçar». Foi adicionado em 1 de maio de 2026, após um incidente de envios duplicados. Um sistema que envia em seu nome precisa de uma paragem que possa ser acionada por alguém que não seja programador.

Cancelamento de subscrição num só clique, em três etapas

A primeira etapa é o cabeçalho standard de cancelamento de subscrição com um clique, conforme a RFC 8058 — o requisito que os grandes fornecedores de email impõem para envios em volume. A segunda é um centro de preferências, onde o cancelamento de subscrição também pode ser anulado. A terceira é o apagamento completo a pedido, que elimina o endereço de seis tabelas, o adiciona a uma lista permanente de bloqueio e deixa um rasto no registo. As três estão protegidas com um token ligado ao destinatário, para que ninguém possa cancelar a subscrição de outra pessoa.

As respostas e as reações são recolhidas automaticamente

As respostas aos emails são lidas da caixa de correio através do Microsoft Graph, de dez em dez minutos, e ligadas automaticamente ao envio que as causou. O estado da entrega é sincronizado a partir do fornecedor de envio. As aberturas são rastreadas com pixel, os cliques por redirect, e os painéis de entregabilidade mostram os domínios com problemas. Um serviço separado acompanha o crédito restante nos fornecedores pagos e dá alerta antes de acabar — não depois.

Pesquisa pelo que uma organização faz, não apenas pelo nome

Além da pesquisa em texto integral, a pergunta é transformada num vetor com um modelo de embedding e a correspondência é feita na base através de uma função própria, com limiar de semelhança ajustável (por defeito 0,25) e com limitação por projeto. Na prática: „empresas que fazem transporte refrigerado” encontra também organizações que não têm nenhuma dessas palavras no nome.

Ligação ao CRM que você já tem

Se a sua equipa já trabalha num CRM, não o substituímos por reflexo. Escrevemos e executámos o conector para amoCRM — 12 funções de servidor, incluindo o fluxo OAuth completo, a renovação do token e a verificação do estado — além de Bitrix24 com OAuth e webhook, um guia OAuth para Zoho e dez funções para Google Sheets, desde a leitura da estrutura de uma folha até à importação de contactos.

Qué aspecto tiene

El recorrido, paso a paso.

Primeiro o modelo, depois a interface

O que é uma organização para você, o que é um contacto, o que é uma oportunidade, que campos são obrigatórios e quais são apenas úteis. Esta conversa parece lenta e é a única que não pode ser recuperada mais tarde: um modelo errado paga-se em cada relatório que você pede a seguir.

O percurso e os estádios, escritos como regras, não como hábito

Os estádios por que passa um lead, o que o faz avançar e o que o faz recuar, quem é responsável em cada um. Escrevemos também as regras automáticas — que resultado de chamada faz subir o lead, que inatividade o faz descer — porque um percurso que só se mexe quando alguém se lembra de carregar não é um percurso, é uma lista.

Os canais que trazem dados sozinhos

As chamadas da telefonia ou do agente vocal, as respostas da caixa de correio, os formulários do site, os webhooks de outros sistemas. Cada canal é ligado e testado separadamente, e para cada um definimos o que acontece com os dados que não coincidem com nada na base — porque esses são os que se perdem em silêncio.

Os travões antes da aceleração

Horas de envio, listas de exclusão, deduplicação, arrefecimento, limites, cancelamento de subscrição, paragem de emergência. Colocamo-los antes da primeira campanha, não depois da primeira reclamação. É a parte em que a nossa experiência custa menos e vale mais, porque é feita de erros já pagos.

Entrega: procedimentos, funções, documentação

Quem tem que função, como se adiciona uma pessoa, como se pára uma campanha, onde se vê quando algo não saiu, o que se faz num pedido de eliminação. Um sistema comercial que só o construtor sabe parar é um risco, não um ativo.

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.

Os dados

Qué tocamos, dónde están y cuánto se quedan

Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.

Onde ficam os dados e como estão estruturados: PostgreSQL através de Supabase, com 96 migrações versionadas. A estrutura é hierárquica: projetos, sob eles organizações com campos flexíveis em JSONB e vetor de pesquisa em texto integral, sob elas contactos, e as campanhas dependem do projeto. Cada projeto define o seu próprio esquema de campos — por isso a mesma aplicação serve tanto administrações públicas como empresas privadas, sem a base crescer a cada novo tipo de organização.
O que aparece no rodapé de cada email enviado: A identidade completa da empresa — nome, código fiscal, sede registada — o endereço do responsável pela proteção de dados, o fundamento legal invocado e a origem do endereço: registos públicos e perfis públicos, dito explicitamente, não subentendido. Mais a opção de cancelamento de subscrição num clique e uma alternativa de recurso, com resposta numa palavra. O que diz respeito ao fundamento legal é verificado novamente a cada alteração da lei — um envio em massa que cite um fundamento desatualizado é um problema, mesmo que o resto esteja impecável.
Quem vê o quê: O acesso é feito por autenticação, as rotas da aplicação estão fechadas atrás de um gate, e a área de administração tem um gate adicional. Os papéis estão separados: administração, proprietário, vendas, prospeção e um papel distinto para o agente automático — porque um agente que escreve no sistema não deve ter os direitos de uma pessoa. Não existe registo aberto.
O que verificamos explicitamente na instalação: Que cada segredo está efetivamente definido no servidor: o segredo com que são assinados os webhooks que entram e o segredo com que são assinados os tokens de cancelamento de subscrição. São verificações que parecem formais até deixarem de o ser: uma verificação de assinatura não tem o que comparar se o segredo falta, e um token previsível é um token que não protege ninguém. Colocamo-las na lista de entrega, não em suposições.
O que é eliminado a pedido e o que fica: A eliminação completa retira o endereço de seis tabelas e coloca-o numa lista permanente de bloqueio, para que uma importação posterior não o traga de volta. Fica um rasto no registo, com o motivo — porque é preciso poder demonstrar, daqui a um ano, que o pedido foi cumprido. Os agregados estatísticos, que não identificam ninguém, também ficam.

Un caso

Um endereço recebeu 42 emails num dia. Não era um loop.

A situação

Numa campanha de prospeção para organizações, uma única caixa de correio recebeu 42 mensagens no mesmo dia. A primeira hipótese, a mais cómoda, é um loop no código. Não era.

Qué construimos

A extração dos destinatários era feita por organização, não por endereço. Quarenta e duas organizações usavam a mesma caixa de correio — uma situação absolutamente comum no meio empresarial local, onde um contabilista, uma empresa-mãe ou um administrador servem várias entidades. Cada organização era, corretamente, um destinatário único; o endereço não era. O número total de pessoas afetadas nesse incidente foi 11. A correção foi em três partes, não em uma: a deduplicação passou para o endereço escrito em minúsculas, foi introduzido um período de espera de cinco dias entre campanhas para o mesmo endereço, e todos os scripts de envio foram obrigados a passar por um módulo comum de proteção — o que recusa registar um envio sem identificador da campanha. No mesmo dia foi acrescentado também o interruptor que desliga completamente o orquestrador, sem possibilidade de contorno.

Qué salió

Hoje, a deduplicação por endereço, a lista de cancelamentos de subscrição, os filtros de domínio e o período de espera de cinco dias são garantias do módulo comum, não hábitos do script que por acaso está a correr. Um script manual escrito à pressa já não pode contornar as proteções, porque já não tem permissão para enviar sozinho.

Qué no dice el caso

A lição não se transfere automaticamente: cada base de dados tem a sua própria forma de duplicado. Numa é o endereço de email, noutra é o número de telefone de um grupo de empresas, na terceira é uma pessoa com duas funções. A primeira coisa que fazemos numa nova importação é procurar qual é a forma de duplicado ali — não presumimos que seja a mesma.

Perguntas

Lo que nos pregunta la gente antes de llamar

Vocês vendem o CRM com que vocês trabalham?

Não, e o motivo é técnico, não comercial. O nosso sistema foi feito para uma única equipa: não tem separação estrita de dados entre clientes e não tem um fluxo de instalação que não pressuponha acesso ao servidor. Para ser entregue a alguém, teriam de ser reescritas exatamente essas duas coisas. Mostramo-lo pelo mesmo motivo por que um marceneiro mostra a sua oficina — diz mais sobre o ofício do que uma brochura. O que vendemos é a construção de um sistema para a forma como você trabalha.

Por que haveria de construir, em vez de comprar um CRM já pronto?

Na maioria das vezes não deveria, e somos nós que lho dizemos. Uma ferramenta já pronta é a resposta certa quando o seu trabalho se parece com a hipótese para a qual foi pensada. A construção torna-se justificada em três situações concretas: tem tipos de organizações fundamentalmente diferentes que não cabem no mesmo conjunto de campos; metade dos contactos vem de sistemas automáticos que têm de escrever sozinhos na ficha; ou precisa de regras de envio que a ferramenta não lhe dá e que não se pode dar ao luxo de violar. Se nenhuma se aplicar, dizemos-lhe para comprar.

Podem ligar o sistema ao CRM que já usamos?

Sim. Temos escrito e executado o conector para amoCRM — 12 funções de servidor, com o fluxo OAuth, a renovação do token, a obtenção de leads e a verificação do estado — e para Bitrix24, com OAuth e webhook. Para Zoho CRM, temos o percurso OAuth documentado por regiões de centro de dados. E quando a fonte real de verdade da equipa é uma folha de cálculo, temos dez funções para Google Sheets, desde a leitura da estrutura da folha até à importação e atualização de contactos.

Como é que as chamadas entram no CRM, concretamente?

Por meio de um webhook assinado, enviado no fim da chamada. O sistema pega no número de telefone e procura a organização através de uma função escrita de raiz para os formatos em que os números aparecem em dados reais — não por uma comparação de strings, que falharia em metade dos casos. A chamada é guardada com transcript, resumo, sentimento, endereço do registo e duração, ligada à ficha, e a regra no código pode subir o lead no funil em função do resultado da chamada.

Como se asseguram de que não acabamos por enviar spam?

Por seis mecanismos que se verificam uns aos outros, e não por uma boa intenção: horas de envio, listas de exclusão por tipo de instituição, deduplicação por endereço escrito em minúsculas, arrefecimento de cinco dias para o mesmo endereço, limites diários e por execução, e um interruptor que para o orchestrator sem caminho de desvio. Mais abaixo está o caso concreto que nos ensinou porque a deduplicação tem de ser feita por endereço, e não por organização.

O que acontece quando alguém pede para não voltar a ser contactado?

Tem três níveis, todos protegidos com um token ligado ao destinatário. A subscrição cancelada com um clique, diretamente a partir do cabeçalho do email, em conformidade com o RFC 8058. Um centro de preferências, onde a decisão também pode ser anulada. E a eliminação completa, que remove o endereço de seis tabelas e o adiciona a uma lista permanente de bloqueio — para que uma importação feita seis meses depois não o traga de volta. A última parte é a que a maioria dos sistemas falha.

Onde ficam os dados e quem os pode ver?

Numa base PostgreSQL, na infraestrutura acordada no início do projeto, com migrações versionadas — isto é, cada alteração de estrutura é um ficheiro, e não uma intervenção manual. O acesso é por funções distintas, com uma função separada para os agentes automáticos, porque um sistema que escreve na base não deve ter os direitos de um humano. Não existe registo aberto e não existe superfície pública.

Podem importar a nossa base antiga, com duplicados incluídos?

Sim, e são precisamente os duplicados o motivo pelo qual a importação foi construída assim. O ficheiro é processado em fluxo, em lotes de 200 linhas, com um índice de deduplicação por número fiscal, email e telefone construído antes da escrita, além da validação dos endereços: formato, domínios descartáveis, padrões inválidos. O que não bate certo não é descartado em silêncio — é reportado, para que decidas tu.

Garantem-me um aumento das vendas?

Não. Podemos garantir que saberás quem foi contactado, por que canal, o que foi dito e o que se segue — e que o sistema se desliga sozinho quando deve. Os números de resultado dependem da oferta, do mercado e da equipa que faz as chamadas, ou seja, de coisas que não controlamos. Não publicamos percentagens de melhoria que não tenhamos medido, nem para nós nem para mais ninguém.

Em que se baseiam as afirmações acima (24 fontes)

24 delas são código e ficheiros dos nossos repositórios. Não publicamos o nome nem a linha: juntos, numa única página, descreveriam com demasiada precisão como estão construídos sistemas que não são só nossos. Percorremo-los consigo, no repositório, a pedido — a verificação continua possível, só que se faz numa conversa.

Como trabalhamos Todos os serviços

O que gostaria que funcionasse melhor?

Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.

Vamos falar