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ídoDuas implementações próprias, em produção, citadas abaixo. (1) MEGA CRM — o sistema com que a nossa equipa gere a sua própria atividade comercial: `server.js` tem 9.516 linhas e 99 rotas HTTP, no repositório há 96 migrações SQL e cerca de 95.000 linhas de TypeScript na interface, e o último commit é de 18 de agosto de 2026. (2) Os conectores de CRM da plataforma Kallina: 12 funções de servidor para amoCRM, 4 para Bitrix24, mais um fluxo OAuth documentado para Zoho CRM e 10 funções para Google Sheets. A precisão que conta: **MEGA CRM não está à venda.** Mostramo-lo como prova de competência, não como produto — não tem isolamento estrito dos dados entre clientes e não tem um fluxo de instalação que não pressuponha acesso ao servidor. O serviço é “construímos um sistema como este para si”, não “damos-lhe uma licença do nosso”.

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.

Prevenção do spam no CRM — os pedidos que vale a pena acompanhar · vídeo em romeno, com legendas e transcrição em português

A transcrição completa

Olá! Na análise de hoje, dissecamos um problema com que absolutamente qualquer empresa que queira escalar acaba por se deparar a certa altura. Como é que automatizamos, exatamente, a prospeção comercial sem que tudo se transforme num spam irritante e agressivo? Queremos crescer, queremos tornar-nos mais eficientes, claro. Mas hoje vamos olhar por baixo do capô de um material técnico fascinante para ver como se previne o spam através de exatamente 6 mecanismos claros, em anel, integrados num sistema verdadeiramente seguro. Não se trata apenas das definições padrão que assinalamos e esquecemos, mas de arquiteturas reais, factos e números. Vamos aos dados! Bom, em resumo, aqui está a estrutura da nossa conversa. Começamos com o problema da aceleração sem travões, depois analisamos um estudo de caso, o incidente das 42 mensagens, passamos ao núcleo da análise, ou seja, os 6 mecanismos de proteção, falamos da gestão correta dos cancelamentos de subscrição e fechamos com o dilema clássico: quando é que faz sentido construir um sistema e quando é melhor comprá-lo.

Vamos começar! Portanto, a questão essencial com que começamos é esta. Como é que garantimos que a automatização que implementamos não se torna simplesmente spam? Há aqui uma linha incrivelmente ténue. A intenção por trás é sempre boa: queremos contactar pessoas, gerar vendas, mas, se o sistema for deixado a acelerar às cegas, sem verificações técnicas muito rigorosas codificadas diretamente na sua estrutura, o impacto na marca pode ser desastroso. Chegamos à secção 1, aceleração sem travões. Vamos olhar para o problema fundamental da evidência nestes sistemas automáticos. Pensem nisto como um carro muito potente, mas sem sistema de travagem. Quando um software padrão não se alinha com a realidade diária do trabalho, as coisas descambam rapidamente. Por exemplo, digamos que a equipa interage tanto com administrações públicas como com empresas privadas.

Estruturas de decisão completamente opostas, não é? Os seus dados simplesmente não cabem nos mesmos campos rígidos de um CRM genérico. E o que acontece na prática? As pessoas começam a manter a verdade separada, através de ficheiros Excel ou notas na secretária, enquanto a automatização principal continua a correr em vazio com dados errados. Isso significa simplesmente caos. E a nossa fonte tem aqui uma citação absolutamente genial, uma verdade brutal da indústria. Um CRM em que os dados são escritos à mão esvazia-se em 3 semanas. Faz todo o sentido. As pessoas cansam-se, aparecem erros, e o moral baixa. As pessoas de vendas têm de construir relações, não de ser robôs de introdução de dados. Quer se trate de um agente vocal inteligente que transcreve automaticamente as chamadas, ou de e-mails que se sincronizam sozinhos em segundo plano a cada 10 minutos, a ideia é clara.

A alimentação automática de dados já não é um luxo. É a base obrigatória de qualquer sistema funcional. Passamos à segunda secção, o incidente das 42 mensagens. Vamos dissecar a anatomia de uma falha real. 42. Não é apenas um número qualquer, mas uma história real de uma campanha de prospeção que desencadeou uma verdadeira reforma técnica. Conseguem imaginar? Uma única caixa de correio recebeu exatamente 42 mensagens ao longo de algumas horas, no mesmo dia. Evidentemente, a equipa técnica pensou primeiro: ok, é um bug, um simples loop no código que envia mensagens sem parar. Mas, quando olhou com mais atenção para a base de dados, a realidade era muito mais complexa do que isso. A explicação? O sistema tinha sido configurado para extrair e enviar mensagens por organização, não por endereço de e-mail.

Portanto, do ponto de vista lógico, o algoritmo tinha feito o seu trabalho na perfeição. Tinha encontrado 42 empresas juridicamente distintas. O problema, e é uma realidade que vemos muitas vezes no mercado local, era que todas estas 42 entidades usavam exatamente o mesmo endereço de e-mail. Quer fosse o da empresa-mãe, quer o do mesmo contabilista externo que administrava dezenas de empresas. As entidades eram únicas no papel, mas o destino final da mensagem era um só. E, para pôr as coisas em perspetiva, sabem quantas pessoas reais, em carne e osso, foram afetadas por esta avalanche de mensagens? Apenas 11. 11 pessoas que administravam estas dezenas de negócios. Este incidente demonstrou uma coisa muito clara. Boas intenções e um código que parece correto à primeira vista nunca são suficientes.

