Agente de Aquecimento 1-a-1 no WhatsApp

00Veredito executivo (TL;DR)

A sacada que faz isso não tomar ban: o próprio fluxo que o Daniel definiu — manda a 1ª mensagem, e QUANDO a pessoa responde começa o aquecimento — é exatamente o modelo seguro. A gente só aquece de verdade quem respondeu, e o aquecimento acontece dentro da janela de 24h grátis que a resposta do lead abre. Quem fica em silêncio recebe no máximo 1–2 re-toques por template e depois é aliviado para uma cadência leve. Isso protege a reputação dos números E gasta menos.

Prazo, com honestidade: para a Semana da Profissionalização (07–09/jul, daqui a 3 dias) NÃO dá para ter um agente automático de pé e chips aquecidos com segurança. Para essa, no máximo uma versão assistida (templates que já existem + humano no particular). O MVP real mira a Maestria Terapêutica (aula de venda 25/jul) — dá ~3 semanas, prazo realista. A versão completa vem depois, para os lançamentos seguintes (Vida Alinhada, Alinhar pra Crescer, Áxia).

Faixa de custo Estimativa: ordem de grandeza de R$ 1,6 mil a R$ 8 mil por lançamento em mensageria + LLM para ~15 mil leads (o driver é quantos templates pagos a gente dispara; o papo livre dentro da janela é grátis e o LLM é barato), mais ~R$ 300–1.600/mês de BSP e infra. Detalhe na seção 7.

01O que estamos construindo e o fluxo do dono

O agente é um SDR de aquecimento que roda 1-a-1 no WhatsApp particular de cada lead. Ele não vende: ele aquece e leva para a aula ao vivo. A meta única e medível é presença na aula de venda.

Fluxo definido pelo Daniel (respeitado à risca)

1. Lead entra no grupo VIP de WhatsApp do evento (opt-in).
2. O agente manda uma 1ª mensagem proativa no particular (obrigatoriamente um template aprovado — é a única forma de iniciar conversa na API oficial).
3. Quando a pessoa responde, começa o aquecimento: micro-conteúdos diários por ~10 dias, no tom da casa (Bruno Gimenez e Patrícia / "Pathy"), com lembretes e um empurrão forte no dia da aula.
4. Objetivo final: a pessoa presente e ao vivo na aula.

Esse fluxo casa perfeitamente com o modelo seguro. A seção 2 explica por quê.

02O CRUX — modelo de conformidade que não toma ban

2.1 Como a Cloud API oficial funciona Verificado

Três regras da plataforma definem tudo (verificado na doc oficial da Meta, 04/07/2026):

a) Para INICIAR conversa, só com template aprovado. A empresa não pode mandar texto livre para um número "do nada". Tem que ser uma template message pré-aprovada pela Meta, numa categoria:

b) Janela de atendimento de 24h. Quando o usuário te manda uma mensagem, abre uma janela de 24 horas. Dentro dela, a empresa responde com texto livre, quanto quiser, de graça (mensagens "service"). Cada nova mensagem do usuário renova a janela por mais 24h. As respostas livres da empresa NÃO estendem a janela — quem estende é o usuário.

c) Fora da janela, só template (pago). Passadas as 24h sem o lead escrever, para reabrir a conversa você precisa mandar de novo um template — o tal "re-template diário para reabrir a janela".

2.2 Por que o fluxo do Daniel É o caminho que não toma ban

O ponto que muita gente erra: tentar "aquecer" mandando template todo dia para todo mundo, inclusive para quem nunca respondeu. Isso vira anúncio não-solicitado, gera bloqueio e denúncia, derruba o quality rating e mata o número. É aí que se toma ban.

O fluxo do Daniel evita isso naturalmente porque é gatilhado por resposta:

