Dexter · caderno
Zydon · Dexter

Sete processos, do primeiro contato à resposta

O que a automação de prospecção faz hoje, lido direto do ambiente, para acordarmos o mapa antes de reorganizar.

Levantamento de 30 jul, revisto em 4 ago 2026 Nenhuma configuração alterada Documento interno
Por que existe

Hoje não existe a figura de processo dentro do Dexter. Existem 43 rotinas automáticas ligadas, cada uma criada para resolver um problema pontual. Juntas elas formam sete processos, mas por acidente, não por desenho.

Este caderno nomeia esses sete e descreve cada um pelo que ele faz, não pelo código que o executa. Cada processo recebe um código de P1 a P7 e cada etapa um número, para que qualquer ponto possa ser corrigido citando a referência.

Entre o levantamento original e esta revisão o ambiente mudou de forma relevante: um caminho novo de despacho entrou em produção e o planejamento do dia saiu do ar. O capítulo Mudou registra a diferença, e é por ele que vale começar.

Os capítulos
Escala

São 21 linhas de WhatsApp operando ao mesmo tempo, 11.804 envios registrados no histórico e 12.487 eventos de conversa entre recebidas e enviadas. Tudo isso é acionado por 43 rotinas automáticas ligadas hoje, e outras 60 permanecem desligadas.

§

O que mudou desde o levantamento

Entre 30 de julho e 4 de agosto o Dexter trocou de caminho de despacho e perdeu o planejamento do dia. Nas duas pontas, sem aviso no mapa.

31 de julho

Treze agendamentos foram desligados no mesmo minuto

Às 05h37 de 31 de julho, treze rotinas passaram a pausado de uma vez. Nenhuma delas registra motivo. Entre elas está o núcleo inteiro do P3 — o preparo da noite, o pré-plano por telefone e o isolamento final — e as duas entregas da manhã do P7, incluindo o relatório executivo das 06h50.

O P3 tinha oito agendamentos no levantamento. Sobrou um, o plano de capacidade das 06h45, e o último status dele é erro. Na prática o processo deixou de existir.

O que saiu do ar
AgendamentoEtapaDesde
Preparo integral noturno 20h05–06h45P3.131 jul
Pré-plano por chip D-1 20h30P3.231 jul
Isolamento final por chip 05h15P3.431 jul
Relatório diário profundo 06h50P731 jul
Teste de contingência por chip 06h20P731 jul
Relatório diário de follows 18hP71 ago
Worker de retry das obrigaçõesP529 jul
Preparo rolante e reconciliação de arquivoP3, P431 jul
Trilhas de sábado e recuperação de perdidosP3, P431 jul
31 de julho

Um caminho novo de despacho entrou em produção

No mesmo dia, às 18h40, entrou no ar o V4: uma rotina de 30 em 30 minutos que valida e envia em dois passos separados. Ele não substitui o P4 no papel — substitui o P4 na prática, porque é ele que está entregando.

O worker antigo continua ligado e falha em toda execução, justamente porque procura os marcos do P3 que foram desligados. Os dois convivem na mesma fila.

A prova
DiaO que estava no arMensagens entregues
28 julworker antigo30
29 julworker antigo21
30 julworker antigo · dia do levantamento6
31 julP3 desligado, V4 recém-criado1
3 agoV435
4 agoV4130
Leitura
O V4 responde a duas das três travas

Ele não depende do portão do dia, então a trava 1 deixa de bloqueá-lo. E ele reivindica cada envio com dono e prazo de validade antes de mandar, que é exatamente o mecanismo de executor que este caderno propunha no modelo alvo — só que já em produção, no caminho crítico.

O que ele não resolve é a trava 3: a unicidade continua sem garantia no banco, e a fila continua crescendo mais rápido do que drena.

