Pular para conteúdo

Conteúdo Infinito — Estratégia (segmentação, cadência, religamento)

Consolida o pensamento estratégico do sistema — segmentação da base, modelo de cadência, plano de religamento do email e considerações de deliverability. As tabelas técnicas (IDs de filtro, contagens, campos) estão em referencia-tecnica.md; a implementação pendente no WF3 está em arquitetura.md; a cronologia em historico.md.

Fontes consolidadas aqui (originais listados em ARQUIVOS.md): PLANO_RELIGAR_EMAIL_E_ESCALAR_2026-07-03.md, Proposta_RFM_Cadencia_Nutricao_Reativacao_2026-07-03.md (RFM — superada), e a proposta final de 6 clusters (Proposta_Clusters_Cadencia_WhatsApp_2026-07-03.html).

Origem da demanda: reunião de 2026-07-02 com Enrico Bertanha e Gustavo Sander — clusterizar a base do Pipedrive para definir cadência de nutrição (conteúdo) e reativação (comercial) por canal, e dimensionar quantos números de WhatsApp o sistema precisa.

1. Segmentação: por que 6 clusters nativos e não RFM

O Pipedrive já tem campos RFM Segment/RFM Score nativos na Pessoa (modelo clássico de 11 segmentos + "Perdido"), mas eles cobrem só ~805 de ~59.617 pessoas (2,3% da base) e não são recalculados desde a criação em 2024-08-21 — RFM exige histórico de compra, e 95%+ da base nunca fechou negócio. Decisão do Rafael: abandonar RFM por enquanto e segmentar com campos nativos de contagem de negócios, que qualquer pessoa consegue auditar via filtro clicável no Pipedrive.

Os 6 clusters são baseados em won_deals_count, open_deals_count, lost_deals_count e last_activity_date (corte de 2 anos), excluindo Junk e opt-out. Cada cluster é um filtro real e clicável no Pipedrive, não um número calculado à parte.

Cluster Critério N (API, 2026-07-03)
1 — Frio won_deals_count = 0, ativo -2a (funde "nunca abriu" + "já orçou nunca fechou") 20.607
2 — Cliente ativo won = 1, sem outro negócio aberto/perdido, ativo -2a 614
3 — Cliente recorrente won = 1 MAS open > 0 OU lost > 0, ativo -2a 321
4 — Recorrente ativo won >= 2, ativo -2a 481
5 — Cliente adormecido won = 1, sem atividade há +2a 1.017
6 — Recorrente adormecido won >= 2, sem atividade há +2a 228
Total 23.268

IDs de filtro e links em referencia-tecnica.md. Contagem feita via paginação real da API (GET /v1/persons?filter_id=X), não estimativa.

2. Modelo de cadência: um calendário por canal, tipo alternado

Erro corrigido pelo Rafael na v1: a primeira versão definia frequências independentes de nutrição e reativação no mesmo canal (ex.: WhatsApp nutrição a cada 45 dias E reativação a cada 21 dias). Dois relógios independentes colidem — a mesma pessoa recebe as duas mensagens no mesmo dia quando os ciclos coincidem. Imprevisível e difícil de explicar.

Modelo final: cada canal (email, WhatsApp) tem uma única frequência de contato por cluster. O tipo da mensagem simplesmente alterna a cada toque: nutrição, reativação, nutrição… Exemplo — Cluster 4, WhatsApp a cada 18 dias: dia 0 nutrição, dia 18 reativação, dia 36 nutrição… Resultado: cada tipo específico ocorre a cada 2× a frequência de contato, sem colisão possível.

Cluster 1 (Frio) é exceção: só nutrição, sem alternância — nunca fechou negócio, não há relação comercial prévia pra reativar.

Cadência proposta por cluster (calendário único por canal) — tabela completa em referencia-tecnica.md:

Cluster N Email a cada WhatsApp a cada WhatsApp msgs/dia
1 — Frio 20.607 30 dias 120 dias (só nutrição) 171,7
2 — Cliente ativo 614 25 dias 35 dias 17,5
3 — Cliente recorrente 321 15 dias 25 dias 12,8
4 — Recorrente ativo 481 15 dias 18 dias 26,7
5 — Cliente adormecido 1.017 35 dias 55 dias 18,5
6 — Recorrente adormecido 228 21 dias 25 dias 9,1
Total 23.268 — — ≈ 256/dia

