Na segunda-feira de manhã após a Black Friday do ano passado, meu telefone acendeu às 7 a.m. O CEO de um cliente me mandou mensagem: "Lao Mi, nossa equipe de atendimento ao cliente está sendo massacrada na internet."
Uma marca de cosméticos, com fulfillment a partir de um armazém 3PL de 120,000-square-foot em Ontario, na Califórnia. Durante toda a Black Friday, a página inicial deles estampava "2-Day Delivery Sitewide." Na manhã de segunda-feira, mais de mil pedidos ainda estavam parados em "awaiting shipment," os telefones não paravam de tocar e as redes sociais os chamavam de golpistas.
Passei aquela tarde no escritório deles desmontando a lógica de promessa de entrega do OMS. O armazém não estava lento — os separadores tinham virado a madrugada trabalhando a semana inteira. O problema real é que o sistema jamais deveria ter feito aquelas promessas. O available-to-promise (ATP) e a promessa de data de entrega são o recurso do OMS que a maioria das equipes configura uma vez e esquece. É também o que mais te deixa com vergonha em público.
Três armadilhas. Vamos percorrer cada uma.
O estoque nos registros não está no armazém
A armadilha número um é a clássica: a conta do ATP está errada.
Available-to-promise parece simples — se você tem, pode vender. Mas o que significa "ter", de fato? Já vi sistemas demais rodando uma fórmula do tipo: estoque físico menos alocado igual a vendável. Parece razoável. Está errado, porque o estoque físico inclui silenciosamente três coisas que você não pode tocar: estoque em trânsito, estoque com reserva flexível (soft-reserved) e estoque congelado pelo QA.
O estoque em trânsito causa o maior estrago. Um cliente de eletroportáteis contava pedidos de compra "já despachados, a caminho" como vendável, com a teoria de que "de qualquer forma chega em três dias." Na semana anterior à Black Friday, uma carga de 8,000 umidificadores ficou parada esperando berço fora do Porto de Los Angeles por nove dias seguidos. O site continuou vendendo o tempo todo — mais de 3,000 unidades, todas com promessa de "3-day delivery." Quando o contêiner enfim atracou, a equipe de atendimento já tinha pedido desculpas até ficar rouca.
O estoque reservado é a segunda mina terrestre. Grandes pedidos de clientes B2B, planos de reposição para Amazon FBA — eles amarram estoque no sistema, mas nada foi despachado fisicamente. Algumas plataformas de OMS registram reservas só no nível do cabeçalho do pedido, não no nível do item, ou reservam sem deduzir do ATP. O pior caso que já vi: o mesmo lote foi reservado uma vez por um pedido B2B e de novo por um plano de reposição FBA, e o ATP deduziu zero vezes. Um lote de estoque, vendido três vezes.
Os bloqueios de QA são os mais sorrateiros. Um lote de recebimento reprova na inspeção por amostragem, o lote inteiro é congelado aguardando resposta do fornecedor, e fica travado no WMS — intocável. Mas se o OMS só lê o número total de estoque físico, nunca enxerga o status de congelado. Naquele armazém de cosméticos em Ontario, 20,000 frascos de sérum foram travados pelo QA por um erro de rotulagem bem antes da Black Friday. O sistema continuou vendendo como se nada tivesse acontecido.
Como verificar? Meu método low-tech: puxe do OMS os números de ATP de vinte SKUs de alto giro, e peça ao armazém para contar fisicamente "o que dá para separar agora mesmo" desses mesmos SKUs. Onde os dois números divergirem, a diferença é uma dessas três coisas. Na hora de corrigir, não tente abraçar o mundo — mude a fórmula para estoque físico menos reservas menos bloqueios, e mostre o estoque em trânsito como linha própria, "previsão de chegada," detalhada por data de chegada. Nada entra na quantidade vendável até estar fisicamente dentro do prédio. Apliquei essa mudança num armazém de 80,000-square-foot em duas semanas. As reclamações de venda acima do estoque zeraram depois disso.
A promessa assume o Armazém A. O pacote sai do Armazém B.
A armadilha dois mora no fulfillment multi-nó. A conta de um único armazém é fácil: despacha hoje mais o tempo de trânsito da transportadora. Some mais armazéns e a coisa complica rápido.
Quando um OMS promete uma data de entrega, precisa responder a duas perguntas: qual armazém despacha, e quantos dias vai levar? Muitos sistemas calculam uma data de entrega bonita para a vitrine usando "o armazém mais próximo do cliente" e, depois que o pedido é feito, o motor de alocação reseleciona o nó com base em "quem de fato tem estoque ao menor custo." A vitrine prometeu os dois dias do armazém A; o pacote sai de fato do armazém B e leva quatro. O cliente acompanha o rastreio, vê "despachado da Califórnia" enquanto mora em Nova York, e é aí que nasce o telefonema furioso.
Tem uma mais sutil: os horários de corte (cutoff) das transportadoras. O sistema calcula a promessa assumindo "despacha hoje," mas não percebe que já são 4 p.m. e o corte diário do armazém era 3 p.m. Esse pedido na verdade despacha amanhã — a promessa já nasceu um dia atrasada. Na alta temporada os armazéns antecipam os cortes, 3 p.m. vira 2 p.m., ninguém atualiza o parâmetro no sistema, e toda data prometida roda um dia atrasada por semanas.
A correção vai na direção oposta: faça a lógica de promessa e a lógica de alocação usarem as mesmas regras. Antes de a vitrine exibir uma data de entrega, rode a alocação de verdade, descubra qual armazém vai despachar de fato, e então calcule o trânsito da transportadora a partir daquele nó mais a checagem de corte. Parece óbvio. Aposto que metade das plataformas de OMS do mercado médio rodam promessa e alocação como dois fluxos de código separados que nunca conversam. É a demonstração que sempre exijo na seleção de sistema: faça três pedidos de teste para CEPs diferentes e confira se a data prometida bate com a alocação real. Se não bater, esse fornecedor está fora.
Chega a alta temporada, e toda promessa desmorona
A armadilha três é da alta temporada. O ATP parece preciso o ano inteiro, e desaba em novembro. A fórmula não é o problema — a concorrência é.
Num dia normal, dezenas de pedidos por minuto, as baixas de estoque acompanham. À meia-noite da Black Friday, milhares de pedidos por minuto entram, e o ATP continua vendendo a partir de um snapshot calculado minutos atrás. O snapshot diz 500 unidades; na realidade, elas se foram em três segundos. Todo mundo que pediu nos dois minutos seguintes continuou recebendo promessa de "em estoque, entrega em 2 dias." O armazém chega na manhã seguinte, não há nada para separar, e as únicas opções são pedir desculpas uma a uma ou esperar a reposição enquanto "2 dias" estica até virar "2 semanas."
Depois tem a dupla venda pré-venda versus pronta-entrega. O marketing faz uma live de pré-venda do "lote que chega semana que vem," enquanto o site continua vendendo o estoque atual. Os dois canais não compartilham um mesmo pool de estoque, então o mesmo lote de entrada é prometido duas vezes. Quando ele chega, dá para metade dos compradores. Os "2-day delivery" da outra metade viram "avisaremos você."
As correções de alta temporada vêm em três partes. Primeiro, dê aos SKUs promocionais seu próprio pool de estoque, fisicamente separado do estoque de venda do dia a dia — pré-venda é pré-venda, pronta-entrega é pronta-entrega, e eles nunca emprestam um do outro. Segundo, aplique bloqueio pessimista (pessimistic locking) no ATP durante as janelas de alta concorrência, ou no mínimo reduza a atualização do snapshot para segundos — isso exige engenharia envolvida, a operação sozinha não resolve. Terceiro, rode um "teste de estresse de promessa" antes do pico: replique o volume de pedidos do pico do ano passado num ambiente de teste e observe quando o ATP começa a mentir. Saber onde quebra antes da hora sai muito mais barato que pedir desculpas depois.
Não troque o sistema às pressas. Verifique nesta ordem.
Muita gente quer arrancar o OMS fora na hora que isso explode. Meu conselho: diagnostique primeiro, depois decida, porque nove vezes em dez essas armadilhas são problemas de configuração, não de plataforma.
Verifique nesta ordem. Primeiro, faça a conciliação física de vinte SKUs e confirme se a fórmula do ATP deduz reservas e bloqueios corretamente. Segundo, faça pedidos de teste para CEPs diferentes e compare a data prometida na vitrine com a alocação real e os horários de corte. Terceiro, replique sua última alta temporada e classifique os pedidos vendidos acima do estoque: quantos vieram de snapshots de concorrência desatualizados, quantos de pré-venda e pronta-entrega compartilhando um pool. Ao fim desses três passos, você vai saber a causa raiz.
Corrija também em ordem de prioridade. Corrigir a fórmula vem primeiro — não precisa de mudança de código. Unificar as regras de promessa e alocação vem em segundo — isso exige tempo de engenharia. O bloqueio de concorrência e a separação de pools vêm em terceiro — programe um mês antes do próximo pico. Nessa sequência, um armazém com três mil pedidos por dia recupera a precisão de entrega ao normal dentro de um trimestre.
Uma última pergunta para você: o número de promessa de entrega no seu sistema — quando foi a última vez que alguém percorreu o piso do armazém com o relatório de ATP e conciliou SKU por SKU? Se você não se lembra, a próxima promessa quebrada provavelmente já está a caminho. Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