Em aberto
A pausa de 31 de julho foi decisão ou foi acidente? Treze agendamentos no mesmo minuto, nenhum com motivo registrado, derrubando um processo inteiro. O código do V4 pesa a favor de decisão: dois comentários dentro dele creditam regras a “Lucas 31/07”, a mesma data. Mas nada no ambiente registra a intenção, e o worker antigo foi deixado ligado falhando. Se foi decisão, o P3 precisa ser redesenhado em torno do V4 e este caderno já reflete o novo desenho. Se foi acidente, o que está vencido não é o caderno — é a operação. Esta é a primeira pergunta a responder.
§

Como esses processos são disparados hoje

Existem 43 relógios disparando scripts em horários fixos. Nenhum deles sabe o que é um processo.

O mecanismo

Um agendamento carrega 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á tem alguém fazendo aquilo. Ele é um despertador.

Dos 43 ligados, 39 rodam um script e 4 abrem uma conversa com um modelo de inteligência artificial para decidir algo. Os de IA custam muito mais e demoram muito mais.

Distribuição
ProcessoAgendamentosFrequências usadas
P1 Aquisição2a cada 1 minuto e a cada 30 minutos
P2 Qualificação6quatro de 1 minuto e dois de 5 minutos
P3 Planejamento do dia2o que sobrou: capacidade às 06h45 e pesquisa às 23h30
P4 Despacho5V4 de 30 minutos, mais worker, validador e dois monitores
P5 Escuta51 e 5 minutos, mais a revisão de 6 horas
P6 Canal11de 1 a 15 minutos, a maior família
P7 Relato9horários fixos, mais três de 15 minutos
Manutenção e pontuais3backup, transcrição de áudio, lembretes
Cadência

A frequência declarada não é a real, e a distância aumentou

Medindo as execuções de 24 horas: os agendamentos que dizem rodar a cada 1 minuto rodam, no melhor caso, a cada 12 minutos e meio. A maioria dos de 1 a 5 minutos caiu para a faixa de 4 a 6 horas entre execuções. Oito dos 43 ligados não executaram nenhuma vez no período.

A máquina não estava saturada no momento da medição. O que está saturado é a fila do próprio relógio: como cada agendamento faz o trabalho inteiro dentro do disparo, um que demora segura todos os outros.

Arqueologia
Além desses, 60 estão 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 carregam no nome PAUSADO-NAO-REATIVAR, o que indica que foram desligados por causar dano, e não por ficarem obsoletos. Os treze mais recentes são de 31 de julho e não são arqueologia — são operação que saiu do ar semana passada.

Hoje a única forma de saber o que está no ar é ler os 103 registros um a um.

§

Onde a linha está travando hoje

Três travas medidas no ambiente. Nenhuma é queda de servidor; todas vêm de os processos não terem dono.

Trava 1

O topo do funil está represado, e represando mais

5.266 mensagens enfileiradas que não saem, sendo 608 só do dia 28 de julho. Entre elas estão 256 primeiros contatos, dos quais apenas 1 foi enviado — o mesmo 1 de cinco dias atrás. O volume de leads existe. O que não acontece é a fila drenar.

No levantamento a fila tinha 4.794. O V4 passou a entregar, mas entrega menos do que entra: em quatro dias a fila cresceu quase 500 itens. Drenar a fila não é a mesma coisa que voltar a enviar.

Trava 2

O preparo da noite não roda mais — agora por decisão, não por defeito

No levantamento, a etapa falhava por um caminho de arquivo escrito errado. Esse defeito não existe mais: a referência torta sumiu da árvore ativa e o arquivo de autorização foi reposicionado.

A etapa continua sem rodar por outro motivo: o agendamento foi desligado em 31 de julho, junto com o resto do P3. Quem for consertar precisa saber disso, porque procurar o bug antigo é procurar o que já foi corrigido.

O efeito no negócio permanece e ficou pior: o worker antigo de despacho falha em toda execução reclamando exatamente dos marcos das 05h15, 06h20 e 06h45 que o P3 deixou de produzir.

