CRM de Recuperação de Carrinho Abandonado integrado com IA

Contexto

O Clubinho Corações Preciosos vende assinaturas de livros infantis cristãos para famílias. O negócio não escala com planilhas e WhatsApp manual: cada abandono de checkout exige timing certo (áudio, conversa, link, follow-up humano), cada assinante anual precisa ser contactado antes do vencimento, e cada cobrança Pix recorrente precisa de lembrete sem misturar com a esteira de vendas.

O desafio era construir uma operação comercial integrada — não um CRM genérico — que orquestre pessoas, automação e IA em três frentes distintas, sem que um lead de prospecção receba mensagem de renovação, sem que a Bia venda para quem já é cliente, e sem que pagamento confirmado se perca entre webhooks reenviados.

A solução é uma plataforma orientada a eventos: cada ação externa (abandono, resposta no WhatsApp, link enviado, pagamento AppMax, vencimento de ciclo, Pix a vencer) entra como evento, é processada com idempotência e move o lead na máquina de estados correta. O time opera em filas e kanbans; a Bia conduz a fase automática; closers assumem quando a automação esgota o prazo.

---

Os três módulos

Módulo comercial — Funil 1 (carrinho abandonado com a Bia)

Problema: leads abandonam o checkout e esfriam em minutos. Sem cadência e sem handoff claro, o time perde conversões recuperáveis.

O que faz: recuperação de carrinho abandonado em oito etapas (F1-01 Capturado → F1-08 Convertido). A jornada combina automação (Reportana, Bia) e trabalho humano (closers na Fila do Dia).

Fluxo em linhas gerais:

1. A plataforma de checkout avisa o abandono → lead criado em F1-01.
2. Reportana dispara o áudio inicial → F1-02.
3. O lead responde → conversa com a Bia (assistente de IA via WhatsApp) → F1-03.
4. A Bia qualifica, trata objeções e envia o link → F1-04.
5. Sem pagamento em 24h → handoff para o closer → F1-05 (a Bia para de vender).
6. O closer executa a régua D+1…D+7 na Fila do Dia → F1-06.
7. Sem fechamento em 14 dias → migração para comunidade/webinar → F1-07.
8. AppMax confirma pagamento → baixa atômica, venda registrada → F1-08.

Telas: Dashboard executivo, Fila do Dia, Kanban do Funil 1, Leads, Performance comercial, Inteligência de conversas (objeções detectadas por IA), Cadência, Templates, Integrações.

Diferencial: a Bia consulta o CRM antes de cada turno (can_sell: false para clientes ativos). A cadência tem quatro trilhas (silencioso, inatividade na conversa, pós-link, handoff humano), cada uma ancorada na etapa em que o lead está.

---

Módulo de renovação — Funil 3 (assinatura anual)

Problema: assinantes anuais precisam renovar antes do vencimento. Sem esteira dedicada, renovação compete com prospecção, números comerciais ficam poluídos e o closer não sabe quem priorizar.

O que faz: esteira isolada para clientes ativos com ciclo em subscription_cycles (data de vencimento, número de renovação, plano). Leads do F3 não aparecem na busca global nem no dashboard comercial do F1; vendas de renovação usam is_renovacao = true.

Etapas: F3-01 Vencimento próximo → F3-02 Oferta 1 (valor cheio) → F3-03 Oferta 2 (cupom RENOVA10) → F3-04 Oferta 3 (pagamento inteligente) → F3-05 Renovado, F3-06 Perdido ou F3-07 Bloqueado.

Régua operacional (relativa ao vencimento):

• Prevenção (antes de D0): D-30 valor cheio, D-15 RENOVA10, D-7 pagamento inteligente.
• Resgate (após D0): D+1, D+7 e D+15 com argumentos de resgate; em D+15 sem renovar → F3-06 Perdido.

Entrada na esteira: varredura diária a D-30, importação CSV da base de renovação, ou entrada manual. O CRM avança a etapa conforme o calendário; os toques são manuais na Fila Renovação (prioridade para vencidas e toques pendentes).

Telas: Fila Renovação, Kanban Funil 3, Dashboard Renovação, Importar base.

---

Módulo de cobranças (Pix recorrente)

Problema: assinantes no Pix recorrente precisam de lembrete antes e depois do vencimento, sem misturar com leads em prospecção ou renovação anual.

O que faz: pipeline totalmente separado na tabela crm.cobrancas, sem funil de vendas — kanban próprio C-01 / C-02 / C-03.

Fluxo:

1. C-01 — sistema de assinatura avisa Pix a vencer; n8n envia lembrete “vence amanhã”; CRM registra a cobrança.
2. C-02 — em D+2 (janela comercial 8h–22h), CRM dispara follow-up “ainda em aberto” via n8n → WhatsApp.
3. C-03 — webhook de pagamento confirma a baixa.

Registros de telefones ainda no funil de vendas são removidos do pipeline; pagos antigos saem do kanban operacional.

Tela: Cobranças (kanban + realtime).

---

Arquitetura orientada a eventos

O CRM não é “formulário que guarda status”. É um motor de eventos onde a etapa do lead é consequência do que aconteceu — nunca atualizada manualmente por integrações externas.

Princípios

Mapa de integrações

Renderizando diagrama Mermaid...

Fluxo canônico de um evento

1. Fonte externa dispara (checkout abandonado, mensagem WhatsApp, pagamento AppMax, etc.).
2. n8n normaliza o payload e chama a Edge Function correspondente.
3. A Edge Function valida o token, grava webhook_events (idempotente) e chama a RPC (ingest_*).
4. A RPC aplica a máquina de estados, agenda ou cancela cadência, e em pagamentos executa baixa atômica.
5. Um novo registro em eventos_lead documenta o que ocorreu.
6. O frontend React reflete a mudança via Supabase Realtime e RLS por perfil (admin, gestor, closer, viewer).

A Bia no ecossistema

O agente Bia (workflow n8n) é a interface conversacional do módulo comercial — não o cérebro do CRM:

• Antes de responder, consulta human-takeover (pode_bia_enviar).
• Notifica o CRM em cada mensagem recebida e enviada (webhook-bia).
• Pode agendar pagamento futuro (tool → Edge Function agendar-pagamento).
• Pode escalar para humano (sub-workflow n8n).
• Usa Grok (fallback OpenAI), memória Postgres e buffer Redis para debounce de mensagens.

O domínio crítico (etapas, cadência, vendas, conflitos multi-funil) permanece no PostgreSQL — a IA conversa; o banco governa.

---

Como os três módulos se relacionam

Renderizando diagrama Mermaid...

• Um lead em prospecção (F1) não entra em renovação nem cobrança.
• Um cliente anual entra no F3 na varredura D-30; vendas de renovação não inflam o dashboard comercial.
• Pix recorrente opera em pipeline separado; telefone de prospecção é excluído do kanban de cobranças.
• Conflitos (ex.: lead em F1-05 e tentativa de entrar no F3) são registrados em funnel_conflicts com precedência definida.

---

Stack e decisões técnicas

---

Resultado para o negócio

O time comercial passa a operar com visibilidade em tempo real: fila priorizada, kanban por etapa, performance por closer, objeções detectadas nas conversas com a Bia. A renovação anual tem esteira própria com régua clara de prevenção e resgate. Cobranças Pix não poluem o funil de vendas. E a arquitetura orientada a eventos garante que, mesmo com webhooks duplicados ou integrações instáveis, o estado do lead reflita o que de fato aconteceu — com rastro auditável em cada transição.