App de força de vendas que funciona sem internet

O vendedor está no depósito de um mercadinho no interior, com o comprador ao lado e uma lista de itens para repor. O sinal oscila entre uma barra e nenhuma. O app de pedidos gira, trava e pede para tentar de novo. O vendedor anota no papel, promete mandar o pedido à noite e, quando manda, o preço que ele passou não é mais o que está no sistema.

Numa distribuidora, o app de força de vendas é a ferramenta de trabalho do vendedor externo. Se ele não funciona sem sinal e não conhece as regras comerciais do cliente, o vendedor volta para o papel e o sistema passa a receber pedidos digitados depois, com erro. Este texto trata das duas coisas que definem um bom app para esse cenário: offline de verdade e política comercial no aparelho.

Por que o app genérico de pedidos não aguenta a distribuidora

Existem bons aplicativos de pedido no mercado, e para muitas empresas eles bastam. Os limites costumam aparecer em distribuidoras e atacadistas por causa de regras como estas:

• Preço por cliente, região e canal. O mesmo produto tem preços diferentes para o supermercado da capital e para a mercearia do interior, e às vezes uma tabela negociada só para aquele CNPJ.
• Desconto com alçada. O vendedor pode dar até um certo desconto; acima disso, o supervisor aprova; acima de outro limite, a diretoria.
• Bonificação e verba. Produtos bonificados que consomem uma verba do vendedor ou da indústria parceira.
• Mix mínimo e pedido mínimo. Regras por cliente, por linha de produto ou por fornecedor.
• Crédito e títulos em aberto. Cliente com título vencido não pode receber pedido a prazo, ou precisa de liberação.
• Embalagem de venda. Vende em caixa fechada, em fardo ou em unidade, com conversões e múltiplos.

Quando o app não conhece essas regras, ele aceita o pedido e o problema aparece depois: o pedido trava no faturamento, volta para o vendedor, e o cliente espera. Ou o app fica tão simples que o vendedor precisa ligar para o escritório para confirmar preço e crédito, justamente o que ele não consegue fazer sem sinal.

Quando o sob medida não compensa: se a política comercial é simples (uma ou duas tabelas, sem alçada), se o ERP já oferece um app de pedidos integrado e se os vendedores trabalham com boa cobertura, comece pelo produto pronto.

Offline de verdade: banco local e sincronização incremental

"Funciona offline" tem graus. Muitos apps guardam em cache as últimas telas visitadas e chamam isso de offline. Para o vendedor externo, offline de verdade significa fazer o dia inteiro de trabalho sem nenhuma conexão:

• consultar clientes da carteira, com endereço, histórico e títulos em aberto;
• ver o catálogo com fotos, preços e estoque da última sincronização;
• montar o pedido aplicando todas as regras comerciais;
• registrar visitas, fotos e observações;
• guardar pedidos para envio quando houver sinal.

Isso exige um banco de dados local no aparelho, com uma cópia da parte da base que interessa àquele vendedor: a carteira dele, o catálogo que ele vende, as tabelas de preço aplicáveis.

A sincronização precisa ser incremental. Baixar todo o catálogo e todos os clientes a cada conexão é lento e consome dados móveis. O servidor guarda um marcador de alteração em cada registro, e o app pede apenas o que mudou desde a última sincronização. A primeira carga, mais pesada, acontece no Wi-Fi da empresa ou de casa.

Três decisões de projeto merecem atenção:

Fotos do catálogo. São a parte mais pesada. Baixe em resolução adequada à tela, sincronize em segundo plano quando houver Wi-Fi e permita que o app funcione mesmo sem todas as fotos.

Validade dos dados. O app precisa mostrar há quanto tempo foi a última sincronização, e o preço e o estoque exibidos devem deixar claro que são daquele momento.

Conflitos. Se o escritório alterou o cadastro do cliente enquanto o vendedor editava o mesmo cliente offline, qual versão vale? Defina regras por tipo de dado. Em geral, cadastros mestres pertencem ao ERP, e o vendedor envia sugestões de alteração, não alterações diretas.

A escolha entre nativo, híbrido e PWA pesa aqui: armazenamento local robusto e sincronização em segundo plano funcionam de forma diferente em cada abordagem, e isso está detalhado em app nativo, híbrido ou PWA.

Política comercial no aparelho: tabela, alçada e bonificação

Para o vendedor montar um pedido correto sem sinal, as regras precisam estar no aparelho e ser as mesmas regras que o servidor aplica. Duas implementações diferentes da mesma regra, uma no app e outra no ERP, vão divergir.

Algumas formas de lidar com isso:

• Regras como dados, não como código. Tabelas de preço, faixas de desconto, alçadas e regras de mix são sincronizadas como configuração. O app interpreta; o servidor usa a mesma configuração para validar.
• Validação dupla. O app valida para dar resposta imediata ao vendedor; o servidor valida de novo ao receber, porque a regra pode ter mudado desde a última sincronização.
• Alçada que funciona sem sinal. Um desconto acima do limite gera um pedido pendente de aprovação. O vendedor vê que o pedido depende de aprovação e o cliente sabe disso na hora. Quando houver sinal, a solicitação vai ao supervisor, que aprova pelo celular.
• Verba de bonificação com saldo local, descontada no aparelho e conciliada no servidor, com regra clara para quando o saldo real for menor do que o aparelho achava.

O vendedor precisa entender por que o app recusou algo: "cliente com título vencido desde o dia 12", "mix mínimo da linha de limpeza não atingido". Uma mensagem genérica de erro leva o vendedor de volta ao papel.