Trava 3

A deduplicação é conselho, não regra

Antes de enfileirar, o sistema verifica em memória se aquele contato já está na fila. O banco, porém, não impede a repetição, porque não existe restrição de unicidade. De 9.781 envios com chave, só 6.067 são distintos. Há chaves repetidas até 48 vezes — eram 45 no levantamento.

Esta é a trava que o V4 não resolve, e virou a mais urgente das três. No levantamento, o que segurava o risco era um acidente feliz: o portão do dia estava fechado e nada saía. O V4 não passa por esse portão — ele tem guardas próprias, por item, e envia. As guardas dele são boas, mas nenhuma delas é unicidade no banco.

O denominador
Não existe um lugar único onde se registra que um item foi reivindicado, por quem, e como terminou. As três travas são sintomas da mesma ausência. Cada rotina guarda seu pedaço de estado num arquivo próprio, e ninguém enxerga o todo.
P1

Aquisição de lead

Encontrar quem entrou na base e garantir que o CRM e o registro interno contam a mesma história.

Dispara quando
A cada 1 minuto para lead novo, a cada 30 minutos para reconciliação
Entrada
HubSpot e o registro interno de contatos
Saída
Lead marcado como candidato à qualificação
Conclui quando
O lead existe nos dois lados com o mesmo estado
Etapas

O que ele faz, passo a passo

P1.1

Detecta lead novo

Verifica se apareceu contato que ainda não passou pela qualificação, e registra início e conclusão da entrada.

P1.2

Varre divergências entre CRM e registro interno

Compara os dois lados e aponta o que existe num e não no outro. Leva cerca de um minuto e meio por varredura.

P1.3

Entrega para a qualificação

O lead reconciliado fica disponível para o P2 decidir se vira MQL.

Nota
Para a reorganização

Este é o único processo cujo estado principal mora fora da máquina, no HubSpot. Isso é bom, porque 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.

P2

Qualificação

Decidir se o lead merece abordagem comercial, manter a lista de pendências e não deixar o prazo do diagnóstico estourar.

Dispara quando
A cada 1 e a cada 5 minutos, em seis rotinas diferentes
Entrada
Leads reconciliados pelo P1
Saída
Lead classificado como MQL ou não, e fila de pendências atualizada
Conclui quando
O lead saiu da lista de itens abertos
Etapas

O que ele faz, passo a passo

P2.1

Qualifica o lead ativo

Roda a análise que decide se é MQL e grava o resultado no CRM. É a etapa mais pesada: leva cerca de 90 segundos, com limite rígido de 110 segundos. Hoje estoura o limite em praticamente toda execução — ver abaixo.

P2.2

Reconstrói a fila de itens abertos

Refaz a lista de leads pendentes a partir dos registros de origem e só avisa quando o conjunto muda. Não envia mensagem nem escreve no CRM.

P2.3

Vigia o prazo do diagnóstico

Acompanha se o diagnóstico prometido ao lead está dentro do prazo combinado.

P2.4

Cumpre obrigações do ciclo de vida

Executa as tarefas que a mudança de estágio do lead exige. Deixa um registro por execução, e hoje há quase 2.000 desses arquivos acumulados.

Falha ativa
A qualificação está cega

Nas últimas 24 horas o P2.1 rodou 77 vezes e falhou 76. O erro é sempre o mesmo: estoura o tempo limite e termina sem dizer o que aconteceu. Nenhum lead novo está sendo classificado como MQL ou descartado por esta etapa.

É a falha mais silenciosa do conjunto, porque não gera fila visível nem alerta: o funil simplesmente para de produzir qualificação, e as etapas seguintes continuam trabalhando o que já estava dentro.

Nota
A frequência declarada não é a real

As rotinas dizem rodar a cada minuto, mas na prática rodam a cada 12 minutos no melhor caso, porque disputam a mesma capacidade. Em julho a faixa era de 3 a 12 minutos; ela piorou. É uma das primeiras coisas a acertar.

