Eis um número que deveria preocupá-lo: em uma operação de e-commerce típica que processa de 30.000 a 50.000 pedidos por mês, de 1 a 2 por cento dos pedidos caem na fila de exceções. São de 300 a 1.000 pedidos por mês que não fluem direto — e cada um deles é um cliente esperando, um cutoff da transportadora se aproximando e uma decisão que ninguém tomou.
Segunda-feira, 8h. Um atendente abre o OMS e encontra 300 exceções em um único pool indiferenciado: endereços ruins, telefones inativos, bloqueios por fraude, faltas de estoque — todos ordenados por hora, nenhum por prioridade. Até o cutoff da transportadora à tarde, metade rola para amanhã. As avaliações de uma estrela já estão a caminho.
Depois de vinte anos em fulfillment de e-commerce, digo sem rodeios: a fila de exceções é o espelho mais honesto do armazém. Ela nunca reflete o quanto o atendimento se esforça. Reflete se alguém desenhou o processo.
Triar primeiro, resolver depois
A maior armadilha com exceções é pular a triagem. Um endereço ruim e um bloqueio por fraude são problemas completamente diferentes. Jogados em um único pool, os atendentes abrem um por um e confiam no feeling — lento, e os urgentes ficam enterrados.
Faço os armazéns dividirem as exceções em quatro trilhos. Problemas de endereço: endereços incompletos, CEPs que não batem com a cidade, telefones do destinatário em branco. Geralmente mais da metade de todas as exceções, e os mais fáceis de resolver — a maioria se resolve com regras, não com pessoas. Pagamento e fraude: verificações AVS que falharam, divergências no endereço de cobrança, bloqueios por regras de fraude. O trilho mais sensível — devagar demais e você perde o pedido, rápido demais e pode liberar um pedido fraudulento. Estoque: o estoque estava disponível na hora do pedido, mas sumiu na alocação, ou transferências presas entre armazéns. Isso é do planejamento ou das compras, não do atendimento. Erros de sistema: pedidos com campos faltando vindos do canal, SKUs que não batem com o cadastro de itens. Isso é trabalho de TI, e deixá-los se acumular na fila de atendimento enterra todo o resto.
Uma vez que cada trilho tem seu próprio caminho de tratamento, o atendimento só toca a pequena fatia de problemas de endereço que a automação não resolve. Só esse passo costuma encolher a fila visível em mais da metade.
Construí isso para um armazém de fulfillment de vestuário no ano passado, que processava cerca de 40.000 pedidos por mês. O pool de exceções estava acima de 400, com cinco atendentes fazendo hora extra sem conseguir limpar. Um mês depois que os trilhos de triagem e as três regras automáticas entraram no ar, o pool estava abaixo de 120, a equipe caiu para três atendentes, e um deles foi realocado para trabalho com contas-chave. Exceções não são um problema de headcount.
Automatize o óbvio
De setenta a oitenta por cento das exceções de endereço podem ser tratadas por regras — mas as regras têm de estar no fluxo do pedido, não em uma etapa de limpeza manual depois do fato. Três regras fazem a maior parte do trabalho.
Primeiro, padronização de endereços. Valide contra o USPS ou uma API de endereços de terceiros no checkout: divergências entre CEP e cidade são corrigidas automaticamente, números de apartamento faltantes são sinalizados para o cliente completar. Não subestime isso — um número de apartamento faltante é a principal causa de devoluções por "endereço insuficiente" nos EUA.
Segundo, validação de telefones. Confira o formato e a validade do plano de numeração na hora do pedido, e bloqueie números obviamente inativos no front end. Descobrir um telefone inalcançável quando o pacote já está com a transportadora custa dez vezes mais para corrigir do que pegá-lo no checkout.
Terceiro, triagem de fraude em camadas. Sem bloqueios gerais. Minha configuração: risco baixo libera automaticamente, risco médio vai para uma fila de revisão manual com SLA de duas horas, risco alto fica retido para uma ligação de verificação. O que as regras de fraude mais temem é o falso positivo — bloquear um cliente de verdade não perde só um pedido, perde aquele cliente para sempre.
Falsos positivos precisam de uma via de recurso
As regras de fraude vão bloquear clientes de verdade. Isso é inevitável. O que separa uma boa operação é o que vem depois: o cliente tem para onde ir?
Minha exigência: toda regra de fraude nasce com um caminho de recurso. O cliente bloqueado recebe um SMS ou e-mail com um link para enviar documento ou comprovante de pagamento, e uma pessoa revisa em até 48 horas. Pedidos aprovados liberam automaticamente, e o cliente entra em uma lista branca para que a mesma regra nunca mais o bloqueie.
E acompanhe a taxa de falsos positivos: todo mês, revise a parcela de bloqueios revertidos em recurso. Se subir além da sua linha de conforto, a regra está rígida demais. Prevenção de fraude e conversão são sempre uma gangorra — se você topa bloquear, topa assumir os erros.
Dê aos humanos um SLA
O que a automação não limpa é trabalho humano, e trabalho humano precisa de SLA — senão os atendentes escolhem os fáceis e os casos difíceis escorregam para depois do cutoff da transportadora. Minha ordem de prioridade corre de trás para frente a partir do cutoff de hoje: problemas de endereço que podem ser corrigidos e enviados hoje vão primeiro, revisões de fraude de risco médio recebem decisão em duas horas, exceções de estoque são transferidas ao planejamento no mesmo dia e ficam marcadas como aguardando sem consumir horas de atendimento, e erros de sistema vão direto para um ticket de TI em vez de mofar na fila.
Uma regra dura: nunca contate o mesmo cliente duas vezes em 24 horas por causa de exceções. Um pedido com problema de endereço e bloqueio por fraude recebe uma ligação combinada e um roteiro claro. Falhe nisso e o dano à experiência supera o atraso do envio.
A fila tem de zerar toda noite — não zero não resolvido, mas zero sem próximo passo definido e sem dono. Nada fica "pendente" de um dia para o outro. Se você não conseguir limpar, a primeira reunião da manhã seguinte é uma revisão: regras mal configuradas, falta de gente ou um pico repentino em um trilho. Um pico costuma ser o sinal mais precoce de que algo quebrou à montante — em uma integração de canal ou no próprio sistema — e sempre ganha do atendimento na hora de descobrir.
Por fim, dê às exceções um relatório diário. Toda noite, o sistema envia cinco linhas ao líder de operações: novas exceções do dia, vencidas e não tratadas, recursos revertidos. Curto. Exceções não são perigosas porque são muitas — são perigosas quando ninguém está olhando. O relatório força um olhar diário.
Uma fila de exceções ordenada por hora é uma lista de tarefas. Uma fila de exceções ordenada por categoria é um pipeline. Construa o pipeline.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