3. Dimensionamento de WhatsApp

256 msgs/dia ÷ 30 msgs/dia/número = 8,5 → 10 números recomendados (~15% de folga). Hoje o Conteúdo Infinito opera com 6 (Vendas1-6) — faltam 4.

Achado que decide a conta: o Cluster 1 (Frio) sozinho carrega ~172 msgs/dia (89% da base). A conta de quantos chips comprar é decidida pelo tamanho da base fria, não pela riqueza do RFM. Se quiser cortar o número de chips sem sacrificar o atendimento aos clientes reais, o alavanque está em espaçar mais a nutrição do cluster frio — tem efeito desproporcional no total.

4. Status e implementação pendente

Aprovada em princípio pelo Enrico (2026-07-08). Ainda NÃO implementada no WF3 — o WF3 hoje continua lendo frequencia_email/frequencia_whatsapp (mensal/bimestral/semestral, sem distinção nutrição/reativação). Para implementar o calendário alternado, o WF3 vai precisar de:

  1. Um campo por pessoa indicando o cluster atual (ou recalcular via filtro a cada ciclo).
  2. Um campo/estado indicando o tipo do último toque enviado (nutrição ou reativação).
  3. Nova tabela de frequência por cluster substituindo o mapeamento atual mensal/bimestral/semestral.

Próximo passo: Rafael vai abrir uma sessão dedicada só pra planejar essa infraestrutura (não é continuação automática). Ver historico.md, entrada 2026-07-08.

5. Plano de religamento do email (independente do WhatsApp)

Da tarefa "religar nutrição por email e escalar para toda a base" (2026-07-03), mesma reunião. Nada foi ativado/editado — é um plano para Rafael revisar e aprovar antes de qualquer execução.

Diagnóstico

O email não está quebrado — está sem alimentação. WF1 e WF2 estão ativos e saudáveis; o que está desligado é o WF0 (A Ignição), a torneira que cria as atividades. Sem WF0, a fila fica vazia, o WF1 auto-pausa e nada é enviado. Além disso, o email já é arquiteturalmente independente do WhatsApp (o WF2 separa por canal). Religar email sem depender do WhatsApp é possível hoje, com baixo risco — a dependência que existiu foi operacional (pausou-se tudo junto), não técnica.

Como religar

Princípio: feed só-email → fila só-email → WF2 só manda email. O status do WhatsApp passa a ser irrelevante para o email.

  1. Pré-voo (sem enviar nada): confirmar active de WF3/WF4; conferir nutricao_fila limpa; conferir se WF1 está em auto-pausa (resolve sozinho ao aparecer fila).
  2. Ignição só-email: rodar uma versão do WF0 que cria apenas a atividade nutricao___email (condicionar/remover a branch de WhatsApp; editar o WF0 com flag incluir_whatsapp = false ou clonar como "WF0 — Ignição Só-Email").
  3. Lote piloto pequeno: 50–100 pessoas (não os ~15k), validado ponta a ponta.
  4. Validar E2E (protocolo n8n-bepex-teste-pipeline-e2e): abrir as execuções de WF1/WF2/WF3 e conferir os outputs reais, não só o status "success".
  5. Só depois de o piloto passar limpo, seguir para o escalonamento.

Cadência diferenciada por segmento — o bloqueio das frequências

A próxima data é calculada no WF3 lendo frequencia_email da Pessoa, cujas únicas opções são Mensal (30d) / Bimestral (60d) / Semestral (180d). Semanal (7d) e Quinzenal (15d) não existem. Isso bloqueia a cadência semanal desejada para arquitetura.

  • Decisão A — criar as options que faltam no Pipedrive (Semanal/Quinzenal) antes de usar (senão a API rejeita o valor), e estender o freqMap do WF3 (Calcula Próxima Data). Regra da skill: nunca usar fallback freqMap[id] || id — sempre ?? DEFAULT explícito.
  • Decisão B — quem seta a frequência por lead: recomendação é o WF3/WF1 gravar frequencia_email a partir da classificação da IA (arquitetura → Semanal; industrial → Quinzenal, subindo para Bimestral com o tempo). A segmentação por tipo de cliente (arquitetônico/industrial) já existe no WF1 (IA classificadora); o que falta é ligá-la à frequência.