P3

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. Hoje esse processo não existe mais.

Dispara quando
Só a capacidade das 06h45 e a pesquisa das 23h30 — o resto está desligado
Entrada
Estoque de contatos, inventário de telefones, metas do dia
Saída
Nenhuma desde 31 de julho. O último veredito é de 30 de julho
Conclui quando
O veredito do dia foi emitido e assinado
Estado
Seis das oito rotinas foram desligadas em 31 de julho

Este capítulo descreve um processo que não está rodando. Ele fica no caderno porque as etapas continuam sendo a melhor descrição do que precisa acontecer antes de enviar, e porque o P4 antigo ainda depende delas — é por isso que ele falha.

Do processo inteiro sobrou o P3.3, o plano de capacidade das 06h45, cujo último status é erro, e uma rotina de pesquisa às 23h30. O portão do P3.5, que era a peça mais bem feita do Dexter, não emite veredito desde 30 de julho.

O V4 não usa nada disto. Ele substituiu o controle por dia por um controle por item, descrito em P4.

Etapas

O que ele fazia, passo a passo

P3.1

Preparo da noite

Entre 20h05 e 06h45 monta o estoque do dia seguinte, com contatos pesquisados e prontos, sem enviar nada.

P3.2

Pré-plano por telefone

Às 20h30 define o horizonte: 120 contatos prontos na abertura, 180 pesquisados até as 09h, e cobertura planejada para a meta de 300.

P3.3

Plano de capacidade dos comunicadores

Às 06h45 calcula quanto cada operador e cada telefone aguentam no dia.

P3.4

Isolamento final

Às 05h15 fecha o preparo. Nada é enviado, nada é enfileirado e nada é escrito no CRM nesta etapa.

P3.5

Emite o veredito do dia

Confere idade dos dados, posse do bloqueio, integridade de cada arquivo do plano, telefones planejados e capacidade. Só então libera. Na dúvida, bloqueia.

O princípio
Hash autodeclarado não é proveniência. Comentário no código do portão do P3.5, que recusa por padrão e recalcula a integridade em vez de acreditar no arquivo. Entrada inválida vira recusa, nunca erro. É o modelo a copiar quando desenharmos o controle único.
Correção do caderno
A falha que este capítulo descrevia já não existe

A versão de 30 de julho atribuía a quebra do P3.1 a um caminho de arquivo escrito errado — release-authority.json com hífen, na pasta errada. Esse defeito foi corrigido: não há mais nenhuma referência ao caminho torto na árvore ativa.

A etapa continua parada por outro motivo, que é o desligamento de 31 de julho. Ficou registrado aqui para que ninguém gaste tempo caçando um bug que já foi resolvido.

Para a decisão

O que fazer com o P3

Há três saídas, e a escolha é de desenho, não de código. Aposentar: assumir que o controle por item do V4 substitui o controle por dia, e apagar este capítulo. Reduzir: manter só o plano de capacidade, que é o que o V4 não tem, e descartar o resto. Religar: voltar o processo inteiro, o que exige antes decidir quem manda quando o portão do dia e as guardas do V4 discordarem.

O que não dá para manter é o estado atual, em que o processo está desligado mas outro processo ainda depende dele.

P4

Despacho de mensagem

Tirar o próximo envio da fila, respeitar os limites de cada telefone e entregar no WhatsApp com comprovante. Desde 31 de julho, por dois caminhos ao mesmo tempo.

Dispara quando
V4 a cada 30 minutos, na janela de 07h às 19h. Worker antigo a cada 1 minuto
Entrada
Fila de envios. O V4 valida por item; o worker antigo espera o veredito do P3
Saída
Mensagem entregue, com identificador do WhatsApp
Conclui quando
O envio tem comprovante do WhatsApp e o contrato de CRM fechado
Dois caminhos

O V4 é quem entrega; o worker antigo continua ligado e falhando

