Porque é que a sua loja online vende em excesso: a sincronização de stock do ERP feita corretamente

Barras de nível de stock a fluir através de uma linha tracejada para uma janela de loja online com uma marca de verificação verde

Todos os retalhistas que conhecemos têm a mesma história: a loja online vendeu três unidades de um artigo do qual o armazém tinha zero, seguiu-se um email zangado de um cliente, e alguém declarou a integração «avariada». Normalmente não está. Está a fazer exatamente aquilo para que foi concebida - sincronizar o stock a cada 15 minutos - e o problema é o design.

Vender em excesso é uma questão de consistência

A sincronização de stock situa-se num espetro entre dois custos:

  • Sincronizar com pouca frequência e vende-se o que não se tem.
  • Reservar em tempo real e paga-se por isso - em carga na API do ERP, em latência no checkout e em complexidade de engenharia.

O erro é escolher um único ponto desse espetro para todo o catálogo. Um retalhista com 40.000 SKUs pode ter apenas 200 que alguma vez se aproximam de vender em excesso - produtos de rotação rápida, artigos em promoção, liquidação da última unidade. Esses merecem reserva em tempo real no checkout. Os outros 39.800 são perfeitamente servidos por um feed em lote a cada 15 minutos.

O modelo de três níveis que entregamos

  1. Nível em lote - o padrão. Os níveis de stock fluem do ERP → loja online segundo um calendário. Barato, robusto, adequado para tudo o que tenha uma profundidade de stock saudável.
  2. Nível de limiar - quando a quantidade disponível cai abaixo de um limite configurável, o SKU é automaticamente promovido a atualizações orientadas por eventos.
  3. Nível de reserva - o checkout efetua uma reserva firme no ERP antes de confirmar a encomenda. Reservado para o pequeno número de SKUs em que uma venda em excesso custa mais do que as chamadas à API.

A promoção entre níveis é automática e orientada por dados - a integração observa a sua própria taxa de falhas e ajusta-se. Seis meses depois de implementarmos isto para um grupo retalhista báltico, as vendas em excesso passaram de um canal de incidentes semanal para dois casos por trimestre - e ambos se revelaram saldos de stock corrigidos à mão no armazém: um erro de introdução de dados na origem, não uma falha da sincronização.

Desenhe a integração em torno do custo de errar, e a arquitetura segue-se naturalmente.