• 1º toque: template (a gente já usa UTILITY na captação — confirmação de vaga, lembrete, material liberado). Um toque só, opt-in, tom de utilidade. Aprova rápido e não queima reputação.
• Quem responde → entra no aquecimento DENTRO DA JANELA DE 24h GRÁTIS. O agente conversa em texto livre, à vontade, sem pagar por mensagem e sem gastar template. Cada resposta do lead renova a janela. É aqui que mora o aquecimento de verdade: papo humano, micro-conteúdo, quebra de objeção, empurrão pra aula.
• Quem não responde: recebe no máximo 1–2 re-toques por template (utility, ângulos diferentes) espaçados, e depois é rebaixado para uma cadência leve (ex.: só o lembrete véspera + dia da aula). A gente não martela template diário em quem está mudo — é exatamente o comportamento que a Meta pune.

Ou seja: o "aquecimento de 10 dias com micro-conteúdo diário" acontece majoritariamente na janela grátis dos que estão conversando, não num disparo diário de template para a base inteira. Isso é o que mantém o quality rating verde e o custo baixo ao mesmo tempo.

2.3 Oficial vs. não-oficial (userbot) — comparação honesta

Recomendação clara: Cloud API oficial. O userbot compensa em operação pequena, "underground", onde perder número é barato. Aqui NÃO: um número que cai no dia 5 de um aquecimento de 10 dias leva junto a presença de milhares de leads na aula — e presença é a métrica que paga o lançamento. A liberdade extra de papo do userbot não vale esse risco, ainda mais porque o modelo oficial já dá papo livre à vontade dentro da janela de quem respondeu (que é justamente quem a gente quer aquecer).

03Componentes do sistema

Arquitetura em camadas. Cada componente é independente e testável.

   Grupos VIP / Diagnóstico / CRM Avalanche
                    │  (ingestão)
                    ▼
        ┌───────────────────────┐
        │  1. INGESTÃO DE LEADS  │  → lista opt-in + tags (segmento, origem, evento)
        └───────────┬───────────┘
                    ▼
        ┌───────────────────────┐        ┌──────────────────────┐
        │  2. MÁQUINA DE ESTADOS │◄──────►│  BANCO DE ESTADO      │ (Postgres)
        │     (por lead)         │        │  lead, evento, msgs   │
        └───────┬───────┬────────┘        └──────────────────────┘
                │       │
      (agenda)  │       │  (evento: lead respondeu)
                ▼       ▼
   ┌────────────────┐  ┌──────────────────────┐
   │ 4. ORQUESTRADOR│  │ 3. CÉREBRO (LLM)      │
   │  régua 10 dias │  │  persona + memória +  │
   │  fila/scheduler│  │  guardrails           │
   └───────┬────────┘  └───────┬──────────────┘
           │                   │
           ▼                   ▼
     ┌───────────────────────────────┐        ┌────────────────────┐
     │  5. CAMADA WHATSAPP (BSP/Meta) │◄──────►│ 6. TEMPLATES aprov. │
     │  envio + webhook de entrada    │        └────────────────────┘
     └───────────────┬───────────────┘
                     │
        ┌────────────┴─────────────┐
        ▼                          ▼
 ┌──────────────┐          ┌────────────────────┐
 │ 7. HANDOFF    │          │ 8. PAINEL MÉTRICAS │
 │   humano      │          │  funil + saúde nº  │
 │ (CRM Avalanche)│         └────────────────────┘
 └──────────────┘

3.1 Ingestão de leads

Origem tripla, já existente na operação: (a) entrada no grupo VIP = opt-in do evento; (b) Diagnóstico do Futuro da Carreira (/api/diagnostico já grava nome, e-mail, WhatsApp, estágio, dor, renda, nível de interesse e o "compromisso de comparecer"); (c) CRM Avalanche / base disparável. A ingestão normaliza o número (E.164), deduplica, registra a origem e o consentimento e aplica tags (segmento = terapeuta/outros, evento, estágio, temperatura). Os dados do Diagnóstico entram como memória inicial do lead — o agente já começa o papo sabendo o estágio e a dor da pessoa, que é ouro pro aquecimento.

3.2 Máquina de estados por lead

Cada lead vive num estado. Transições disparadas por eventos (envio, webhook de resposta, agenda, quality). Estados:

Transições (o fluxo da máquina de estados):

3.3 Cérebro conversacional (LLM)

O motor do papo. Recebe: histórico do lead + dados do Diagnóstico (memória) + persona da casa + guardrails + o objetivo do dia (definido pela régua). Responde no tom Bruno/Pathy.

• Persona: recomendo persona de assistente identificado da equipe ("aqui é a [nome], da equipe do Bruno e da Pathy"), no tom da casa, sem fingir ser o Bruno ou a Pathy em pessoa. É mais honesto, evita o problema de o lead descobrir que "o Bruno" era bot, e mantém o calor. (Decisão do Daniel — ver seção 10.)
• Memória por lead: perfil do Diagnóstico + resumo rolante da conversa (não mandar histórico cru gigante pro modelo; resumir a cada N turnos pra segurar custo e contexto).
• Guardrails (duros, herdados das regras de compliance do lançamento): nunca prometer resultado terapêutico nem faturamento como garantia; preço só o final, sem parcelamento na comunicação; nunca pedir/manusear dado sensível de consultante; não inventar fato sobre a oferta (se não sabe, escala); manter o foco em presença na aula, não vender no particular. Toda saída passa por um filtro de segurança antes de ir pro WhatsApp.
• Classificador de intenção: um passo barato (modelo pequeno) que lê a resposta do lead e roteia: quer confirmar? tem objeção? pediu humano? é dado sensível? é "PARE"? Isso decide a próxima ação sem gastar o modelo grande à toa.

3.4 Agendador / orquestrador (a régua de 10 dias)

Coração da operação. Uma fila com jobs agendados (delayed jobs) por lead: o próximo micro-conteúdo, o lembrete de véspera, o empurrão no dia. Respeita:

• Horário civilizado (ex.: 9h–20h BRT; nada de madrugada — vira denúncia).
• Response-gated: se o lead está na janela (respondeu <24h), manda texto livre grátis; se está fora, decide se vale um re-template (só até o teto) ou segura.
• Ritmo por número: distribui os envios entre os 10–15 chips respeitando o limite/ritmo de cada um (seção 5).
• Dia da aula: sequência reforçada (manhã: "hoje é o dia"; 1h antes: "abrindo a sala"; no ar: "link aqui, tô te esperando").

Exemplo de régua (aula no dia D — micro-conteúdo educativo, viés da casa) no Apêndice A.

3.5 Gestão de templates aprovados

Biblioteca versionada de templates (os 5 UTILITY da captação já servem de base). Cada template: categoria, idioma pt_BR, variáveis, botão, status de aprovação e quality rating do próprio template. O sistema escolhe o template certo por estado do lead e por evento, e para de usar um template cuja qualidade caiu. Trocar de ângulo (5 variações) evita fadiga da base. Submissão e acompanhamento de aprovação via API do BSP.

3.6 Handoff para humano

Quando o lead esquenta ou pede algo sério, o agente para e passa pro closer. Gatilhos: sinal de compra ("quero comprar", "como pago", "qual o valor" com intenção real), objeção forte de preço, queixa/reclamação, desabafo pessoal/sensível, menção a saúde, pedido explícito de falar com humano, ou qualquer coisa fora do script. O handoff cria/atualiza o card no CRM Avalanche com o resumo do papo e o perfil do Diagnóstico, e notifica o closer — que assume no mesmo número. Regra de ouro: na dúvida, escala. Melhor um humano a mais do que o bot pisar na bola num lead quente.

3.7 Painel de métricas

Duas visões:

• Funil: abordados → responderam → aquecendo → confirmaram → compareceram → no-show → (pós) compraram. Taxa de cada etapa, por segmento e por evento. A métrica-rainha é taxa de comparecimento (confirmou→compareceu) e presença total na aula.
• Saúde dos números: por chip — quality rating (verde/amarelo/vermelho), tier de messaging limit atual, volume enviado hoje, bloqueios/denúncias, status (Connected/Flagged/Restricted). É o painel que evita a gente descobrir tarde demais que um número está morrendo.

