O que o Dexter faz, do primeiro contato à resposta
O Dexter é a automação de prospecção da Zydon. Hoje ele executa sete processos encadeados: encontra o lead, decide se ele vale abordagem, planeja o dia, envia a mensagem, escuta a resposta, mantém os telefones no ar e relata o resultado para as pessoas.
Esta página existe para uma coisa: concordarmos sobre quais são os processos antes de reorganizá-los. Cada processo tem um código (P1 a P7) e cada etapa tem um número (P4.2, por exemplo). Se algo estiver errado ou faltando, basta citar o código.
A linha de produção
Clique em qualquer processo para ver o detalhe: o que dispara, o que entra, o que ele faz passo a passo, o que sai e quando se considera concluído.
O tamanho da operação, medido
Como esses processos são disparados hoje
Hoje não existe a figura de "processo". Existem 52 agendamentos — relógios que disparam scripts em horários fixos. Cada um foi criado para resolver um problema pontual, e juntos eles formam os sete processos por acidente, não por desenho.
O que é um agendamento aqui
Um agendamento tem só duas informações: quando disparar e o que rodar. Ele não sabe o que o script faz, não sabe se o trabalho terminou, e não sabe se já existe alguém fazendo aquilo. Ele é um despertador.
Dos 52 ligados, 44 rodam um script e 8 abrem uma conversa com um modelo de IA para decidir algo. Os de IA são incomparavelmente mais caros e demorados — um deles leva 14 minutos por execução.
| Processo | Agendamentos | Frequências usadas |
|---|---|---|
| P1 · Aquisição | 2 | a cada 1 min e a cada 30 min |
| P2 · Qualificação | 5 | todos a cada 1 min |
| P3 · Planejamento do dia | 8 | madrugada, início da manhã, e uma trilha só de sábado |
| P4 · Despacho | 6 | 1, 2, 5 e 15 min, mais um de hora em hora |
| P5 · Escuta | 6 | 1 e 5 min, mais um de 30 min e um de 6 horas |
| P6 · Canal | 10 | de 1 a 15 min — a maior família |
| P7 · Relato | 10 | horários fixos da manhã, mais dois de 15 min |
| Manutenção e pontuais | 5 | backup, transcrição de áudio, lembretes |
Existem ainda 47 agendamentos desligados
São gerações anteriores de solução para os mesmos problemas — sete variações de follow-up, três
de recuperação de perdidos, seis de qualificação. Cinco deles carregam no nome
PAUSADO-NAO-REATIVAR, o que indica que foram desligados por causar dano, não por
ficarem obsoletos. É um bom retrato de por que vale reorganizar: hoje a única forma de
saber o que está no ar é ler os 101 registros um a um.
Onde a linha está travando hoje
Três travas medidas no ambiente, em ordem de impacto no negócio. Nenhuma delas é "o servidor caiu" — todas são consequência de os processos não terem dono nem controle único.
1 · O topo do funil está represado
Há 4.794 mensagens enfileiradas que não saem — 609 só do dia 28/07. Entre elas, 241 primeiros contatos com apenas 1 enviado. Não é falta de lead: é a fila não drenando.
A causa imediata: o portão que autoriza a operação do dia recusa todo minuto, porque nenhum telefone aparece com capacidade disponível no plano do dia. A recusa está tecnicamente correta — o sistema se recusa a enviar o que não consegue provar que é seguro enviar. O problema é que ninguém é responsável por destravar.
2 · O preparo da noite não roda desde já faz dias
O processo que monta o estoque do dia seguinte (P3) falha em toda execução por procurar um arquivo de autorização num caminho que não existe — diferença de um caractere e de uma pasta em relação ao arquivo real. Sem ele, o dia começa sem estoque preparado, o que alimenta a trava número 1.
3 · A deduplicação é conselho, não regra
Antes de enfileirar, o sistema verifica em memória se aquele contato já está na fila. Mas o banco não impede a repetição — não existe restrição de unicidade. O resultado medido: de 9.417 envios com chave, só 5.995 são distintos. Há chaves repetidas até 45 vezes.
Na prática o risco é mandar a mesma mensagem para a mesma pessoa mais de uma vez. Hoje o que segura isso é o portão do dia estar fechado.
O que essas três têm em comum
Nenhuma é um erro de programação isolado. Todas vêm da mesma ausência: não existe um lugar único onde se registra que um item foi reivindicado, por quem, e como terminou. Cada rotina guarda seu pedaço de estado num arquivo próprio, e ninguém tem a visão do todo — nem as pessoas, nem o próprio sistema.
Aquisição de lead
Encontrar quem entrou na base e garantir que o CRM e o registro interno contam a mesma história.
O que ele faz, passo a passo
Observação para a reorganização
Este é o único processo cujo estado principal mora fora da máquina — no HubSpot. Isso é bom: o CRM já é uma fonte compartilhada e auditável. Mas ele guarda o estado do lead, não o da execução: não sabe qual rotina pegou o quê, nem o que já foi tentado.
Qualificação — o lead vira MQL?
Decidir se o lead merece abordagem comercial, manter a lista de pendências e não deixar o prazo do diagnóstico estourar.
O que ele faz, passo a passo
Observação para a reorganização
As cinco rotinas dizem rodar a cada minuto, mas na prática rodam a cada 3 a 12 minutos, porque disputam a mesma capacidade. A frequência declarada aqui não descreve a realidade — é uma das primeiras coisas a acertar.
Planejamento do dia
Antes de qualquer mensagem sair, decidir quantos contatos cada telefone pode fazer, com quem, e se o dia está liberado para operar.
O que ele faz, passo a passo
Esta é a peça mais bem feita da instalação
O portão do P3.5 recusa por padrão e só libera quando toda a lista está verde. Ele não aceita o arquivo dizer que está íntegro: recalcula a integridade por conta própria, porque — nas palavras do próprio código — "hash autodeclarado não é proveniência". Nunca quebra: entrada estranha vira recusa, não erro.
Quando formos desenhar o controle único, este é o modelo a copiar, não a substituir.
Problema conhecido
O P3.1 (preparo da noite) e a variação de sábado estão falhando em toda execução.
Eles procuram o arquivo de autorização em zydon-prospeccao/release-authority.json,
mas o arquivo real está em zydon-prospeccao/controle/runtime/release_authority.json
— hífen contra sublinhado, e uma pasta de diferença. A rotina irmã do despacho aponta certo e
funciona.
Despacho de mensagem
Tirar o próximo envio da fila, respeitar os limites de cada telefone e entregar no WhatsApp — com comprovante.
O que ele faz, passo a passo
Estado da fila hoje
| Tipo de mensagem | Na fila | Enviadas | Falhas | Bloqueadas | Em revisão |
|---|---|---|---|---|---|
| Follow-up F2 | 1.467 | 429 | 159 | 173 | 239 |
| Follow-up F4 | 1.246 | 303 | 138 | 91 | 6 |
| Follow-up F3 | 742 | 489 | 149 | 32 | 19 |
| Follow-up F1 | 449 | 447 | 65 | 215 | 17 |
| Envio de diagnóstico | 276 | 593 | 58 | 23 | 26 |
| Primeiro contato | 241 | 1 | 2 | 0 | 0 |
Problemas conhecidos
- A rodada aparece como erro quando na verdade foi recusa. Quando o portão do dia diz não, a rotina termina com código de erro e o painel pinta vermelho. Uma recusa correta e uma pane real são indistinguíveis para quem olha de fora.
- O motivo da recusa é descartado. A explicação que o portão produz é jogada fora na hora da execução. Só existe porque a rotina de validação (P4.6) a registra em separado.
- Três versões de código convivem na mesma execução — o produtor vem de uma versão antiga fixada, o portão de uma pasta de manutenção e o envio da versão ativa. É a origem da fragilidade.
- 12 envios em quarentena permanente, de uma sequência de 3 mensagens em que 1 saiu e 2 ficaram retidas. O sistema preserva a prova e se recusa a reenviar — certo — mas ninguém resolve a pendência.
Escuta e obrigação de resposta
Quando o lead responde, o relógio começa a correr. Este processo garante que ninguém fique sem resposta.
O que ele faz, passo a passo
Situação das obrigações
| Situação | Quantidade | Significado |
|---|---|---|
| Respondidas | 2.068 | o lead recebeu retorno |
| Silêncio intencional | 1.112 | decidiu-se não responder, e isso está registrado |
| Escaladas | 285 | passaram para tratamento humano |
| Aguardando resposta | 100 | ainda em aberto |
| Pausadas | 33 | bloqueadas por pausa deliberada |
Aqui já existe o que queremos generalizar
O P5.3 já implementa a ideia de executor independente: cada turno de conversa é reivindicado por um dono, com prazo, número de tentativas, momento em que fica elegível de novo, e um estado final que exige prova material. É exatamente o desenho que queremos aplicar aos outros processos.
Problema conhecido
O mecanismo de nova tentativa não está convergindo. Há 108 turnos em nova tentativa que somam 2.738 tentativas — uma média de 25 cada. Para comparação, os 117 turnos que fecharam com sucesso precisaram de 2,4 tentativas em média. E o estado final com prova completa tem um único registro.
Traduzindo: o sistema tenta de novo indefinidamente sem nunca desistir nem escalar.
Sustentação do canal
Manter os 18 telefones conectados e o painel no ar. É invisível quando funciona e para tudo quando falha.
O que ele faz, passo a passo
Observação para a reorganização
As dez rotinas deste processo fazem a mesma pergunta dez vezes: "está no ar? se não, sobe". Mudam apenas o alvo. É o candidato mais claro a virar um executor único parametrizado pelo inventário — um processo, dez alvos, em vez de dez processos.
Relato para pessoas
Tudo que produz saída para gente ler: relatório da manhã, auditoria do funil, agenda de reuniões e alertas.
O que é produzido
| Entrega | Quando | Para quem / o quê |
|---|---|---|
| Relatório diário profundo | 06h50 | Rafael. Executivo, somente leitura, montado sobre os artefatos do dia. |
| Teste de contingência por chip | 06h20 | Auditoria de inventário, capacidade e filas, sem alterar nada. |
| Auditoria do funil | 08h, 12h, 16h | Alerta quando o funil sai do esperado. |
| Reuniões do dia | 07h + 3 tentativas | Lucas Resende. As três tentativas extras são um mecanismo improvisado de nova tentativa. |
| Fila de follow-up do SDR | 15 min | Foto do que está pendente. |
| Alertas de fim de semana | 2 min | A única rotina que roda exatamente na frequência declarada. |
| Relatório financeiro e exportação | 08h e 18h30 | Enviados ao Mitra. |
Observação para a reorganização
A regra de comunicação hoje é: silêncio significa sucesso. A rotina só fala quando algo deu errado. É uma boa convenção — mas está aplicada de forma desigual, e um recado importante pode se perder no mesmo canal em que caem erros técnicos repetidos.
O modelo alvo: gestor, executor e controle único
A proposta não é reescrever o Dexter. É separar três papéis que hoje estão misturados dentro de cada agendamento, e dar a eles um lugar comum onde o trabalho é registrado.
Os três papéis
Isso já funciona em outro agente da casa
A Zoe opera exatamente assim. Os agendamentos dela não fazem trabalho: reivindicam um ticket deixando uma marca pública, sobem uma sessão independente e, no tique seguinte, verificam se aquela sessão ainda está viva — se morreu, retomam de onde parou. A marca pública é a fonte de verdade, então nada é feito duas vezes.
O Dexter não tem nada disso hoje. Nenhuma das 141 rotinas registra trabalho fora da própria máquina.
O que já existe e pode ser aproveitado
| Peça pronta | Onde está | O que já garante | O que falta |
|---|---|---|---|
| Reivindicação por turno | no processo P5 | Dono, prazo, tentativas, reelegibilidade e estado final com prova. | Vale só para a escuta. O despacho, que é o caminho crítico, não usa. |
| Portão com recusa por padrão | no processo P3 | Verificação independente, sem confiar no que o arquivo declara. Nunca quebra: vira recusa. | Ter o motivo da recusa preservado e visível. |
| Lançador com verificações | 8 rotinas geradas | Contrato uniforme: valida versão, ponto de entrada e autorização antes de começar. | Não conhece a noção de item nem sabe retomar. |
Os sete processos no modelo alvo
| Processo | Unidade de trabalho | Estado final | Executor pronto? |
|---|---|---|---|
| P1 Aquisição | um lead | qualificado ou descartado | não |
| P2 Qualificação | um item aberto | MQL ou não-MQL | parcial |
| P3 Planejamento | um dia | liberado ou bloqueado, com prova | sim |
| P4 Despacho | um envio | entregue com comprovante | parcial |
| P5 Escuta | um turno de conversa | respondido com prova | sim |
| P6 Canal | um telefone | linha saudável | parcial |
| P7 Relato | um relatório | entregue | não |
A decisão que ainda está em aberto
Onde fica o controle único. Pode ser o GitHub, como na Zoe; pode ser um banco próprio; pode ser o próprio HubSpot para os processos de lead. O requisito não é a ferramenta — é que seja um só lugar, fora da máquina, com unicidade garantida pelo próprio sistema, e não por uma verificação feita em memória antes de gravar.
Como propor um ajuste
Este mapa existe para ser corrigido. Ele foi montado lendo o ambiente, não perguntando às pessoas — então é natural que haja processo faltando, etapa fora de ordem ou nome errado.
Cite o código
Cada processo tem um código e cada etapa tem um número. Para pedir mudança, basta apontar:
- "O P4.5 está errado" — a etapa existe mas o que está escrito não corresponde à realidade.
- "Falta uma etapa entre P2.2 e P2.3" — há trabalho acontecendo que o mapa não registrou.
- "O P6 deveria ser parte do P4" — o recorte dos processos está errado.
- "P7 não é processo, é consequência" — algo aqui não merece ser tratado como processo próprio.
As três perguntas que mais ajudam
O que acontece depois
Com o mapa acertado, o caminho é: escolher onde fica o controle único, desligar os agendamentos atuais, e religá-los um por um já no formato gestor + executor — começando pelo processo que hoje está travando o negócio, o despacho (P4), e pelo que já tem quase tudo pronto, a escuta (P5).