Três motivos pelos quais o dado do seu varejo nunca dá o número certo
SaaS espalhado, BI engessado e operação manual. Os três modos de falha que ouvimos de todo operador de varejo no Brasil, e o que a gente constrói para cada um.
por Zechim
Todo operador de varejo com quem a gente conversa tem uma versão da mesma queixa: ninguém na empresa concorda sobre a margem por SKU. O financeiro tem um número, o painel do marketplace tem outro, e o gerente de loja tem um terceiro que veio de uma planilha que alguém montou em 2023.
Isso não é falta de disciplina. É um problema de arquitetura, e ele aparece em três formatos previsíveis.
1. O dado está espalhado em sistemas que nunca foram feitos para conversar
Shopify ou Magento na vitrine. Bling, Tiny ou Omie no back office. Pedido de marketplace chegando por uma API com documentação incompleta ou errada. Custo de logística no portal da transportadora. E uma planilha que o financeiro mantém na mão para conciliar aquilo que os sistemas discordaram no mês.
Cada uma dessas ferramentas é boa no que faz. Nenhuma foi desenhada para responder "quanto a gente realmente ganhou nesse pedido". A margem por SKU mora nos vãos entre elas, e é nos vãos que gente faz conta.
O que a gente constrói: uma camada de dados que puxa de cada fonte em rotina e aterrissa tudo em um warehouse com formato consistente. Não é trocar tudo. Seu ERP continua sendo seu ERP. O que muda é que finalmente existe um lugar onde o pedido, o custo, as taxas, o frete e a devolução são a mesma linha.
A verdade sem glamour é que essa etapa, o encanamento, é a maior parte do trabalho e nada da demo. É também a etapa que todo mundo pula antes de se perguntar por que o projeto de IA não produziu nada. A gente escreveu sobre esse modo de falha em IA sem fundação de dados.
2. O BI responde as perguntas do trimestre passado
Você comprou Power BI ou Metabase. Alguém montou 200 dashboards. Estavam corretos no dia em que subiram.
Aí o negócio mudou, e agora toda pergunta nova vira um chamado. O time comercial quer saber quais clientes pararam de comprar há sessenta dias. O comprador quer saber quais categorias estão carregando estoque para a próxima temporada. O chamado fica uma semana na fila do time de dados, e quando a resposta chega a pergunta já passou. Então as pessoas param de perguntar, e a ferramenta cara de BI vira um print mensal em apresentação.
O que a gente constrói: uma camada conversacional sobre o warehouse. A pessoa escreve "top cinco SKUs por margem neste mês" ou "pedidos parados há mais de três dias" e recebe um número, uma lista ou um gráfico. O agente escreve o SQL, roda contra o seu dado e mostra tanto a resposta quanto a query que usou, para um analista poder conferir.
Isso não substitui BI. Dashboard continua certo para as métricas que você olha todo dia. O que ele substitui é a fila de chamados, que é onde o gargalo realmente está. Dá para testar o padrão com dado fictício na nossa demo ao vivo.
3. Software deveria estar fazendo o trabalho que gente está fazendo
Lançar produto. Reclassificar SKU depois de mudança de taxonomia. Empurrar atualização de preço em quatro canais. Conferir se o pedido de ontem foi mesmo pago. Vigiar o anúncio do concorrente.
Nada disso exige julgamento. Tudo isso exige atenção, que é justamente por que acaba na mão de uma pessoa, e por que é feito de forma inconsistente e atrasada.
O que a gente constrói: agentes que cuidam do laço mecânico continuamente e escalam as decisões de julgamento. Dois exemplos que aparecem muito no varejo e que não estão no catálogo do que construímos para varejo:
Antifraude conversacional. Um pedido bate na regra de risco. Hoje ele fica na fila até um analista chegar, e o cliente legítimo espera. Um agente pode abrir a conversa no lugar: pedir a documentação, validar identidade e endereço contra as fontes que você já assina, e liberar o pedido ou entregar um caso resumido ao analista. A fila encolhe e o cliente honesto recebe mais rápido.
Conciliação omnichannel. Pedido feito no marketplace, pago por um processador, entregue por transportadora terceirizada, devolvido parcialmente três semanas depois. Quatro sistemas, quatro verdades parciais. Um agente puxa cada lado e fecha a conta. O que era exercício mensal de conciliação vira diário, o que significa achar o vazamento na semana um em vez da semana cinco.
O padrão por trás dos três
Repare que nenhum deles começa por um modelo. Começam por colocar o dado em um lugar só, e depois por botar em cima alguma coisa que responde perguntas ou faz trabalho.
Essa ordem importa. Um agente sem acesso a dado confiável é um chatbot que chuta. O motivo de projetos de IA no varejo travarem quase nunca é o modelo. É que ninguém quis fazer o encanamento primeiro.
Se um desses três formatos descreve a sua operação, trinta minutos bastam para a gente dizer qual deles é de fato o seu gargalo e mais ou menos o que dá para resolver.