Direto ao ponto: para qualquer go-live de WMS ou de automação, configure quatro níveis de alerta — Nível 1 (SMS + ligação), Nível 2 (@menção no grupo de plantão do WeCom), Nível 3 (mensagem simples do WeCom), Nível 4 (resumo por e-mail) — com SLAs de resposta de 5 minutos, 30 minutos, 4 horas e no dia seguinte. Vi três vezes a abordagem de "mandar tudo por SMS". As três morreram de fadiga de alertas: a pessoa de plantão parou de ler na mensagem 47, e a mensagem 48 acabou sendo o incêndio de verdade.
Hierarquizar alertas é um problema de implementação, não de operação
A maioria dos projetos trata o alerta como "algo que a operação resolve depois do go-live", e o consultor de implementação vai embora. Depois de mais de 30 go-lives, vou dizer sem rodeios: as regras de alerta precisam estar travadas durante a UAT, porque a hierarquização define seu processo de resposta a incidentes, e a resposta a incidentes faz parte do blueprint do WMS que é assinado.
Em novembro de 2023, um cliente de e-commerce transfronteiriço em Shenzhen, segundo mês após o go-live. Às 2:14 AM, um alerta de congelamento de estoque disparou porque a fila de integração estava represando — e saiu só por e-mail. O supervisor de plantão estava com Não perturbe ativado; o e-mail ficou sem ler na caixa de entrada. Às 8 AM, mais de 2.000 pedidos não podiam ser enviados porque o estoque estava congelado. O atendimento ao cliente ficou sobrecarregado. Prejuízo direto: cerca de 18.000 pedidos não enviados naquele dia, com valor médio de pedido de $22 — quase $400.000 de receita diária perdida, antes das multas de atraso dos marketplaces. Vi exatamente esse fracasso três vezes. Toda vez foi "o alerta disparou, mas ninguém olhou".
E aqui o contraintuitivo: alertas perdidos são um problema de hierarquização em 90% das vezes, não um problema de canal. Também vi o extremo oposto — um 3PL no leste dos Estados Unidos cujas sondas de temperatura de cadeia do frio mandavam um SMS cada vez que a leitura oscilava, mais de 60 mensagens por noite. No terceiro dia, o gerente de plantão colocou o número dos alertas na lista negra. Alertas demais equivalem a nenhum alerta. A hierarquização existe para proteger a atenção de quem está de plantão, para que só eventos verdadeiramente graves acordem a pessoa.
Quatro passos para construir a cadeia de escalação
Passo 1: defina primeiro os níveis — não mais que cinco categorias de Nível 1.
Classifique por apenas duas dimensões: raio de impacto × tempo até o dano irreversível. Nível 1 significa "se ninguém agir agora, haverá um incidente de produção dentro de uma hora". Meu modelo padrão para clientes:
| Nível | Definição | Canal | SLA de resposta | Exemplos |
|---|---|---|---|---|
| Nível 1 | Incidente de produção em até 1 hora se ignorado | SMS + ligação | 5 min | WMS fora do ar, perda de energia na cadeia do frio, integração de alarme de incêndio |
| Nível 2 | Impacto parcial, pode esperar horas | Grupo de plantão do WeCom @on-call | 30 min | Fila de interfaces acima do limite, AGVs massivamente fora de operação |
| Nível 3 | Precisa de ação, não urgente | Mensagem simples do WeCom | 4 horas | Impressora de etiquetas sem papel, falha de um único PDA |
| Nível 4 | Estatísticas e tendências | Resumo por e-mail | No dia seguinte | Resumo dos incidentes de ontem, disco em 70% |
Mantenha a lista do Nível 1 curta. Minha regra de ferro: não mais que cinco categorias. Mais de cinco significa que você não conseguiu distinguir prioridades, o que significa que não hierarquizou nada.
Passo 2: monte a escala de plantão — ninguém de plantão por mais de duas semanas seguidas.
Use um par titular + reserva: o titular responde, o reserva só recebe uma ligação se o titular não confirmar recebimento em 10 minutos. Rodízio semanal; máximo de duas semanas. Uma vez vi um cliente manter uma pessoa de plantão um mês inteiro — na terceira semana o tempo de resposta dele já tinha se degradado claramente. Perguntado por quê, ele disse que tinha criado o hábito de presumir que todo alerta era falso positivo.
A escala precisa viver no sistema: a plataforma de alertas (bot do WeCom, gateway de SMS) roteia automaticamente para quem estiver de plantão conforme a data. Sem encaminhamento manual. O encaminhamento manual é o maior ponto único de falha: em março de 2024, um 3PL no leste da China estava com o supervisor de plantão de férias; o SMS chegou ao telefone dele, ele estava num trem de alta velocidade sem sinal, e o reserva nem sabia que era o reserva. Isso foi um Nível 1: falha de transelevador do AS/RS, linha parada por 3 horas, 9.000 caixas enviadas a menos.
Passo 3: construa a cadeia de escalação — escalação automática ao estourar o prazo.
Esta é a parte mais pulada e a que mais pode salvar você. As regras são simples:
- O Nível 1 dispara; se o titular não clicar em "confirmar recebimento" no sistema em 5 minutos, ligação automática para o reserva;
- Mais 10 minutos sem confirmação, ligação automática para o gerente de operações;
- Mais 15 minutos, ligação direta para o gerente geral e @todos no grupo de gestão do WeCom.
Registre cada escalação: quem confirmou a que horas, que ação tomou. O registro não é para culpar — é para a análise post-mortem. Um processo de alertas sem registros vai falhar do mesmo jeito na próxima vez.
Passo 4: o checklist da véspera do go-live — teste os alertas como uma funcionalidade.
Este é meu mantra, e é o que faço na noite anterior a cada go-live:
- Para cada categoria de Nível 1, dispare manualmente e confirme que o SMS + a ligação chegam ao telefone de plantão em menos de 1 minuto
- Simule o titular não atendendo; confirme a escalação automática para o reserva em 5 minutos
- Confirme que o token do bot do WeCom é o de produção (bots de teste postam em grupos de teste — troque no go-live)
- Confirme que o gateway de SMS tem crédito (pode rir — já tive um cliente cujas mensagens pararam no terceiro dia porque a conta zerou)
- Confirme que a escala cobre as próximas 4 semanas e roteia corretamente no sistema
- Confirme que a lista de destinatários do resumo de Nível 4 inclui o responsável de TI do cliente
Três modos de falha que vi mais de três vezes
Modo de falha 1: alertas de teste e de produção misturados. Testadores fazem teste de carga à meia-noite, sai uma enxurrada de SMS de alerta, a pessoa de plantão é acordada três vezes e começa a tratar todo alerta como ruído. Solução: alertas do ambiente de teste vão só para o grupo de teste do WeCom. Nunca tocam no canal de SMS.
Modo de falha 2: a lista do Nível 1 não para de crescer. Seis meses após o go-live, cada departamento faz lobby: "o nosso também é importante, coloque no Nível 1". Meio ano depois há mais de 20 categorias de Nível 1 e o canal de SMS trava de novo. Solução: mudanças na lista de níveis passam por revisão. Antes de sair de um projeto, escrevo o processo de revisão no manual de operações — adicionar um alerta de Nível 1 exige dupla aprovação do gerente de operações e do responsável de TI.
Modo de falha 3: dispara e esquece. O alerta aparece como "enviado" no sistema, mas o gateway de SMS descartou silenciosamente 30%. Solução: faça uma checagem mensal de saúde dos alertas — mensagens enviadas vs. entregues. Taxa de entrega abaixo de 95%? Troque de gateway. Coloque essa checagem na pauta da reunião mensal de operações. Não dependa da força de vontade.
Faça as contas: toda essa estrutura custa a um armazém pequeno cerca de RMB 5,000–8,000 por ano em SMS e taxas de plataforma, e a um grande RMB 20,000–30,000. Um alerta de Nível 1 perdido às 2 AM custa o que os dois casos acima mostraram: $400,000 de receita de um dia perdidos, ou uma linha parada 3 horas com 9,000 caixas enviadas a menos. Essa conta você faz sozinho.
Um aprendizado acionável: se você está em seleção ou implementação de WMS agora, coloque o "plano de hierarquização de alertas" no anexo do contrato e assine junto com o blueprint. Não espere uma ligação às 3 AM para perceber que ninguém jamais decidiu isso.
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.