Este capítulo passou a descrever dois processos que fazem a mesma coisa. O V4, no ar desde 31 de julho, entregou 130 mensagens no dia da revisão. O worker antigo, descrito nas etapas P4.1 a P4.6, falha em toda execução porque depende dos marcos do P3, que foram desligados.

Os dois leem a mesma fila. Nada no ambiente declara qual é o oficial.

V4 · etapas

O caminho que está entregando

V4.1

Confere se há telefone saudável

Sem nenhuma linha conectada, o ciclo termina aqui e não valida nada. É a única dependência dura que ele tem de outro processo, o P6.

V4.2

Respeita a janela comercial

Fora do intervalo de 07h às 19h no horário de Brasília, nada é validado. A janela é a única noção de “dia” que sobrou depois do P3 sair.

V4.3

Confirma o estágio no CRM, item a item

Para cada mensagem na fila, consulta o negócio no HubSpot e verifica se o estágio dele corresponde ao tipo de mensagem que está prestes a sair. Um follow-up F3 só passa se o negócio estiver de fato em F3. Diverge, não envia.

V4.4

Respeita o dono do lead

Cada lead fica ligado ao telefone que falou com ele primeiro, e esse vínculo é a autoridade sobre quem pode continuar a conversa. Consulta o mapa autoritativo, não só a fila local, para enxergar também os envios do sistema antigo.

V4.5

Respeita a janela de 20 horas

Confere no histórico de auditoria quando aquela pessoa foi contatada pela última vez, mesmo que o contato tenha saído pelo caminho antigo, e segura o envio se for cedo demais.

V4.6

Reivindica o envio antes de mandar

Marca a linha da fila como sua, com dono e prazo de validade de 10 minutos. Se o processo morrer no meio, a reivindicação vence e o item volta a ficar elegível — sem duplicar, porque quem já tem comprovante nunca é reivindicado de novo.

V4.7

Entrega e guarda o comprovante

Envia pela ponte do telefone, no máximo 50 por ciclo e com 4 segundos entre mensagens, captura o identificador do WhatsApp e entrega a linha ao fechamento de CRM com os passos que faltam nomeados um a um.

Worker antigo · etapas

O caminho que está parado

P4.1

Produz o plano da rodada

Monta sete arquivos: frota de telefones, plano de capacidade, fila do dia, marcos, portas planejadas, autorização e o índice de tudo isso.

P4.2

Normaliza a frota

Corrige o formato dos números e recalcula a integridade dos arquivos recém-produzidos.

P4.3

Consulta o portão do dia

Pergunta ao P3.5 se está liberado. Se a resposta for não, a rodada para aqui. É aqui que ele morre hoje, porque o P3 não emite mais veredito.

P4.4

Confere a autorização de versão

Antes de enviar qualquer coisa, valida que a versão do código em execução é a autorizada, com o ponto de entrada e o portão no lugar. Qualquer coisa fora do lugar interrompe.

P4.5

Envia respeitando os limites

Até 21 telefones por rodada, 2 mensagens por telefone, 8 por hora por papel, intervalo mínimo entre mensagens e janela de 20 horas entre contatos com a mesma pessoa.

P4.6

Valida a rodada

Uma rotina de IA confere cada rodada: se o papel certo falou com o contato certo, se não houve duplicidade, se a sequência ficou completa. Ao encontrar sequência quebrada, coloca em quarentena e não reenvia. Continua rodando, e é hoje a principal fonte de diagnóstico do despacho.

Estado da fila
Tipo de mensagemNa filaEnviadasFalhasBloqueadasEm revisão
Follow-up F21.597474162180229
Follow-up F41.361311138996
Follow-up F38804991654319
Follow-up F14694776524618
Envio de diagnóstico282642614128
Primeiro contato2561200

Comparado a 30 de julho, todas as filas cresceram. O primeiro contato continua com um único envio: o V4 está drenando follow-up e diagnóstico, não o topo do funil.

