Carga fracionada: o que fazer quando o SLA falha

Você acertou o SLA, alinhou o prazo com o cliente, configurou a rota. E aí o embarque de segunda-feira não chegou na quarta. O cliente liga na quinta de manhã. O que você faz?

Essa é a pergunta que a maioria dos posts sobre SLA nunca responde. Falam sobre como montar o indicador, como calcular o transit time, como escolher o modal certo. Mas quando a falha acontece, o que muda na operação? Qual é o protocolo? Quem aciona quem, em quanto tempo, com que informação?

A resposta direta: quando o SLA de carga fracionada falha, o custo real não é o frete. É o cliente que para de confiar no prazo e começa a pedir aéreo preventivo. O protocolo correto tem três movimentos: identificar antes do cliente reclamar, comunicar com dado (não com desculpa) e corrigir a causa-raiz na rota, não no embarque individual. O resto do post detalha cada um desses movimentos.

Por que a falha de SLA vira problema de custo, não só de prazo

Entendido o cenário de pânico, a consequência mais cara não é óbvia. Quando o SLA falha uma vez sem protocolo claro, o embarcador começa a fazer o que chamo de "aéreo defensivo": manda pelo aéreo os pedidos que mais doem, independente do prazo real que o rodoviário ou o multimodal entregaria. Ele não calcula. Ele reage.

O problema é que esse comportamento se cristaliza. Uma distribuidora de médio porte que atende clientes industriais no interior pode ter dois ou três pedidos por mês que legitimamente justificam o aéreo. Quando o SLA falha sem resposta estruturada, ela passa a mandar dez ou quinze por mês nesse modal. O custo marginal de cada envio aéreo é significativo, e ele se repete todo mês, silenciosamente, sem aparecer como "custo da falha de SLA" no relatório.

Isso não é hipótese. É o padrão que vejo em diagnósticos de operação: a raiz do custo logístico inflado quase sempre tem uma falha de SLA não tratada lá atrás. O embarcador nunca percebeu que estava pagando pela desconfiança, não pelo serviço.

O que o dado de rastreamento diz que o freteiro não conta

O rastreamento em tempo real resolve metade desse problema, mas só se você souber ler o sinal certo. O dado relevante não é "onde está a carga agora". É "qual a diferença entre o horário previsto de chegada e o horário atual de progressão?"

Quando você opera com horário fixo de saída, como acontece na malha de ônibus interestadual, esse cálculo é direto. O ônibus saiu 40 minutos atrasado de origem? A chegada no hub intermediário vai deslocar proporcionalmente. Você já sabe, antes da reclamação, que aquele embarque tem risco de virar D+3 em vez de D+2. É ali que o protocolo começa, não quando o cliente liga.

Como agir antes da reclamação chegar

Esse ponto conecta direto com o anterior: o protocolo de falha de SLA começa no monitoramento, não no atendimento. E a diferença prática entre os dois é enorme.

Quando você age no atendimento, você está respondendo a um cliente irritado com uma informação incompleta, pedindo desculpa por algo que já aconteceu. Quando você age no monitoramento, você liga para o cliente antes dele ligar para você, com dado preciso e com alternativa concreta.

A lista de ações que funciona, por ordem de execução:

• Alerta automático de desvio: qualquer embarque com progressão acima de 15% do transit time previsto gera alerta interno antes de gerar reclamação externa
• Contato proativo em até 2 horas do alerta: não espere confirmar o atraso para comunicar. Comunique o risco com o dado que você tem
• Ofereça a alternativa, não a desculpa: "seu embarque está com risco de chegar quinta em vez de quarta. Posso redirecionar pelo hub Y com chegada garantida na quarta tarde. Confirmo?"
• Registre o desvio com causa-raiz: problema mecânico, atraso de coleta, excesso de carga no hub? Cada causa exige uma correção diferente na rota

O cliente que recebe esse contato proativo reage de forma radicalmente diferente do cliente que descobriu o atraso sozinho. Ele ainda pode ficar incomodado, mas a confiança operacional se mantém. E é a confiança operacional que evita o aéreo defensivo.

Quando o problema é na ponta, não no trecho principal

Um detalhe que complica bastante: a maioria das falhas de SLA em carga fracionada interestadual não acontece no trecho principal. Acontece nas pontas. A carga chega no hub de destino dentro do prazo e fica parada esperando o veículo de last mile para o interior.

Isso é especialmente crítico em cidades menores, que dependem de transferência local com frequência de saída baixa. Se o hub de destino faz last mile para aquela praça três vezes por semana, e a carga chegou no dia seguinte ao último horte, ela espera dois dias. O transit time do trecho principal foi D+1. O SLA entregue ao cliente foi D+3.

Para resolver isso, a informação que você precisa na hora do SLA não é só o transit time do modal principal. É a frequência de saída do last mile na praça de destino. Esse dado muda completamente como você monta o SLA por rota e onde você concentra a atenção de monitoramento.

