Nas lojas que operamos, tem um padrão que a gente vê o tempo todo. O painel HRM mostra que você tem 12 unidades de água 1,5L em estoque. Você confia. Vai lá e encontra três. Desaparece um item por dia, silenciosamente, sem gerar ruptura, sem ativar alerta no app. E a margem some com.

Esse problema não é furto. Ou melhor: é, mas invisível pro sensor de peso. E mata mais rápido que qualquer balanço desequilibrado porque você não vê vindo.

O que seu painel conta, mas seu estoque físico nega

Começa assim: um cliente escaneia um produto, paga pelo código, e leva embora. O painel registra uma venda, diminui a contagem lógica. Tudo correto até aqui. Mas aí aparecem três vazamentos que ninguém discute com franqueado novo.

Primeiro: cliente escaneia produto A, paga, e leva produto B. O app debita A, mas B saiu da gôndola sem gerar débito. Segundo: produto cai da prateleira, fica embaixo da geladeira, ninguém recoloca, código nunca sai do sistema. Terceiro: produto entra com código digitado errado no recebimento. O sistema acha que tem duas unidades. Na verdade tem uma, mas a lógica não sabe.

Esses três juntos, numa loja com ~200 SKUs, comportam-se como pequenos vazamentos. Individualmente, parecem nada. Semanalmente, você tá perdendo entre R$ 40 e R$ 80 só nesse ruído.

Por que o sensor de peso não captura isso

O sensor pesa a gôndola. Se a massa bate com o esperado, sensor fica mudo. Só grita se faltar peso. Mas faltar peso não é o mesmo que faltar inventário lógico. Você pode ter três garrafas de água embaixo da prateleira (peso ali, mas fora de venda) e o sensor não mexe um dedo. O painel diz que tem 12. Você vende duas. Sua métrica de ruptura fica calma.

Enquanto isso, cliente chega e não encontra a água. Ele não vai gritar pro seu painel. Ele vai comprar em outro lugar.

Onde o dinheiro some entre a contagem e a venda real

Vimos isso numa loja de ~120 unidades habitadas numa região corporativa em Brasília. O franqueado reabastecia de manhã cedo. Painel dizia que ruptura era 8%, bem acima do aceitável. Mas quando a gente entrou no rastreamento manual, descobriu que 60% da ruptura não era furto nem falta de reposição. Era dessincronia entre o que o sistema esperava estar lá e o que realmente estava à venda.

Resultado: ele tava comprando errado. Pedia muito de um SKU que nunca movia porque a contagem lógica inflava o desempenho dele. Deixava outro SKU com falta porque o painel não enxergava que ele saía da prateleira derrubado antes de virar venda.

Numa operação onde margem bruta gira em torno de 35%, cada ponto percentual de dessincronia come 2,5% do lucro líquido.

Como seu app ignora produto fora de lugar

O painel Be Honest captura venda, gera inventário lógico, alimenta reposição automática. Tudo por código de barras e peso. Mas existe um momento cego: entre o cliente escanear (venda registrada) e o produto sair fisicamente da loja (sem câmera em cada prateleira, é lento saber quando saiu mesmo). Se ele saiu da prateleira mas continua na loja, preso atrás da geladeira ou numa caixa que virou e ficou embaixo, o app segue a vida. Continua contando como estoque.

Quando você reabastece, tira 12 unidades de uma caixa e coloca na gôndola. O painel vê 12 saindo do backstock e entrando em estoque de venda. Perfeito. Mas se três delas ficam caídas no chão da loja e ninguém levanta, seu painel acha que tem 9 vendidas. Na verdade tem 3 desaparecidas sem gerar lucro.

O custo real de não sincronizar manual com painel

A maioria das lojas autônomas faz contagem física uma vez por mês. Errado. Isso deixa uma janela de quatro semanas pra dessincronia crescer. Se você tá perdendo R$ 10 por dia em dessincronia pura (não furto, dessincronia), vai acumular R$ 280 até a próxima contagem.

O padrão Be Honest que funciona realmente bem faz uma rápida (5 a 10 minutos) duas vezes por semana. Só nos SKUs que o painel marca como críticos: água, café, suco, snack salgado. Não precisa contar tudo. Mas esses cinco itens que movem 65% do ticket precisam bater painel com realidade a cada 72 horas. Assim, quando você descobre uma dessincronia, ela tem no máximo três dias de crescimento. Você corrige antes que vire R$ 200 perdidos.

Quando corrigir, antes de pedir reposição

Se seu painel diz que tem 15 unidades de um SKU e você chega na loja e conta sete, não é dia pra pedir reposição. É dia pra investigar onde estão os oito que faltam. Pode ser produto caído. Pode ser cliente que escaneia, tira o item da prateleira, muda de ideia e coloca em outro lugar. Pode ser digitação errada na última reposição. Qual for, você precisa saber antes de mandar compra pro distribuidor.

A gente operou uma loja em um condomínio em Salvador onde tínhamos essa prática: antes de qualquer reposição autorizada pelo painel, a gente fazia uma varredura visual rápida de cinco minutos. Você ia atrás da geladeira, verificava se tinha item que saiu de estoque sem ser vendido, recontava. Isso cortou em 40% a dessincronia mensal. Resultado: menos compra desnecessária, menos estoque parado, melhor cashflow.

O que ninguém fala: dessincronia é pior que furto documentado

Furto gera perda. Você sabe qual é. Faz nota fiscal de devolução, deduz do imposto se conseguir documentar, fecha a conta. Dessincronia gera dois problemas: perda real (produto sumiu) mais erro de gestão (você continua pedindo como se tivesse em estoque). Essa combinação mata mais margens que furto óbvio.

Pra validar se sua loja tá com problema de dessincronia, comece daqui: pegue o painel HRM dos últimos 30 dias, imprime o relatório de estoque. Depois faz uma contagem física de verdade (leva uma hora, máximo). Compara número por número. Se achar mais de 5% de dessincronia em SKUs que movem mais de 10 unidades por dia, tem vazamento de sincronismo acontecendo agora mesmo.

Não é problema de tecnologia. É problema de procedimento. O app funciona. Mas funciona só quando o operador fecha a lacuna entre o que o sistema espera e o que a prateleira realmente tem. Isso é trabalho. Manual. Chato. Mas é a diferença entre rodar uma loja que bate no faturamento estimado e uma que mistério um terço do lucro todo mês sem saber por quê.