Falhas ativas
Cinco problemas conhecidos
  • O worker antigo falha em toda execução. Ele para no P4.3 reclamando dos marcos das 05h15, 06h20 e 06h45 que o P3 deixou de produzir. Continua ligado, a cada minuto, sem chance de sucesso.
  • 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 ficam 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. Ela só existe porque a rotina de validação do 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.
  • 301 envios estão retidos para revisão, e ninguém resolve a pendência. Eram doze no levantamento, todos de uma sequência interrompida. O sistema preserva a prova e se recusa a reenviar, o que está certo — mas a pilha cresceu vinte e cinco vezes.
Achado
O V4 é o executor que o modelo alvo pedia

A etapa V4.6 faz, no caminho crítico, exatamente o que este caderno propunha: reivindica um item com dono e prazo, recupera sozinho quando o processo morre no meio, e só considera concluído o que tem comprovante. É a segunda peça do Dexter a fazer isso, depois do P5.3.

Falta a terceira parte: o registro continua num arquivo dentro da máquina. Dois processos agora sabem reivindicar; nenhum dos dois reivindica num lugar que outra máquina enxergue.

P5

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.

Dispara quando
A cada 1 minuto para escuta, a cada 5 minutos para progresso
Entrada
Mensagens recebidas nos 21 telefones
Saída
Uma obrigação de resposta por mensagem recebida
Conclui quando
Respondido com prova, escalado para humano ou silenciado de propósito
Etapas

O que ele faz, passo a passo

P5.1

Escuta as respostas

Lê as mensagens que chegaram. Roda um ciclo por minuto e, se sobrou fila, avisa que há trabalho pendente e retoma exatamente de onde parou no minuto seguinte.

P5.2

Transforma em obrigação

Cada mensagem recebida vira uma obrigação de resposta, com telefone, conversa e momento.

P5.3

Reivindica o turno

Antes de responder, marca o turno como seu, com prazo de validade e contador de tentativas. É o mecanismo mais maduro do Dexter e o mais próximo do que queremos generalizar.

P5.4

Registra silêncio intencional

Nem toda mensagem pede resposta. Quando a decisão é não responder, isso fica registrado como escolha, não como esquecimento.

P5.5

Completa o CRM

Leva para o HubSpot o que aconteceu na conversa.

P5.6

Revisão reflexiva

De 6 em 6 horas, uma rotina de IA relê as conversas em modo somente leitura e avalia a qualidade do atendimento.

Situação
Situação da obrigaçãoQuantidadeSignificado
Respondidas2.267o lead recebeu retorno
Silêncio intencional1.153decidiu-se não responder, e isso está registrado
Escaladas337passaram para tratamento humano
Aguardando resposta100ainda em aberto
Pausadas18bloqueadas por pausa deliberada
Achado
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.

Falha ativa
O retry parou de tentar

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.

Esses números são exatamente os mesmos de 30 de julho, cinco dias depois. A versão anterior deste caderno concluiu que o sistema tentava indefinidamente; estava errado. As duas rotinas responsáveis pela nova tentativa foram desligadas em 29 de julho, e desde então os 108 turnos não estão em loop — estão abandonados, sem ninguém para retomá-los nem para escalá-los.

Capítulo P5← P4P6 Canal →
P6

Sustentação do canal

Manter os 21 telefones conectados e o painel no ar. Nenhum dos outros processos funciona sem este — e o V4 depende dele mais do que qualquer outro.

Dispara quando
Entre 1 e 15 minutos, em onze rotinas de vigilância
Entrada
Inventário de telefones cadastrados
Saída
Linhas conectadas, painel e histórico disponíveis
Conclui quando
Cada telefone habilitado responde saudável
Etapas

O que ele faz, passo a passo

P6.1

Lê o inventário de telefones

