Nem toda operação de campo precisa de app. Os critérios que eu uso para dizer a um cliente que ele não deveria construir um — e o que fazer no lugar.
Vou começar pelo lado que ninguém escreve: a maioria das operações que me procura pedindo um app de campo não precisa de um app de campo.
Escrever isso não é humildade, é interesse próprio. App construído para uma operação que não precisava dele é o tipo de projeto que fica bonito na entrega e morre em seis meses, e projeto morto não gera indicação.
Então vamos aos critérios.
Se o volume é baixo. Duas ou três coletas por dia não pagam software. Um formulário do Google bem feito, com a resposta caindo numa planilha, resolve por zero real. Não é solução elegante, mas é a solução certa nesse tamanho — e trocar por app não vai mudar o resultado da operação, só o orçamento.
Se o processo ainda muda toda semana. Operação que ainda está descobrindo o que precisa registrar não deve congelar isso em software. Formulário primeiro, por uns dois meses, até o campo parar de mudar. Automatizar processo indefinido é a forma mais cara de descobrir qual era o processo.
Se o problema real é gente, não ferramenta. Se a equipe não registra porque ninguém cobra, ou porque o supervisor também não olha, o app vai ser um lugar mais caro para não registrar. Isso não se resolve com tecnologia, e vender tecnologia nesse cenário é vender esperança.
Se há sinal em todo lugar e o sistema atual já tem app. Muito ERP e muito sistema de gestão já vêm com aplicativo de campo. É comum a equipe nem saber. Vale checar antes de construir qualquer coisa — já vi cliente pagar por um app que ele tinha há três anos incluído na mensalidade.
Quando o dado nasce onde não tem sinal. Galpão, estrada, subsolo, zona rural, ambiente industrial. Aqui a coisa fica binária: qualquer solução que dependa de internet no momento da coleta vai voltar a ser papel na primeira semana. É por isso que “offline” não é um detalhe técnico dessa história — é o requisito que decide se o projeto existe.
Quando o dado é digitado duas vezes. Se alguém no escritório retranscreve o que a equipe registrou na rua, você está pagando duas vezes pela mesma informação e comprando erro no pacote. Essa dupla digitação é o sinal mais confiável de que um app se paga.
Quando o atraso da informação custa dinheiro. Se decidir hoje em vez de depois de amanhã muda alguma coisa — rota, alocação, manutenção, faturamento — então a latência tem preço, e é ele que paga o projeto.
Quando existe obrigação de comprovar. Foto, assinatura, geolocalização, horário. Se você precisa provar que o serviço foi feito, foto solta em conversa de WhatsApp não é prova utilizável. Registro amarrado ao serviço é.
Esse é o ponto onde a maioria dos projetos morre, e é um ponto de desenho, não de tecnologia.
Se a coleta pelo app demorar mais que o papel, o app morre. Sem exceção, sem treinamento que salve. A equipe de campo não está sabotando nada — ela está otimizando o próprio dia, e o papel é rápido.
Na prática isso significa: formulário curto, campo grande, o mínimo possível de digitação, seleção no lugar de texto livre, foto e assinatura direto do celular, e valor padrão em tudo que for previsível. Se o formulário tem trinta campos porque “já que vamos fazer, vamos aproveitar”, o projeto já nasceu condenado. É melhor ter oito campos que são preenchidos do que trinta que não são.
O outro lado disso: o app tem que funcionar com o aparelho no modo avião. Grava local, sincroniza sozinho quando o sinal volta, sem depender de alguém lembrar de apertar “enviar”. Toda vez que a sincronização depende de uma ação humana, alguém esquece — e o dado que ficou preso no celular é pior que dado que não existe, porque você acha que tem.
O app deve ser a porta de entrada do dado, não o dono dele. O dono continua sendo o seu ERP ou sistema de gestão. Isso significa que a primeira pergunta técnica de qualquer projeto desses não é sobre o app — é se o seu sistema tem API ou algum caminho de importação.
Se não tiver, é melhor descobrir antes da proposta. Sem caminho de integração, o app resolve a coleta e devolve o problema da digitação para o escritório, só que agora com um custo de software em cima.
Some as horas: digitação, retrabalho, tempo de coordenação perguntando “cadê o relatório”. Coloque na calculadora com o custo-hora real da sua equipe e veja o número mensal.
Se ele não pagar o projeto em menos de doze meses, não construa. É uma resposta legítima, e é de graça.
Sobre o custo do atraso da informação — que costuma ser maior que o da digitação — escrevi neste artigo. A página sobre logística e operação de campo está aqui.
30 minutos para entender o seu desafio e ver se faz sentido trabalharmos juntos.