Case 06 — Desenvolvimento web com IA
Integrador RD Station ↔ SAP
Dados de compras conectados ao CRM para organizar o funil de marketing.
- Stack
- Node.js · TypeScript · React
- Testes
- 676 automatizados
- Chaves de cruzamento
- CNPJ, e-mail, telefone
- Relatórios
- 8 CSVs de auditoria
O desafio
O problema
A base de marketing não sabia quem já era cliente. Leads que compravam havia anos continuavam recebendo campanhas de prospecção, e não havia como segmentar por tempo desde a última compra.
Contexto do projeto
O cruzamento não era trivial: o mesmo e-mail aparecia em várias empresas, CNPJs de matriz e filial se misturavam e telefones mudavam. Qualquer automação precisava ser segura — nunca rebaixar um contato no funil e deixar rastro de cada decisão.
- Gatilho Export da RD
- Dados Cadastro SAP
- Dados Última compra
- Lógica Cruzamento + desempate
- Lógica Simulação
- Entrega Aplica na RD
- Entrega Relatórios
A ferramenta
Um painel para operar a base
A plataforma roda localmente e lê a base da RD Station — ocupação do plano, estágios do funil, contatos bloqueados, bounces, opt-out e desengajados — antes de qualquer ação. A leitura das segmentações acontece como tarefa longa, com progresso e log ao vivo.
O cruzamento
Regras claras para casos ambíguos
Cada contato é cruzado com o cadastro de clientes do SAP por três chaves. Quem tem compra vira Cliente; quem só tem cadastro vira Lead Qualificado. O código do cliente e o histórico de engajamento — ativo, inativo, inativo há um ano ou super inativo — são gravados no CRM.
Ver detalhes desta etapa
Quando as chaves discordam, entram regras de desempate determinísticas. Tudo que não pode ser decidido com segurança vai para revisão humana — e cada decisão fica registrada em relatório.
- CNPJ × e-mail em conflito: vence quem tem compra; se forem matriz e filial, a compra mais recente; persistindo o empate, o CNPJ informado pelo lead.
- E-mail compartilhado: cascata de desempate — único candidato com compra, telefone, semelhança do nome da empresa, compra mais recente — e, por fim, revisão humana.
- Telefone: nunca decide sozinho; só vale confirmado pelo domínio do e-mail ou pelo nome da empresa.
- Funil só sobe: nenhum contato é rebaixado de estágio.
A aplicação
Simular, aplicar, retomar
Antes de escrever qualquer coisa na RD, a plataforma pode rodar em modo simulação: gera exatamente os mesmos relatórios, sem nenhuma escrita. Na aplicação real, mostra progresso ao vivo, ritmo por minuto e tempo restante, e pode ser pausada ou interrompida.
Ver detalhes desta etapa
Um checkpoint por contato garante que, se algo falhar no meio — um erro temporário da API, por exemplo —, a próxima execução reprocessa só o que faltou. Limitadores de requisição, fila por custo e novas tentativas automáticas respeitam os limites da API da RD.
Por dentro
Engenharia de verdade
O núcleo de regras é puro — sem rede nem disco — e separado dos adaptadores de RD Station, SAP, banco e planilhas. O backend usa Node.js com TypeScript, Fastify e SQLite; a interface, React com Vite e Tailwind. A data da última compra vem de uma réplica do ERP com sessão de usuário e regras de acesso por linha; o cadastro de clientes chega por um webhook do n8n, com cache e planilha de reserva.
Ver detalhes desta etapa
São 676 testes automatizados cobrindo regras de cruzamento, desempates, limites de API e checkpoints, além de testes de paridade com a primeira versão do integrador.
Resultado
O que mudou
- 01
O marketing passa a saber quem já é cliente e há quanto tempo comprou — e para de prospectar quem já compra.
- 02
Segmentações por engajamento (ativo, inativo, super inativo) prontas para campanhas de reativação.
- 03
Cada decisão automática é auditável, e o que é ambíguo vai para revisão humana.
- 04
Execuções longas e seguras: simulação antes, checkpoint durante, retomada depois.