Vou direto ao ponto: a interceptação de pedidos no OMS quase nada tem a ver com a rapidez com que o atendente clica em "cancelar". O que decide é se o armazém tem uma cadeia de interceptação completa. Cancelar no OMS é só o tiro de largada — a briga de verdade acontece em cinco nós do WMS: onda ainda não liberada, separação em andamento, separado aguardando embalagem, embalado aguardando embarque, entregue à transportadora. Quanto mais você desce nessa lista, mais caro fica interceptar. Barrar durante a separação custa alguns minutos de mão de obra; quando o pacote já está nas mãos da transportadora, interceptar é basicamente queimar dinheiro. Já vi essa falha exatamente três vezes, e o roteiro nunca muda: o atendimento acha que cancelou, o armazém nunca fica sabendo, a mercadoria embarca do mesmo jeito.
Por que a interceptação de pedidos quebra no chão do armazém
Entre o OMS e o WMS, o cancelamento de pedidos tem um atraso embutido. O atendente clica em cancelar no OMS, e essa instrução precisa viajar por um push via API, ser interpretada pelo WMS e passar por uma verificação do status da onda antes de virar uma tarefa de interceptação no coletor do separador. Se qualquer elo dessa cadeia roda em polling em vez de push em tempo real — ou se o WMS nunca devolve o status do pedido ao OMS — a interceptação desmorona.
Em mais de 30 go-lives, a causa raiz nunca foi "o sistema não suporta cancelamento". É sempre "cancelou, mas ninguém no chão ficou sabendo". O caso clássico é o pico de vendas: os atendentes cancelam dezenas de pedidos por minuto, a onda do WMS foi liberada há uma hora, os separadores correm os corredores com carrinhos e nada nos coletores deles diz pare. A mercadoria é separada, embalada, etiquetada — enquanto o atendente diz ao cliente "já cancelei para você". No dia seguinte o cliente recebe o pacote e deixa uma avaliação de uma estrela.
Então vou ser direto: interceptação de pedidos não é um recurso do OMS. É uma cadeia que começa na ação de cancelar e dá a cada nó de trabalho do WMS uma ação de interceptação definida. Cinco nós, cinco ações, cinco perfis de custo.
Cinco nós de interceptação: quanto mais tarde você pega, mais queima
Esta é a tabela de custos que apresento a todo cliente:
| Nó de interceptação | Ação no armazém | Nível de custo | Taxa de sucesso |
|---|---|---|---|
| Onda ainda não liberada | Anular as linhas do pedido na onda | Quase zero | Quase certa |
| Separação em andamento | Enviar tarefa de interceptação ao coletor; unidades separadas voltam à posição de separação | Alguns minutos de mão de obra | Alta — se o separador vir a tempo |
| Separado, aguardando embalagem | Interceptar na estação de embalagem; a caixa cheia retorna ao estoque | Alguns minutos de mão de obra mais uma movimentação de endereçamento | Alta |
| Embalado, aguardando embarque | Sinalizar o pacote, movê-lo para uma área de retenção, mantê-lo fora do caminhão | Mão de obra mais espaço de staging | Média — depende de vencer a saída da carreta |
| Entregue à transportadora | Processo de recall da transportadora | Dezenas de dólares mais incerteza | Baixa — depende da rede da transportadora |
O padrão é claro: os três primeiros nós custam minutos de mão de obra; o quarto nó soma espaço de staging; o quinto salta para dezenas de dólares por pacote, com sucesso à mercê da transportadora. Então o primeiro princípio de design da interceptação: empurre a ação de interceptação o mais para montante possível. Se dá para matar antes da liberação da onda, nunca espere até a separação.
Aqui está a parte contraintuitiva que a maioria dos clientes entende ao contrário: eles acham que o KPI é "quantos pedidos conseguimos barrar". Errado. O valor real é "quão rápido sabemos que este pedido não pode mais ser barrado". Dez minutos de aviso antecipado de que um pacote já embarcou permitem ao atendimento iniciar o fluxo de reembolso na hora e salvar a experiência. As avaliações de uma estrela vêm do oposto: o atendente acha que interceptou, espera dois dias, e o cliente recebe o pacote. O ROI de uma cadeia de interceptação não é a taxa de barramento — é a visibilidade em tempo real do status da interceptação.
Passo a passo: a cadeia completa do cancelamento no OMS à interceptação no armazém
Estes são os passos de implementação, em ordem. Não pule nenhum.
Passo 1: a ação de cancelar no OMS precisa fazer push em tempo real. Sem polling. Quando um atendente cancela no OMS (ou o próprio cliente cancela), o OMS precisa enviar a instrução de cancelamento ao WMS em segundos via API. Projetos que fazem polling a cada cinco minutos têm interceptação só no nome — no pico, cinco minutos bastam para separar uma onda inteira. Critério de aceitação: latência fim a fim do clique em cancelar até o recebimento pelo WMS medida em segundos, testada ao vivo e registrada no checklist da noite de go-live.
Passo 2: ao receber o cancelamento, o WMS primeiro verifica o status do pedido e então escolhe a ação de interceptação. Esta lógica de decisão é o coração da cadeia:
- Pedido ainda no pool de ondas, onda não liberada → remova as linhas do pedido da onda e libere o estoque reservado. Custo zero. O melhor cenário.
- Pedido já em uma tarefa de separação → envie uma tarefa de interceptação ao coletor do separador imediatamente, com prioridade máxima. O coletor precisa exibir um pop-up e vibrar — uma notificação silenciosa é o mesmo que notificação nenhuma, e já vi exatamente essa falha três vezes. O separador devolve as unidades separadas às suas posições e encerra a tarefa.
- Mercadoria separada, na fila da embalagem → a tela da estação de embalagem mostra a lista de interceptação, o embalador pula o pedido, e a caixa cheia segue o fluxo de retorno ao estoque.
- Pacote embalado, aguardando embarque → sinalize-o (cor chamativa, bem distinta de uma etiqueta normal) e mova-o para a área de retenção de interceptação — mantenha-o fora do caminhão. A área de retenção precisa ser uma localização real no sistema, não "aquele cantinho vazio junto à parede", ou esses pacotes viram estoque fantasma.
- Pacote entregue à transportadora → dispare automaticamente a solicitação de recall da transportadora e marque o pedido no OMS como "interceptando (embarcado)". O roteiro do atendimento muda para acolhimento mais um plano de reembolso — pare de prometer ao cliente "conseguimos barrar".
Passo 3: o WMS precisa devolver o resultado da interceptação ao OMS em tempo real. Barrado ou não — o WMS reporta em segundos, e a página de detalhes do pedido no OMS mostra "interceptado / interceptando / interceptação falhou (embarcado)" de relance. Sem este passo, o atendimento voa às cegas. Muitos projetos constroem o push unidirecional OMS-para-WMS e pulam o caminho de volta. Essa é a falha mais comum que já vi. Não a segunda mais comum. A mais comum.
Passo 4: a mercadoria interceptada precisa de uma movimentação formal de retorno ao estoque. Unidades interceptadas no meio da separação voltam às suas posições; caixas interceptadas na embalagem são desfeitas e endereçadas por SKU — com um registro de tarefa real no WMS, não "o colaborador devolve quando der". Projetos que dependem de boa vontade sempre estouram o inventário cíclico dentro de um trimestre.
Passo 5: o checklist da noite de go-live ganha sua própria seção de interceptação.
- Peça para alguém fazer um pedido de teste e percorrer todo o fluxo "pedido → liberação da onda → cancelar no meio da separação". O coletor exibe o pop-up? Ele vibra?
- Percorra o fluxo "cancelar após a embalagem concluída". A localização de retenção existe no sistema? A sinalização é visível?
- Lado do atendimento: o status de interceptação na página de detalhes do pedido atualiza em tempo real?
- Plano de pico: quando o volume de cancelamentos dispara, as tarefas de interceptação se afogam sob as tarefas normais de separação? Teste de carga no tratamento de prioridade.
A falha que já vi três vezes
Dois projetos reais, nomes alterados, detalhes reais.
Primeiro: o armazém de uma marca de beleza em Ontário, Califórnia, durante uma Black Friday de alguns anos atrás. A equipe de atendimento cancelou dezenas de pedidos no OMS — no processo, tudo parecia certo. Mas o WMS deles liberava ondas automaticamente a cada hora, e os cancelamentos saíam em polling de cinco minutos. Quando os cancelamentos chegaram, metade da mercadoria já estava separada. Pior: as estações de embalagem não tinham lista de interceptação, então os embaladores embalaram e embarcaram normalmente. Mais de uma dezena de pedidos saiu; recall da transportadora mais processamento de devolução custaram dezenas de dólares por pacote — cerca de mil dólares embora, mais um punhado de avaliações de uma estrela. A correção: push em tempo real em vez de polling, pop-ups de interceptação nos coletores, lista de interceptação nas telas de embalagem. Um trimestre depois, o sucesso da interceptação na fase de separação estava acima de noventa por cento.
Segundo: um armazém de acessórios 3C no Texas. A cadeia funcionava, mas eles reprovaram no Passo 4 — a mercadoria interceptada não tinha tarefa formal de retorno ao estoque. Caixas interceptadas na embalagem foram "temporariamente" empilhadas atrás das bancadas. Três meses depois o inventário cíclico estava errado em várias centenas de unidades, e foram necessárias duas semanas para rastrear até aquela pilha. Desde então, todo projeto meu tem a mesma linha vermelha: a área de retenção de interceptação precisa ser uma localização no sistema. "Empilha no canto por enquanto" não é um plano.
Então aqui vai minha frase de encerramento: interceptação é metade tecnologia; a outra metade é garantir que cada nó tenha uma pessoa, um lugar e um registro no sistema por trás. O último item de todo checklist de noite de go-live é o mesmo — peça para alguém fazer um pedido de teste e percorrer o fluxo inteiro de verdade. Um plano de interceptação de pedidos que só existe no papel vai te dar uma lição no dia de pico.
Por Lin Xiao, Consultor de Implementação de WMS
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
