Case de sucesso em logística: como automatizamos a roteirização e reduzimos o SLA operacional em 60%

Este case de sucesso em logística mostra como a automação da roteirização reduziu o SLA operacional em 60% em uma operação com alto volume de pedidos, múltiplas janelas de entrega e dependência de conferências manuais. O objetivo não era apenas gerar rotas mais rapidamente, mas criar um fluxo rastreável, observável e sustentável para a equipe de operações.

Antes do projeto, o sistema de pedidos, a ferramenta de roteirização e a fila de trabalho funcionavam de forma pouco integrada. A equipe exportava dados, conferia inconsistências, acionava a roteirização, copiava resultados para outra ferramenta e acompanhava exceções por mensagens dispersas.

O tempo de processamento variava conforme o volume do dia. Quando um arquivo chegava incompleto ou uma API respondia com atraso, a operação frequentemente descobria o problema somente depois do início da expedição. Isso gerava retrabalho, reprocessamento de rotas e risco de descumprimento das janelas combinadas com os clientes.

O diagnóstico inicial encontrou quatro gargalos principais: ausência de uma fila única de trabalho, baixa padronização dos dados de entrada, falta de alertas acionáveis e pouca clareza sobre quem deveria tratar cada exceção. A tecnologia existia, mas o processo não tinha controles suficientes para funcionar de maneira previsível.

Para estruturar essa etapa, a Trait aplicou uma abordagem semelhante à apresentada no diagnóstico tecnológico remoto em 7 passos para PMEs, começando por evidências do fluxo real, e não por uma escolha prematura de ferramentas. O resultado foi um mapa de dependências, riscos e decisões que orientou a implementação.

A arquitetura foi desenhada com separação clara entre entrada de dados, orquestração, processamento, fila de exceções e observabilidade. O n8n ficou responsável por coordenar as etapas e chamadas de integração, enquanto a infraestrutura em AWS sustentou os serviços necessários para execução, armazenamento de registros e monitoramento.

O Trello foi usado como fila operacional de exceções, não como banco de dados principal. Cada cartão representava uma ocorrência que exigia análise humana, com categoria, lote, horário, impacto, responsável e prazo de resolução. Essa decisão preservou a simplicidade para a equipe de operação sem esconder o histórico técnico nos bastidores.

O fluxo principal seguia esta sequência: receber o lote, validar o esquema, normalizar os dados, registrar o início, enviar a solicitação de roteirização, aguardar o retorno, conferir o resultado, publicar o status e criar uma tarefa somente quando houvesse uma exceção real. O desenho evitou que a equipe recebesse alertas para cada evento normal do processo.

Uma versão simplificada da lógica reutilizável ficou assim:

Receber lote
 -> Validar campos e regras de negócio
 -> Se inválido: registrar falha e criar exceção
 -> Se válido: normalizar e enviar para roteirização
 -> Aguardar retorno com controle de tempo
 -> Validar quantidade de rotas e pedidos
 -> Publicar resultado e atualizar fila
 -> Se falhar: classificar, alertar e permitir reprocessamento seguro

A validação de contrato de dados foi tratada como parte da integração. Campos como identificador do pedido, endereço, janela de entrega, peso e volume precisavam estar presentes e em formato válido. Para aprofundar essa proteção, o time utilizou práticas alinhadas ao checklist de validação de dados em integrações.

Na camada de infraestrutura, foram definidos ambientes separados para teste e produção, credenciais fora do fluxo de negócio, registros com retenção adequada e permissões mínimas para os serviços. A documentação da AWS sobre práticas recomendadas para segurança na nuvem serviu como referência para revisar identidade, acesso, rastreabilidade e proteção dos componentes.

A decisão de usar n8n como orquestrador também exigiu disciplina. O fluxo foi dividido em etapas menores, com nomes consistentes, tratamento de erro e pontos claros de retomada. A documentação oficial do n8n sobre tratamento de erros em fluxos foi usada como referência para configurar respostas diferentes para falhas temporárias, dados inválidos e indisponibilidade de serviço.

Reduzir o SLA uma vez não é suficiente. O risco maior aparece quando uma alteração no sistema de pedidos, na API de roteirização ou nas regras de negócio quebra silenciosamente o fluxo. Por isso, cada mudança passou a ser tratada como uma alteração operacional com impacto mensurável.

Os controles incluíram testes de contrato, validação de quantidade de pedidos antes e depois da roteirização, proteção contra duplicidade e limite de tempo para respostas externas. Quando o retorno não chegava dentro da janela definida, o fluxo não ficava aguardando indefinidamente: registrava o evento, classificava a ocorrência e encaminhava a decisão para a fila correta.

A observabilidade foi organizada em três camadas. A primeira acompanhava a saúde técnica, como erros de execução, tempo de resposta e disponibilidade. A segunda monitorava o fluxo, como lotes pendentes, reprocessamentos e exceções abertas. A terceira conectava a operação ao negócio, medindo cumprimento de corte, tempo até a rota validada e volume afetado.

O painel no Metabase não foi criado para exibir dezenas de gráficos. Ele respondia a perguntas práticas: quantos lotes estão em risco, qual etapa concentra falhas, qual exceção se repete e qual é o impacto no horário de expedição. Essa abordagem segue a lógica do painel de observabilidade orientado ao negócio, em que métricas técnicas ajudam a tomar decisões operacionais.

Também foi adotado um procedimento de implantação com validações antes e depois da mudança. O checklist operacional de deploy para produção ajuda a transformar essa prática em uma rotina repetível, especialmente para equipes pequenas que não podem depender da memória de uma única pessoa.

Os registros de execução foram estruturados para permitir auditoria sem expor dados desnecessários. Cada evento recebeu identificador do lote, etapa, horário, resultado e referência da exceção, enquanto informações sensíveis foram tratadas conforme a necessidade de acesso. Assim, suporte, operação e gestão passaram a consultar a mesma história do processo.