Nota: esta segmentação por tipo de cliente (arquitetônico/industrial) e a segmentação por cluster de contagem de negócios (§1) são ortogonais e precisam ser reconciliadas antes de implementar.

Riscos de deliverability antes de escalar

A conta SES está fora do sandbox (limite 50.000 emails/dia, 14/s). Volume bruto não é o gargalo — o risco real é reputação e aquecimento.

Risco Por quê Mitigação
Domínio de envio errado A nutrição em massa sai hoje por bepex.com.br (domínio corporativo, também usado pelo Hostinger Mail). Pico de volume + reclamações sujam a reputação do domínio do dia a dia. Recomendado: migrar a nutrição para o domínio dedicado bepexmkt.com.br (já verificado, DKIM ok) e reservar bepex.com.br para email 1:1 de vendedor.
Warm-up / rampa Sair de ~0 para milhares/dia de uma vez é o gatilho clássico de spam. Rampa: dia 1 ~50, dobrar a cada 2–3 dias (50→100→250→500→1k…), monitorando bounce/complaint no SES antes de cada degrau.
Bounce / lista suja Base de ~15k tem emails velhos/inválidos; bounce alto derruba reputação. Higienizar a lista antes; monitorar bounce — pausar rampa se bounce > ~5% ou complaint > ~0,1%.
Sem tratamento de bounce/complaint automatizado SES sinaliza via SNS; hoje não há loop que remove automaticamente. Fase 2: assinar bounces/complaints e escrever aceita_comunicacao = 397 para hard bounce/complaint. Obrigatório antes do volume alto.
Volume × conteúdo Cadência frequente × audiência grande = "pool esgotado" rápido → leads saem do fluxo. Esteira de conteúdo alimentando pool_conteudos em paralelo (form Cadastro Pool / WF-Resumo-IA).

Sequência recomendada

  • Fase 0 — Pré-voo: confirmar active WF3/WF4; nutricao_fila vazia; decidir domínio de envio e options de frequência.
  • Fase 1 — Religar pequeno: ignição só-email para 50–100 leads; validar E2E; rampa de warm-up.
  • Fase 2 — Cadência por segmento: criar options de frequência faltantes + estender freqMap; ligar frequencia_email à classificação da IA.
  • Fase 3 — Escalar audiência + conteúdo: abrir a ignição para toda a base elegível em lotes; esteira de conteúdo em paralelo; higienização + loop de bounce/complaint automático.
  • Fase 4 — WhatsApp volta quando pronto: ignição de WhatsApp separada; os canais coexistem sem se derrubar.

Decisões pendentes de Rafael

  1. Domínio de envio da nutrição: bepexmkt.com.br (recomendado) ou seguir em bepex.com.br?
  2. Criar options Semanal/Quinzenal no frequencia_email do Pipedrive?
  3. Aprovar a copy e o volume/rampa antes do primeiro disparo real.
  4. Definir a frequência final por cluster (§2) para montar a nova ignição.

6. Anexo histórico — a proposta RFM (superada)

A versão intermediária da proposta usou o RFM nativo do Pipedrive para os ~805 clientes com histórico transacional e uma segmentação simples (nunca orçou / já orçou nunca fechou) para o restante. Foi superada pela segmentação de 6 clusters da §1 (RFM cobre só 2,3% da base e não é recalculado desde 2024-08). Preservada aqui só como raciocínio de origem — o documento completo (Proposta_RFM_Cadencia_Nutricao_Reativacao_2026-07-03.md) está listado em ARQUIVOS.md.

Achado que sobreviveu à superação e vale reter: 93% do volume de WhatsApp vem dos dois clusters sem histórico de compra (frio + já orçou); os clientes "de verdade" (com RFM) somam só ~6,6% do volume. A conta de chips é dominada pela base fria — consistente com o achado da §3.