GronerZap

Contexto

A Groner é o CRM feito para o setor de energia solar no Brasil — e, no Brasil, a venda acontece no WhatsApp. Até o GronerZap, o canal de WhatsApp do CRM rodava num fornecedor terceiro que custava mais de R$ 30 mil por mês, uma conta que crescia a cada cliente novo.

O problema

• Um custo que escalava do jeito errado. Cada cliente novo aumentava a conta do fornecedor.
• Estabilidade fora do nosso controle. Quedas de conexão e bugs recorrentes que não podíamos corrigir.
• Nenhum controle. A comunicação com o fornecedor era só por webhooks: não tínhamos acesso ao front-end nem ao back-end, e o produto não evoluía com as necessidades dos nossos clientes.

Meu papel

Construí o GronerZap de ponta a ponta: front-end, back-end, infraestrutura, a integração com o CRM e o PWA. A primeira versão, com a Uazapi, entrou no ar em dois meses. Depois adicionei a API oficial do WhatsApp (Meta), a Z-API e um Evolution Go hospedado por nós. Outros quatro desenvolvedores entraram ao longo do tempo, com funcionalidades como as campanhas de disparo em massa, e correções.

Arquitetura

• Front-end — um PWA em Vue 3 + TypeScript. Dentro do CRM, roda num iframe, recebe a sessão criptografada e conversa com o CRM via postMessage; fora dele, pode ser instalado como app no celular ou no desktop, com cache offline e web push.
• Back-end — 100% serverless na AWS, definido com SAM: APIs HTTP e WebSocket no API Gateway, cerca de 150 funções Lambda, filas SQS com filas de mensagens mortas, DynamoDB e S3.
• Entrada — o webhook de cada provedor é normalizado e enfileirado. Um worker identifica o número de WhatsApp, grava a mensagem e a mídia sem duplicar e, em paralelo, encaminha tudo ao CRM e envia para a tela dos atendentes por WebSocket.
• Integração com o CRM — o monólito em C# continua sendo a fonte da verdade: vincula as conversas a leads e negócios, decide o que cada usuário pode ver e cuida do CSAT, das filas de atendimento e dos relatórios.
• Provedor próprio — o Evolution Go roda numa instância EC2 nossa, definida em CDK, com Docker, snapshots, um watchdog do banco de dados e alarmes.

Decisões-chave

• Uma interface, quatro provedores. Todo provedor implementa a mesma interface de cliente, com uma matriz do que cada um suporta, e cada número de WhatsApp escolhe o seu provedor. Adicionar a Z-API e o Evolution Go foi escrever adaptadores, não mexer na inbox.
• A API oficial da Meta como opção. Provedores não oficiais são mais baratos, mas o número pode sofrer restrições; por isso, quem quer risco zero usa a API oficial — e o sistema respeita a janela de 24 horas da Meta e sugere um template fora dela. Nos provedores não oficiais, uma proteção anti-banimento respeita opt-outs, limita rajadas e volume diário e para de enviar quando um número sofre restrição.
• Feito para reprocessar. Toda fila tem fila de mensagens mortas, mensagens de entrada e saída são idempotentes, e um encaminhamento ao CRM que falha fica registrado na própria mensagem para ser reprocessado. Tracing com X-Ray e alarmes sobre os logs acompanham o fluxo inteiro.

A parte mais difícil

Levar centenas de empresas — milhares de pessoas que passam o dia no WhatsApp — para um sistema novo sem quebrar a rotina delas. A estabilidade tinha que ser igual à da ferramenta antiga desde o primeiro dia, enquanto interface, performance e confiabilidade melhoravam; por isso, cada empresa migrou por trás da sua própria flag de beta.

Migrar também significava importar o histórico de cada empresa, e uma importação se desdobrou em 358 execuções paralelas e saturou o banco de dados do CRM. Hoje as importações de histórico rodam em ordem por uma fila FIFO, com concorrência limitada a cinco.

O código foi metade do trabalho. A outra metade foi conquistar a confiança de quem estava acostumado ao jeito antigo.

Resultados

• Mais de R$ 30 mil por mês em custos de fornecedor eliminados.
• O WhatsApp virou um add-on lucrativo: o cliente paga por número conectado, e a infraestrutura custa uma fração pequena disso.
• Centenas de empresas e milhares de usuários no GronerZap.