Às 15h18, a central recebe uma mensagem do motorista: "cliente fechado". A carga ainda está no caminhão. No sistema de um parceiro, a rota aparece como concluída porque o último ponto planejado foi alcançado. O atendimento promete uma nova tentativa para a manhã seguinte, mas ninguém definiu se a carga volta ao pátio, fica com o motorista ou segue para outra base.
Para quem vê de fora, parece uma entrega atrasada. Para a transportadora, são perguntas que mudam custo, atendimento e risco: qual volume foi afetado? quem registrou o fato? o destinatário foi avisado? quem pode liberar uma nova saída? onde a carga ficou durante a noite?
Um sistema para transportadora precisa guardar essa história sem empurrar tudo para uma observação de WhatsApp. O objetivo não é desenhar um mapa mais bonito. É fazer com que coleta, trânsito, tentativa, ocorrência e desfecho levem a uma próxima decisão clara.
Coleta confirmada não é carga disponível para a rota
Antes de o caminhão sair, uma mesma solicitação pode estar aguardando coleta, com coleta agendada, coletada parcialmente, recusada pelo remetente, aguardando conferência ou liberada para consolidação. Uma coluna com "coletado" esconde justamente as diferenças que a operação precisa enxergar.
Pense em uma empresa que atende lojas de uma região. Uma coleta prevista para 10h pode não acontecer porque o remetente não separou todos os volumes. Outra pode sair com uma ressalva de embalagem. Uma terceira pode ser concluída, mas perder a janela de transbordo. Três cargas foram "coletadas" de algum jeito; nenhuma tem o mesmo próximo passo.
O cadastro precisa preservar o pedido original, a janela combinada, os volumes efetivamente recebidos e o evento que mudou a situação. Isso evita uma falsa certeza logo no começo do dia. A ANTT mantém o RNTRC como referência para o registro de transportadores rodoviários remunerados de cargas; o sistema operacional não substitui esse registro nem decide enquadramentos, mas pode associar a regra interna de habilitação ao parceiro ou veículo usado em cada serviço.
Uma rota precisa de eventos, não de um único status
"Em rota" pode durar quinze minutos ou dois dias. Nesse intervalo, uma carga pode sair de uma base, passar por transbordo, aguardar uma janela, ser reprogramada ou exigir contato com o destinatário. Se o único dado é o ponto no mapa, atendimento e expedição continuam perguntando no grupo o que realmente ocorreu.
Uma sequência útil separa fatos simples:
- saída confirmada, com carga e responsável associados;
- chegada ao ponto, quando houver registro confiável;
- início da tentativa de coleta ou entrega;
- resultado da tentativa;
- ocorrência aberta, se o resultado exige decisão;
- reprogramação, retorno, transferência ou encerramento.
Não é necessário transformar cada parada em burocracia. A regra é registrar o evento quando ele muda uma promessa, uma custódia, uma decisão comercial ou a comunicação com alguém. A GS1 explica o EPCIS como padrão para dados de eventos ligados a objetos e movimentações. Mesmo sem adotar o padrão inteiro, vale aproveitar a ideia: um histórico de eventos explica melhor a operação do que sobrescrever o status atual.
Ocorrência precisa abrir trabalho, não encerrar conversa
No caso do cliente fechado, "não entregue" é o início do caso. O registro ainda precisa dizer se houve tentativa no endereço certo, quem recebeu a informação, onde a carga ficará, qual alternativa será oferecida e quem responde antes da próxima janela.
Uma ocorrência simples pode carregar:
- tipo e descrição objetiva do fato;
- momento e local do registro, quando aplicável;
- volumes ou documentos afetados;
- evidência disponível, como nome informado, foto permitida ou confirmação de contato;
- impacto na carga, na rota e na promessa ao cliente;
- próximo responsável, prazo e ação pendente.
Esse modelo também serve para avaria aparente, divergência de volume, recusa, endereço inacessível ou destinatário ausente. O tipo de ocorrência não decide sozinho uma cobrança, um ressarcimento ou uma responsabilidade. Ele evita que a decisão aconteça sem contexto.
A parte mais importante do fluxo está depois do alerta. Uma ocorrência só é útil quando alguém consegue ver o que aconteceu e assumir a próxima ação sem reconstruir a história por mensagens.
Prova de entrega responde uma pergunta específica
Foto, assinatura, nome de quem recebeu, horário, geolocalização permitida e confirmação digital não têm o mesmo peso em todas as operações. Uma foto de uma porta, por exemplo, pode mostrar que alguém esteve em um local, mas não confirma sozinha quais volumes foram recebidos.
A empresa precisa definir que dúvida cada evidência responde. Em uma entrega B2B, pode importar quem recebeu e se houve ressalva. Em outra operação, o mais importante pode ser registrar a quantidade entregue e a divergência. O formato depende do contrato, do risco e da política de atendimento.
Dados de localização, contatos e imagens também merecem limite. A LGPD exige que o tratamento de dados pessoais tenha base e finalidade. Na prática, isso pede acesso por função, coleta proporcional ao serviço e retenção definida. Guardar tudo por tempo indeterminado só porque o aplicativo consegue registrar não torna a operação mais segura.
Documento fiscal, evento operacional e comprovante não são a mesma coisa
A transportadora costuma trabalhar com documentos e registros que nascem em responsabilidades diferentes. O Portal do Conhecimento de Transporte Eletrônico reúne orientações do CT-e, um documento fiscal eletrônico. Isso não transforma o app de campo em emissor fiscal, nem faz uma assinatura de recebimento substituir o documento aplicável.
Um sistema bem desenhado pode relacionar a referência de um documento ao serviço, controlar se há uma pendência interna e encaminhar dados para uma integração autorizada. A emissão, a escrituração e a validação fiscal continuam no fluxo e nos responsáveis adequados. Misturar tudo em um botão chamado "finalizar entrega" cria uma falsa sensação de conformidade e deixa exceções invisíveis.
O parceiro precisa entrar na mesma história da carga
Em muitas transportadoras, parte da coleta ou da última milha passa por agregado, transportador parceiro ou base terceirizada. Mandar uma planilha pela manhã não resolve quando um endereço muda, uma tentativa falha ou uma carga precisa de retorno.
O sistema não precisa vigiar cada pessoa. Precisa deixar claro o que foi repassado, a quem, em qual condição e qual retorno a central espera. Isso inclui permissões para registrar evento, limites para alterar uma promessa e uma trilha para mudanças relevantes.
Quando a roteirização entra na operação, a integração deve devolver fatos úteis: sequência planejada, saída, tentativa, ocorrência e resultado. Um mapa isolado só aumenta a quantidade de telas. A documentação do Google Maps Routes mostra recursos para calcular rotas; a decisão de aceitar uma reprogramação, priorizar uma carga ou comunicar o cliente continua sendo da operação.
Comece pelo dia em que a carga ficou sem dono
Não comece comprando todas as telas de um TMS. Escolha uma situação que já gerou retrabalho: coleta parcial, tentativa sem sucesso, entrega com divergência ou carga devolvida para a base. Siga um caso inteiro e responda, em cada mudança:
- qual fato foi confirmado;
- qual informação não pode ser perdida;
- quem pode decidir o próximo passo;
- quem precisa ser avisado;
- que evento permite encerrar o caso.
Essa investigação costuma mostrar se o gargalo está em cadastro, comunicação, integração, regra de aprovação ou falta de visibilidade. O artigo sobre quando a planilha vira gargalo ajuda a reconhecer o momento em que várias pessoas já mantêm versões diferentes da mesma operação.
A Foyth Tech pode mapear esse fluxo com sua equipe e desenhar um sistema que conecte eventos, exceções e integrações sem assumir o lugar de quem responde por transporte, contrato ou obrigação fiscal. Converse com a Foyth Tech sobre um sistema personalizado para sua operação.