O que a causa-raiz revela sobre a malha, não sobre o embarque

Resolto o imediato, vem a parte que separa a operação que melhora da operação que fica apagando incêndio: a análise de causa-raiz.

A tentação é tratar cada falha como evento isolado. "O caminhão quebrou." "O hub estava cheio por causa da data comemorativa." "O motorista do last mile estava doente." Tudo verdade, mas essas explicações não evitam a próxima falha.

O que a causa-raiz bem feita revela é o padrão na malha. Três falhas de last mile na mesma praça em dois meses não são azar. É um ponto fraco estrutural naquela rota. Uma distribuidora que atendo no Triângulo Mineiro identificou, depois de mapear três meses de falhas, que 70% dos atrasos vinham de um único trecho de transferência que dependia de um único parceiro local com frota pequena. A solução não foi reclamar mais daquele parceiro. Foi adicionar um segundo parceiro como backup e ajustar o SLA público daquela praça de D+2 para D+3 até ter frequência suficiente para garantir o prazo menor.

Isso parece retrocesso. Na prática, é o oposto: você para de prometer o que não consegue entregar e começa a construir a malha para entregar o que promete. O cliente de e-commerce que vende para o interior prefere D+3 confiável a D+2 que vira D+4 sem aviso.

Como separar falha de modal de falha de execução

Nem toda falha de SLA é problema de malha. Às vezes é execução: coleta fora do horário de corte, cubagem errada que bloqueia embarque, documentação fiscal com erro que segura a carga no hub. Cada um desses casos tem solução diferente.

A pergunta que organiza o diagnóstico:

• A carga saiu no horário? Se não, é problema de coleta ou corte operacional
• A carga chegou no hub intermediário dentro do previsto? Se não, é problema de trecho ou de modal
• A carga saiu do hub para o last mile no próximo slot disponível? Se não, é problema de frequência ou de gestão de hub
• A entrega foi tentada e não foi concluída? Se sim, é problema de last mile ou de informação de destinatário

Mapear onde a falha ocorreu no processo direciona a correção para o ponto certo. Sem esse mapeamento, você muda de transportadora achando que o problema é o modal, quando na verdade é o processo de coleta interno. O custo continua, a falha continua, e você gastou energia trocando de parceiro sem resolver nada. Você pode aprofundar esse tipo de análise de custo invisível na operação aqui.

O que fazer na prática agora

Com tudo isso em mente, a ação mais inteligente agora é auditar as últimas dez falhas de SLA da sua operação, ou as últimas dez vezes que um cliente reclamou de prazo. Para cada uma, responda: onde no processo a falha ocorreu? A causa foi comunicada proativamente ou reativamente? O cliente recebeu alternativa ou só desculpa? Essa falha se repetiu na mesma rota?

Se mais da metade das falhas se concentra nas mesmas rotas ou nas mesmas praças, você tem um problema de malha para resolver, não de execução. A correção passa por revisar o SLA público daquelas rotas e ajustar a frequência de last mile antes de prometer prazo que a infraestrutura não suporta. Se as falhas estão espalhadas sem padrão, o problema provavelmente é de processo interno: corte de coleta, cubagem, documentação fiscal.

O diagnóstico da sua malha atual começa por aí: não pelo custo do frete, mas por onde o SLA está quebrando e por quê.

Quando você trata a falha como dado de operação em vez de evento para pedir desculpa, ela vira informação. E informação bem usada é o que transforma uma malha fracionada cara e imprevisível numa malha que o cliente confia, e que você não precisa compensar com aéreo toda semana.

Perguntas frequentes

Quanto tempo tenho para comunicar um atraso de SLA antes que o cliente reclame? De forma geral, o cliente B2B com prazo comprometido entra em contato nas primeiras horas do dia em que a entrega deveria acontecer. O protocolo ideal é comunicar o risco de atraso no dia anterior, quando o monitoramento já mostra desvio na progressão. Comunicação proativa com dado concreto e alternativa tem resultado muito melhor do que comunicação reativa com pedido de desculpa.

Faz sentido ajustar o SLA público para uma praça em vez de forçar o prazo menor? Faz, e frequentemente é a decisão mais inteligente. Um SLA menor que não se sustenta gera mais custo (aéreo defensivo, atendimento, perda de confiança) do que um SLA maior com cumprimento consistente. O cliente prefere previsibilidade a prazo curto com variação.

A integração via API ajuda a identificar falhas de SLA mais cedo? Sim, de forma significativa. Quando o ERP do embarcador está integrado à plataforma de transporte via API, os alertas de desvio chegam automaticamente ao sistema interno sem depender de consulta manual ou ligação para a transportadora. Isso reduz o tempo de reação e permite que o time de operações aja antes da reclamação, não depois.