04Stack técnico sugerido

4.1 Camada WhatsApp: BSP vs. Meta direto

Recomendação: montar sobre um BSP com pricing pass-through (360dialog como primeira opção) pelo ferramental de multi-número, aprovação de template e dashboards de qualidade — que é exatamente o que dói gerenciar na mão com 10–15 chips. Decisão que preciso do Daniel: qual caminho a operação já usa hoje nos disparos oficiais (Meta direto? algum BSP?). Se já tem um BSP, a gente constrói em cima dele e não troca no meio do rio.

4.2 Backend, fila, banco, LLM

• Backend/webhook: Node.js + TypeScript (stack do time). Recebe os webhooks do WhatsApp (mensagens de entrada, status de entrega, mudanças de qualidade) e expõe a API do orquestrador. Alternativa Python se o time preferir pro cérebro — dá pra separar: Node no webhook, serviço Python no LLM.
• Fila / agendador: Redis + BullMQ (jobs atrasados pra régua de 10 dias, rate-limit por número, retries). É o componente que garante "manda o micro-conteúdo do dia 3 às 10h no chip certo".
• Banco de estado: PostgreSQL (já é padrão da casa e da infra da Naia). Tabelas: lead, evento, mensagem, template, numero_chip, consentimento, handoff. Estado da máquina + histórico auditável.
• LLM: modelo pequeno e rápido como cavalo de batalha (ex.: GPT-4o mini, Claude Haiku ou Gemini Flash — todos dão conta de papo PT-BR com persona) para 90% dos turnos, escalando pra um modelo maior só em turno difícil (objeção elaborada, virada de chave). O classificador de intenção roda no modelo pequeno. Custo de LLM aqui é baixo perto da mensageria (seção 7).
• Integrações: CRM Avalanche (handoff + tags), luzdaserra-api/Diagnóstico (memória do lead), lista/sala do evento (detectar compareceu).

05Controle de banimento (operacional) — o coração do crux

Isto não é opcional. É a diferença entre o lançamento acontecer ou a base sumir no dia 5.

a) Quantidade e aquecimento de chips

A doutrina da casa (10–15 números, ~2 mil msgs/dia/número) está certa. Mas: número novo na Cloud API começa no tier de 250 usuários únicos/24h. Você não sai disparando 2 mil no primeiro dia. Ramp obrigatório:

Prático: fazer a Business Verification já (destrava o 2.000 mais rápido) e subir os chips com dias de antecedência ao lançamento, começando devagar e crescendo. Chip aquecido = chip que já mandou volume crescente com qualidade alta e recebeu respostas.

b) Volume e ritmo por número

Respeitar o tier, distribuir o envio ao longo do dia (não rajada), só em horário civil, com jitter (intervalos irregulares, humano). O orquestrador faz isso por design.

c) Opt-in obrigatório

Só toca quem entrou no grupo VIP / preencheu o Diagnóstico / é base própria que pediu contato. Nunca número comprado ou raspado. Opt-in é o que segura denúncia — e denúncia é o que mata número.

d) Monitorar quality rating e bloqueios

O webhook da Meta avisa mudança de qualidade e de status do número. Regras automáticas: chip caiu pra amarelo → reduz volume dele na hora; vermelho / Flagged → pausa envios naquele número e não volta até recuperar; denúncia/bloqueio subindo → revisar o template/ângulo em uso. O painel (3.7) mostra isso ao vivo.

e) Plano B se um número cair

Os leads são atrelados ao lead, não ao chip. Se um número é restringido/banido, o orquestrador remaneja os leads daquele chip para os chips saudáveis e segue a régua sem furo. Por isso 10–15 números e não 2–3: redundância. Manter 2 chips reserva já verificados e aquecidos, fora de rotação, pra entrar se algum cair no meio do lançamento.

06LGPD / consentimento