Pedido enviado duas vezes: idempotência na sincronização

A conexão cai no meio do envio. O app não recebeu a confirmação e tenta de novo. O servidor, que tinha recebido a primeira tentativa, grava dois pedidos. O cliente recebe a mercadoria em dobro.

O oposto também acontece: o app acha que enviou, apaga o pedido local, e o servidor nunca recebeu. O pedido some.

A solução é idempotência:

• Cada pedido recebe um identificador único gerado no aparelho no momento da criação.
• O servidor usa esse identificador para reconhecer tentativas repetidas e devolver a mesma resposta, sem gravar de novo.
• O app só marca o pedido como enviado depois de receber a confirmação do servidor, e mantém uma fila de envio visível para o vendedor.
• O servidor registra o número do pedido no ERP e devolve ao app, para que o vendedor informe ao cliente.

Um painel de pedidos por status (no aparelho, enviado, recebido, faturado) dá tranquilidade ao vendedor e ao escritório, e acaba com a pergunta "o pedido do cliente X chegou?".

Roteiro de visitas e check-in do vendedor

Além do pedido, o app organiza a rotina do vendedor:

• Roteiro do dia, com os clientes a visitar pela frequência definida para cada um.
• Check-in e check-out com localização e horário, que mostram visitas realizadas e tempo em cada cliente.
• Motivo de não venda: cliente fechado, comprador ausente, estoque cheio, preço da concorrência. Esse dado é valioso e quase nunca é coletado.
• Pesquisa de gôndola e fotos, quando a distribuidora trabalha com exposição ou com indústrias parceiras.

A localização deve servir para a gestão e para o próprio vendedor, não como vigilância. Colete durante o expediente, deixe claro o que é coletado e por quê, e respeite a LGPD.

Quando a empresa também quer gerir oportunidades, negociações longas e o relacionamento com grandes contas, o app de força de vendas passa a conversar com um CRM, tema de CRM sob medida: quando vale a pena.

Integração com o ERP: preço, estoque, crédito e títulos

O ERP continua sendo a fonte da verdade para cadastro, preço, estoque, crédito, faturamento e financeiro. O app é uma extensão dele para a rua. O fluxo típico:

Entre o app e o ERP fica uma camada de integração própria: ela recebe os pedidos com idempotência, valida as regras, enfileira o envio ao ERP e trata as falhas. Se o ERP estiver fora do ar, os pedidos ficam na fila e entram quando ele voltar, sem que o vendedor perceba. Os padrões para essa camada estão em como integrar seu sistema com o ERP.

Muitas distribuidoras combinam o app do vendedor com um portal em que o próprio cliente faz a reposição. O pedido pode entrar pelos dois caminhos, com as mesmas regras e a comissão preservada, como mostramos em portal do cliente B2B.

Distribuição, atualização e o que o gestor passa a enxergar

Distribuição. App interno pode ser distribuído pelas lojas com acesso restrito ou por gestão de dispositivos, quando a empresa fornece os aparelhos. Aparelho da empresa simplifica suporte e segurança; aparelho do vendedor exige mais cuidado com separação de dados.

Atualização. Um vendedor com uma versão antiga do app pode aplicar uma regra que já mudou. O servidor precisa saber a versão de cada aparelho, aceitar as antigas por um período e bloquear as que não são mais compatíveis, com aviso claro.

Perda do aparelho. Os dados locais devem ser criptografados, e o acesso precisa poder ser revogado remotamente.

O que o gestor passa a ver: positivação por vendedor e região, visitas planejadas contra realizadas, motivos de não venda, descontos concedidos e aprovados, tempo entre o pedido e o faturamento.

Erros comuns

• Offline só no discurso, com telas que dependem de conexão para abrir.
• Regras duplicadas em código no app e no ERP.
• Envio sem idempotência, gerando pedido duplicado ou perdido.
• Sincronização completa a cada conexão, lenta e cara em dados móveis.
• Mensagens de recusa genéricas, que o vendedor não entende.
• Não ir a campo com os vendedores antes de desenhar as telas.

Como medir se deu certo

• Proporção de pedidos que chegam ao ERP sem correção manual.
• Tempo entre a visita e o faturamento.
• Pedidos devolvidos por erro de preço, crédito ou regra comercial.
• Positivação e cobertura da carteira.
• Uso real: pedidos pelo app contra pedidos por outros meios.

Checklist do projeto

• Mapear a política comercial completa, incluindo as exceções.
• Definir o que o vendedor precisa ter offline e o volume de dados por aparelho.
• Projetar a sincronização incremental e as regras de conflito.
• Garantir idempotência no envio de pedidos.
• Desenhar a camada de integração com o ERP.
• Testar em campo, em áreas com sinal ruim, com vendedores reais.
• Definir distribuição, atualização e política para aparelho perdido.

Seu vendedor com o sistema no bolso

A Pervian Tech desenvolve apps de força de vendas sob medida dentro do nosso trabalho de desenvolvimento mobile, com banco local, sincronização incremental, política comercial no aparelho e integração com o ERP que a distribuidora já usa.

Começamos por um diagnóstico inicial gratuito: acompanhamos a rotina dos vendedores, levantamos as regras comerciais e avaliamos o que o ERP expõe. Com isso definimos as fases, começando por uma equipe piloto, e o investimento, que é sob consulta. Se os seus pedidos ainda chegam no papel, conte como é a rotina do seu time de vendas.