O cadastro de chips é a fonte única, então cadastrar, trocar ou remover número na tela passa a valer sem mexer em código. Se o inventário não carregar, o processo para, em vez de inventar telefone ou ressuscitar lista antiga.

P6.2

Religa as linhas que caíram

Verifica cada telefone e sobe o que estiver fora, respeitando a lista de chips propositalmente pausados.

P6.3

Reimporta o histórico

Traz para o painel as mensagens que chegaram por outros caminhos, para a visão ficar completa.

P6.4

Garante o painel

Mantém o painel de conversas no ar, na versão pública e na interna, sem nunca subir duas instâncias na mesma porta.

P6.5

Revalida os chips

Confere se cada número continua autenticado e com identidade correta.

P6.6

Vigia desempenho e segurança

Acompanha performance e integridade da camada de canal, e mantém o acesso externo desligado quando a trava de segurança está ativa.

Nota
Onze rotinas, uma pergunta

As onze rotinas deste processo fazem a mesma pergunta onze 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, com um processo para onze alvos em vez de onze processos.

Ficou mais crítico do que era. O V4 encerra o ciclo sem validar nada quando não encontra telefone saudável, então este processo virou a condição de partida do despacho inteiro.

P7

Relato para pessoas

Tudo que produz saída para gente ler: auditoria do funil, agenda de reuniões, exportações e alertas. O relatório executivo da manhã saiu do ar.

Dispara quando
Horários fixos, mais três rotinas de 15 minutos
Entrada
Artefatos do dia produzidos pelos processos P1 a P6
Saída
Relatórios, alertas e a agenda do dia
Conclui quando
O relatório foi entregue ao destinatário
O que é produzido
EntregaQuandoPara quem, e o quê
Auditoria do funil08h, 12h, 16hAlerta quando o funil sai do esperado.
Reuniões do dia07h + 3 tentativasLucas Resende. As três tentativas extras são um mecanismo improvisado de nova tentativa.
Reconciliação Rafael e Lucas15 minConfere se o que foi prometido aos dois saiu.
Fila de follow-up do SDR15 minFoto do que está pendente.
Aprendizado por chip15 minRetrato do comportamento de cada telefone e operador.
Alertas de fim de semana2 minA rotina que mais se aproxima da frequência declarada.
Relatório financeiro e exportação08h e 18h30Enviados ao Mitra.
Relatório diário profundo06h50Desligado em 31 jul. Era a entrega executiva do Rafael, montada sobre os artefatos do dia.
Teste de contingência por chip06h20Desligado em 31 jul. Auditoria de inventário, capacidade e filas.
Falha ativa
Quem acompanhava o dia ficou sem instrumento

As duas entregas da manhã saíram do ar no mesmo minuto em que o P3 foi desligado. O que restou são alertas por exceção e fotos parciais de fila. Não existe hoje nenhuma entrega que responda “como foi o dia” para uma pessoa.

Isso importa mais agora do que importava em julho: com dois caminhos de despacho convivendo, a única forma de saber o que saiu é ler o banco.

Nota
Silêncio significa sucesso

A regra de comunicação hoje é que a rotina só fala quando algo deu errado. A convenção é boa, mas está aplicada de forma desigual, e um recado importante pode se perder no mesmo canal em que caem erros técnicos repetidos.

§

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. O V4 já separou dois deles, sozinho e sem combinar.

Os papéis

Os três papéis

1

O gestor, que é o agendamento

Roda de tempos em tempos e faz só duas coisas: olha o que precisa ser feito e reivindica; e verifica se algum executor morreu no meio, para recuperá-lo. Ele nunca faz o trabalho, então termina em segundos, e a frequência declarada volta a ser verdade.

2

O executor

Recebe um item e o leva até o fim, fora do relógio. Pode demorar 14 minutos sem atrapalhar ninguém, porque não ocupa o agendamento. Cada executor é independente dos outros.

3

O controle único