A base de dados tem sempre associações invisíveis, e o sistema tem de as antecipar. O que nos leva à parte mais importante, a secção 3. Os seis mecanismos de proteção, ou seja, os travões codificados diretamente no coração do sistema. Aqui está a solução. A fonte detalha um anel de proteção formado por seis mecanismos distintos que se verificam uns aos outros. 1. Definir horários de trabalho rigorosos, entre 8 e 18. Ninguém quer um e-mail de vendas no domingo às 3 da manhã. 2. Listas de exclusão permanentes, ou seja, bloquear instituições sensíveis, como escolas ou embaixadas. 3. E isto teria evitado o incidente de há pouco, a deduplicação obrigatória pelo endereço de e-mail convertido em minúsculas, e não pelo nome da empresa.

4. Um período de arrefecimento de 5 dias para qualquer endereço contactado, para evitarmos sufocar o público. 5. Limites diários rigorosos para não chatear os filtros globais anti-spam. E, por fim, o sexto mecanismo, o botão de pânico. De todos, este mecanismo 6, ou seja, o kill switch, ou interruptor de emergência, é uma peça central. Foi implementado exatamente depois desse incidente com as 42 mensagens. O que é ele, na prática? Uma variável simples que, se for ativada, simplesmente proíbe o sistema central de voltar a arrancar. Sem exceções, sem qualquer comando escondido de substituição no código. Qualquer arquitetura séria de automatização precisa de um botão físico destes, figurativamente falando, que absolutamente qualquer pessoa da gestão possa carregar sem ter conhecimentos de programação.

Vamos para a quarta secção, a gestão correta das cancelamentos de subscrição. Porque, atenção, isso significa muito mais do que um simples link colocado no fim da página. Depois de enviares a mensagem, se a pessoa quiser sair da base, o processo tem de ser irrepreensível e blindado. A análise mostra-nos um processo sólido em três etapas. Passo 1. Cancelamento no cabeçalho com um único clique, que seja conforme os novos padrões globais, como o RFC 8058. Passo 2. Um centro de preferências visual, onde a pessoa pode escolher que tipo de mensagem já não quer receber. Mas o passo 3 é, na verdade, o mais crítico e aquele em que muitos sistemas falham. Eliminação completa. Isso não significa pôr uma marca como inativo.

Significa apagar o endereço de, atenção, 6 tabelas diferentes da base de dados, mais a sua colocação numa lista negra permanente. Só assim garantes que esse endereço não reaparece como por magia na próxima importação maciça de dados. E não estamos a falar só de tecnologia. Estamos a falar de respeito e conformidade legal diretamente no rodapé do e-mail. Quem são vocês? Quem é o responsável DPO? Qual é a base legal exata com base na qual enviaram a mensagem? E, sobretudo, de que registo público extraíram os dados inicialmente? A nossa fonte sublinha uma regra de ouro. Estas bases têm de ser reavaliadas em cada alteração legislativa. Porquê? Porque podes ter o sistema mais caro do mundo. Se, com base numa lei revogada, transformaste a tecnologia num risco financeiro major para a empresa.

Chegamos à última secção, a quinta. Quando construir vs. quando comprar? Vamos ver a resposta correta para uma infraestrutura comercial madura. A documentação aborda esta decisão de forma extremamente objetiva. Um CRM pronto a usar, chave na mão, é absolutamente ideal. Com uma única condição major. Que o vosso fluxo de trabalho se adapte perfeitamente à lógica pensada pelos criadores da plataforma. No entanto, a decisão de construir uma solução personalizada torna-se o único caminho em três situações claras. Quando interagem com tipos muito diferentes de organizações, quando têm um volume massivo de automatizações em que o trabalho manual se torna impossível e, o mais importante, quando têm regras de proteção estritas, como esses seis mecanismos que um software de prateleira simplesmente não vos pode garantir a um nível tão profundo.

A boa notícia? Construir algo seguro por trás não significa deitar pela janela as ferramentas que a equipa já conhece. Estes mecanismos de proteção podem correr silenciosamente como uma camada invisível de segurança, enquanto se ligam às interfaces habituais. Existem arquiteturas demonstráveis que têm conectores que executam dezenas de funções bidirecionais com sistemas populares como Amos ERM, Bitrix24, Zohos ERM ou até as clássicas tabelas Google Sheets. Em suma, o núcleo de segurança permanece intacto, mas a experiência do utilizador é igualmente amigável. E assim, o material deixa-nos um tema de reflexão bastante incómodo que vale a pena levar connosco. Um sistema comercial superavançado que só o programador que o escreveu ainda sabe como parar é, afinal, um super ativo para a empresa ou, na verdade, um risco inaceitável?

No fim do dia, a transparência, esse botão de emergência colocado à vista e a documentação clara são as coisas que diferenciam uma simples máquina cega de um sistema de negócio verdadeiramente escalável, profissional e responsável. Espero que esta dissecação dos mecanismos tenha trazido um pouco mais de luz sobre como deve ser uma automatização correta. Até breve!

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.

Canais que convergem para a mesma ficha: a chamada do agente vocal, a chamada humana, o e-mail e a resposta da caixa de correio, o formulário no site, o webhook de outro sistema — e os travões que decidem o que volta a sair.

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