Meu veredito de saída: na noite antes de uma grande venda, não teste a carga do seu tráfego — cronometre quanto tempo uma mudança de preço leva para chegar a cada canal. Os campos de preço precisam viajar por push em tempo real. Se o seu ainda depende de consulta com intervalo acima de cinco minutos, você está sentado sobre uma bomba-relógio. Vi uma explodir na Black Friday 2023.
O armazém era um 3PL de 120,000 pés quadrados em Fontana. Às 7 AM daquela sexta, o cliente derrubou o preço promocional de um alto-falante Bluetooth de $29.99 para $19.99 no back-end do canal, esperando que a oferta entrasse no ar às 8. O canal aplicou em menos de um minuto. Mas o OMS consultava os preços do canal a cada 15 minutos, e a enxurrada de pedidos da Black Friday tinha congestionado a fila de sincronização por mais de uma hora além disso. Quando o novo preço finalmente chegou ao OMS e desceu para o faturamento do WMS, eram 10 AM. Nessas duas horas, mais de 1,400 pedidos pagaram ao preço de página de $19.99 enquanto o OMS tinha travado $29.99. O atendimento ao cliente foi soterrado por tickets de "por que me cobraram $10 a mais?", e depois que a empresa decidiu honrar o preço da página, só os créditos de compensação custaram bem mais de dez mil dólares. A lição ficou comigo: o estrago do atraso de preços é irreversível. Depois que um pedido trava o preço errado, as caixas ainda têm que sair, e o dinheiro simplesmente foi embora.
Desde então tenho um hábito: quando alguém me fala de seleção de OMS, o diagrama do fluxo de sincronização de preços é o primeiro que peço para ver.
Quantas mãos um preço passa antes de virar um pedido
Editar o preço no back-end do canal é só o passo um. A mudança tem que viajar pela API ou webhook do canal até o OMS, ser gravada no mestre de preços do OMS, passar por uma checagem de janela de vigência que decide a que preço este pedido tem direito, e finalmente ser congelada no pedido e empurrada para o WMS e o financeiro. A cadeia parece simples, mas cada mão nela pode ficar sentada sobre o preço sem fazer nada — o canal enviou, o OMS nunca recebeu; o OMS recebeu, nunca gravou; gravou, mas a janela de tempo não bateu. Travar o preço em um pedido é uma porta de mão única. Uma vez travado, nenhuma sincronização atrasada consegue alcançá-lo. Então a sincronização de preços não é uma questão de precisão, é uma questão de velocidade. Duas horas atrasadas e duas horas erradas custam exatamente a mesma coisa.
A estação de empacotamento é o último lugar onde um pedido com preço errado poderia teoricamente ser pego, e não consegue pegá-lo. O empacotador puxa o gatilho do scanner Zebra, o WMS imprime a etiqueta e baixa o estoque contra o preço congelado do pedido — a arma lê códigos de barras, não preços. Uma vez que a caixa toca o transportador, o pedido com preço errado está a caminho. O curativo que depois coloquei naquela unidade de Fontana foi uma checagem de preço na verificação do empacotamento: se o preço congelado do pedido não bate com o preço atual do canal, a tela da estação pisca em vermelho e trava o pedido. Isso estanca o sangramento. A doença continua na cadeia de sincronização.
Os três lugares onde o atraso se esconde
O primeiro é o intervalo de consulta. Muitos OMS consultam os preços do canal a cada 15 ou até 30 minutos. Tudo bem numa terça-feira calma. Na Black Friday as APIs do canal limitam, as respostas ficam lentas, e um ciclo de consulta se estica até três — 15 minutos viram uma hora. Minha opinião é direta: se o seu campo de preço consulta em qualquer coisa acima de cinco minutos, mude para push em tempo real na alta temporada. Não negociável.
O segundo é o push perdido. Webhooks soam em tempo real, mas entre o canal disparar e o OMS receber, um timeout, um erro 500, um soluço de rede significa que a mensagem simplesmente sumiu. Muitos sistemas não tentam de novo, ou tentam algumas vezes, falham, e estacionam a mensagem numa fila de cartas-mortas que ninguém olha. Mudanças de preço feitas de madrugada antes de uma venda caem nessa armadilha com mais frequência — ninguém está olhando às 3 AM, e de manhã o preço nunca chegou enquanto os pedidos rodaram a noite toda.
O terceiro é o desencontro da janela de vigência. A promoção do canal diz "válido das 8:00 AM às 11:59 PM," mas o OMS guarda um preço nu sem horários de início e fim. Ou o OMS avalia a janela no horário do servidor enquanto o canal roda no horário do Pacífico — um silencioso descompasso de três horas. Fontana explodiu na combinação dos dois primeiros, mas vi tantos sites caírem pela janela de tempo, e esses são mais desagradáveis de depurar: o log de sincronização diz "success", mas cada pedido travou o preço errado. Irritante.
O que testar na noite anterior e como estancar o sangramento
A lista de testes pré-venda não precisa ser longa. Três itens cobrem. Primeiro, mude um preço em staging e cronometre quanto tempo leva para aparecer num pedido do OMS. Mais de dez minutos? Não vá dormir — continue cavando. Segundo, mate o receptor do webhook por dez minutos e verifique se alguém é alertado, e se o sistema se recupera ao voltar. Um push sem alerta é o mesmo que nenhum push. Terceiro, faça um pedido de teste bem na borda de uma janela de tempo promocional, veja qual preço trava, e concilie seu fuso horário do servidor com o do canal de quebra.
Quando realmente explode, a sequência para estancar o sangramento tem uma ordem, e a ordem importa. Primeiro o interruptor de emergência: tire o SKU afetado do ar via API — todos os grandes canais suportam, e é muito mais rápido que um humano clicando. Feche a torneira. Depois estrangule: se o volume de pedidos de um SKU em dez minutos ultrapassar cinco vezes a sua norma diária, dispare um alerta e segure para revisão humana para que os pedidos com preço errado parem de se acumular. Por fim, dê ao atendimento ao cliente uma frase honesta para usar. Aqui vai a minha: "We honor the price shown at checkout." Engolir um preço baixo vendido a mais custa uma fatura; discutir isso custa o cliente. Já fiz essa conta — a primeira é mais barata. E para os pedidos com cobrança a mais, reembolse rápido e peça desculpas de forma específica. Não deixe o cliente descobrir sozinho.
Vá perguntar ao seu TI uma coisa: nossa sincronização de preços é push ou poll? Se a resposta vier "I think it's push" — vá verificar hoje à noite. A Black Friday não vai esperar por você.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