Um lugar só, fora da máquina, onde fica registrado que este item foi reivindicado, por este executor, neste momento, e terminou assim. É o que permite recuperar sem duplicar e auditar sem adivinhar.

Precedente
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 disparo 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 já tem duas das três peças, e ganhou a segunda em 31 de julho: o P5.3 reivindica turnos de conversa e o V4.6 reivindica envios, os dois com dono, prazo e recuperação. O que falta é a terceira. Nenhuma das 103 rotinas registra trabalho fora da própria máquina.

Peças prontas
PeçaOnde estáO que já garanteO que falta
Reivindicação por enviono V4.6Dono, prazo de 10 minutos, recuperação automática quando o processo morre, e conclusão só com comprovante.A marca vive num arquivo da máquina. Duas máquinas não conseguiriam dividir a fila.
Reivindicação por turnono P5.3Dono, prazo, tentativas, reelegibilidade e estado final com prova.Quem retomava foi desligado em 29 de julho, então hoje ninguém recupera o que vence.
Validação por item contra o CRMno V4.3Confere o estágio do negócio antes de cada mensagem, em vez de liberar o dia inteiro de uma vez.Convive com o portão por dia do P3 sem que ninguém tenha declarado qual manda.
Portão com recusa por padrãono P3.5Verificação independente, sem confiar no que o arquivo declara. Nunca quebra.Está desligado desde 31 de julho. O motivo da recusa nunca foi preservado.
O alvo
ProcessoUnidade de trabalhoEstado finalExecutor pronto?
P1 Aquisiçãoum leadqualificado ou descartadonão
P2 Qualificaçãoum item abertoMQL ou não-MQLnão
P3 Planejamentoum dialiberado ou bloqueado, com provadesligado
P4 Despachoum envioentregue com comprovantesim, no V4
P5 Escutaum turno de conversarespondido com provasim, sem retomada
P6 Canalum telefonelinha saudávelparcial
P7 Relatoum relatórioentreguenão
Em aberto
O requisito não está na ferramenta. Está em ser um só lugar, fora da máquina, com unicidade garantida pelo próprio sistema. Onde fica o controle único ainda é decisão. Pode ser o GitHub, como na Zoe; um banco próprio; ou o HubSpot para os processos de lead. O que não serve é uma verificação feita em memória antes de gravar.
§

Como propor um ajuste

Este caderno existe para ser corrigido. Foi montado lendo o ambiente, não perguntando às pessoas.

Cite o código

Cada processo tem um código e cada etapa tem um número. As etapas do caminho novo de despacho usam V4.x para não se confundirem com as do worker antigo, que seguem P4.x. 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 caderno 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.
A revisão

As três perguntas que mais ajudam

1

O recorte está certo?

São sete processos mesmo, ou algum deveria ser dividido, unido ou eliminado? Esta é a decisão mais importante, porque tudo depois deriva dela.

2

A unidade de trabalho está certa?

Para cada processo: qual é a menor coisa que pode ser feita do começo ao fim de forma independente? É isso que o executor vai receber.

3

Quando se pode dizer que terminou?

Qual é a prova de que aquele item foi concluído? Sem essa resposta, não há como recuperar sem duplicar.

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 de gestor mais executor.

A ordem sugerida mudou desde julho. O despacho já foi: o V4 é o executor que faltava, e o que resta ali é tirar a marca de dentro da máquina e decidir o destino do worker antigo. As três primeiras decisões agora são outras:

  • Confirmar se a pausa de 31 de julho foi decisão. Tudo o mais depende disso.
  • Fechar a unicidade no banco. Era a trava 3 e virou a mais urgente, porque o freio acidental que a segurava — o portão fechado — não existe mais.
  • Devolver um instrumento de acompanhamento. Sem as entregas da manhã, ninguém consegue dizer como foi o dia sem ler o banco.

Depois disso, a escuta (P5) segue sendo a candidata natural, porque já tem a reivindicação pronta e só precisa de quem retome.