A cadeia de planilhas sumiu. O ERP continua onde estava.
Na Sinais Distribuidora, quatro relatórios de vendas por dia eram montados à mão numa cadeia de PROCV sobre o ERP. Reconstruímos tudo na plataforma (CRM, relatório vivo e workflows de importação), sem trocar o ERP e sem um deploy sob medida: um agente autorizado escreveu a configuração dentro do workspace do cliente.
A Sinais é uma distribuidora de atacado (FMCG) com uma operação que qualquer empresário brasileiro reconhece: o ERP guarda tudo e não conversa com ninguém. O relatório que o comercial usa para decidir o dia não sai do ERP pronto. Alguém monta.
O problema: quatro relatórios por dia e uma cadeia de planilhas
Toda manhã, a analista responsável tirava dois exports do ERP e os despejava numa cadeia de quatro planilhas ligadas por PROCV. De lá saíam quatro relatórios diários, de rede e de e-commerce, que iam por e-mail, um a um, para cada vendedor. Cerca de trinta minutos todo dia, sem contar o retrabalho quando alguma coluna vinha fora de ordem.
Cada etapa dessa cadeia era uma decisão que morava na cabeça de uma pessoa: separar o que é venda de verdade do que é devolução e cancelamento (o ERP não filtra por tipo de pedido), classificar cliente por rede e por e-commerce, cruzar com a meta do período e montar os três blocos do relatório final. O Power BI que deveria ter resolvido isso estava defasado e nem cobria a unidade de Perfumaria.
O custo óbvio eram os trinta minutos. O custo real era o risco: se essa pessoa tirasse férias, o comercial ficava sem número.
A abordagem: acertar o número antes de automatizar qualquer coisa
A gente não começou escrevendo código. Começou escolhendo o critério de sucesso: o relatório novo tinha que fechar com o número que a operação já conhecia, ao centavo, no dia. Enquanto não batesse, nada substituiria nada. Automatizar um cálculo errado só faz o erro chegar mais rápido.
A segunda decisão foi não encostar no ERP. Ele fica onde está. De todo o trabalho manual, sobrevive exatamente um passo: subir os exports do dia. Todo o resto some: filtro, classificação, cruzamento com meta, montagem, distribuição.
A terceira foi não congelar o modelo de dados antes de ler um arquivo de verdade. O mapeamento do arquivo é a decisão de modelo; então o catálogo do cliente só nasce depois que o fluxo de importação existe e roda contra um export real.
O que construímos na plataforma
- —Um workspace dedicado da Sinais na plataforma, com o CRM da operação: venda, vendedor, cliente, rede, fabricante, meta e o registro de cada importação.
- —Um workflow de importação ligado ao relatório: a analista sobe os exports, o fluxo separa a venda real, classifica rede e e-commerce, cruza com a meta e grava os registros, com log de auditoria de cada carga.
- —O relatório vivo, montado sobre esses registros: os mesmos três blocos e as mesmas colunas que a planilha tinha, agora calculados na hora da leitura.
A regra de arquitetura por trás disso é simples e é o que faz o resto funcionar: o workflow alimenta registros, o relatório lê registros. Nada é canalizado direto de um para o outro. Como todo mundo lê da mesma base, dá para entregar um único link e ainda assim cada pessoa ver só o que lhe cabe: a gestora vê o time inteiro, cada vendedor vê a própria carteira. Uma definição de relatório, várias visões, nenhuma cópia.
E cada carga de referência guarda de onde veio: nome e data do arquivo que originou aquele valor. Quando alguém pergunta “de onde saiu essa meta?”, a resposta está no registro, não na memória de alguém.
Como construímos: MCP e Claude Code dentro do workspace
Aqui está a parte que mais muda o nosso jeito de entregar. A plataforma Wazari expõe um servidor MCP, o protocolo que deixa um agente de IA usar um sistema de verdade, com ferramentas declaradas, em vez de clicar numa tela. A gente conecta o Claude Code nesse servidor com uma chave de agente construtor presa a um único workspace, e a configuração do cliente é escrita por ali.
Na prática: criar os objetos do catálogo, os campos, as colunas de cada visão, os fluxos de importação e as cargas de referência é uma conversa com o agente, contra o workspace ao vivo. Nada disso é migração de banco, código novo ou deploy. É dado de workspace, autorizado, com trilha. Foi assim que treze dias separaram o primeiro contato da demo aprovada.
O que segura isso de pé são as regras que o agente não pode furar:
- —A chave é presa a um workspace só. O agente que constrói a Sinais não alcança nenhum outro cliente.
- —Dado de cliente vive no workspace e em nenhum outro lugar: não vai para conversa, log, fixture nem repositório. Conferência de carga é feita por forma (contagem e assinatura mascarada), nunca lendo o valor.
- —Fluxo de importação em produção não se altera no lugar: publica-se uma nova versão e religa-se o relatório a ela. O que está rodando continua rodando.
- —Quando o agente esbarra num limite da plataforma, ele não improvisa contorno. Vira ticket de engenharia, e a plataforma cresce um pedaço, para a Sinais e para todo mundo depois dela.
Essa última regra é a diferença entre uma consultoria que empilha gambiarra por cliente e uma agência que fica mais forte a cada projeto. Tudo o que a Sinais precisou e a plataforma não tinha, hoje a plataforma tem.
E como o mapeamento vive numa forma declarada, o caminho seguinte já está desenhado: o copiloto dentro do produto propõe o mapeamento do arquivo, e a pessoa da operação aprova. Mesmo formato, outro autor.
Onde estamos
A reconciliação bateu ao centavo contra o fechamento da operação, e a demo foi aprovada treze dias depois do primeiro contato. Três das seis fases entregues. O trabalho manual diário sai de cerca de trinta minutos para menos de cinco, e essa é a meta que estamos medindo agora. A ingestão automática direto do ERP e a camada de IA em cima do relatório são os próximos passos: não estão prontas, e não vamos dizer que estão.
Preferimos publicar resultado medido a publicar promessa.
Tem um processo parecido na sua operação? Conta pra gente. Em 30 minutos dizemos se um agente pronto resolve ou por onde começaríamos um projeto sob medida.