• Base legal: consentimento (entrada no grupo VIP / Diagnóstico) e legítimo interesse de relacionamento com quem já é da base. Registrar quando, como e pra quê cada lead consentiu (timestamp + origem) — é o que defende a operação.
• Finalidade e minimização: usar o dado só pra aquecer pro evento; guardar só o necessário (nome, número, respostas do Diagnóstico, histórico do papo).
• Opt-out fácil e respeitado na hora: "PARE"/"SAIR" → estado opt_out terminal, nunca mais tocado. Isso também é regra da Meta, não só LGPD.
• Dado sensível: o público é terapeuta e pode mencionar coisas de consultante/saúde. Guardrail duro: o agente não coleta nem armazena dado de sessão/consultante e nunca sugere colar isso em ferramenta genérica (regra de compliance já da casa).
• Segurança: número e histórico em Postgres com acesso restrito; credenciais no cofre do projeto (nada de token em código/log); retenção definida (ex.: expurgar histórico de papo X meses após o evento).
• Transparência: o lead sabe que está falando com um assistente da equipe (persona identificada, seção 3.3) e a quem os dados pertencem (Luz da Serra).

07Custo — drivers e estimativa Estimativa

Os drivers reais

1. Templates pagos (o grande driver): 1º toque + re-toques a silenciosos. Marketing custa mais que Utility; Utility dentro da janela é grátis.
2. Papo livre na janela de 24h: grátis (mensagem do usuário é grátis, resposta service é grátis).
3. LLM: tokens por turno — barato no volume desta operação.
4. BSP + infra: mensalidade fixa.

Estimativa por lançamento (15 mil leads)

Mensal (infra recorrente) Estimativa

Leitura executiva: manter o 1º toque e os re-toques em UTILITY (como a captação já faz) derruba o custo de mensageria de ordem de "R$ 8–13 mil" para "R$ 1,6–3 mil" por lançamento. É a mesma decisão que protege a reputação dos números. Ganha-se nas duas pontas.

08Fases de implementação

09Riscos e mitigações

10Decisões que preciso do Daniel (pra destravar)

1. BSP atual: hoje os disparos oficiais rodam no Meta direto ou em algum BSP? (define se construo em cima do que já existe).
2. Persona: pode ser assistente identificado ("da equipe do Bruno e da Pathy") — recomendação — ou o Daniel quer o tom em 1ª pessoa do Bruno/Pathy? (impacta honestidade e handoff).
3. Alvo do MVP: confirmo Maestria (25/jul) como primeiro lançamento com o agente de verdade? (Semana fica no modo assistido).
4. Chips: quantos números já estão verificados e aquecidos hoje, e em que tier? (define o ramp e se dá pra 15 mil).
5. Orçamento: teto por lançamento pra eu calibrar Utility vs. Marketing e volume de re-toque.

AApêndice — exemplo de régua de 10 dias (aula = dia D)

Response-gated: o que está como "template" só vai pra quem está fora da janela; pra quem respondeu, é papo livre grátis no mesmo tema. Tom da casa, viés educativo, foco em presença.

BApêndice — fontes e verificação

• Pricing per-message desde 01/jul/2025, categorias, janela 24h, service grátis desde 01/nov/2024, Utility grátis na janela, faturamento BRL no Brasil desde 01/jul/2026: doc oficial Meta (developers.facebook.com/docs/whatsapp/pricing), fetch 04/07/2026. Verificado
• Tiers de messaging limit (250 / 2.000 / 10.000 / 100.000 / ilimitado) e critérios de escalonamento: doc oficial Meta (messaging-limits), fetch 04/07/2026. Verificado
• Valores em US$/R$ por mensagem para o Brasil: Estimativa — as páginas de BSP consultadas (Gupshup, 360dialog) não expõem tabela em texto; o número exato está no rate card atual da Meta e na fatura do BSP. Confirmar antes de fechar orçamento.
• Contexto da operação (10–15 chips, ~2k/dia, base 5k→15k, templates UTILITY, Diagnóstico, esteira de produtos e datas): knowledge/luzdaserra/lancamento/maquina-captacao.md, lancamento-atual.md, frentes-e-metas-jun-jul-2026.md.