Quando devo repor este ASIN?

Saber quantas unidades você tem no FBA é fácil. Saber quando vai precisar repor é a parte difícil — e o que separa uma coisa da outra é a velocidade de vendas.

Mil unidades não significam nada sozinhas. A 10 por dia, são cem dias de cobertura. A 50 por dia, são vinte. E se a velocidade passar de 10 para 50, o plano que você fez no mês passado não está só um pouco errado — ele fala de outro negócio.

Por isso, a previsão de reposição não é um número que você calcula uma vez. É uma estimativa permanente, que deve mudar toda vez que as evidências mudam.

Uma ressalva, feita uma vez só: uma data de reposição prevista não é uma profecia. É o resultado de um cálculo sobre premissas que você consegue nomear. Quando uma premissa muda, a data muda. É o sistema funcionando, não falhando.

Veja como montar essa estimativa e — o que é mais útil — como interpretá-la.

01Duas datas, não uma

Os vendedores perguntam: “quando vou ficar sem estoque?” O sistema precisa responder primeiro a uma pergunta mais difícil.

• A data de ruptura é quando o estoque utilizável chega a zero, com base numa premissa de demanda explícita.
• A data-limite do pedido é o último dia em que você pode fazer o pedido e ainda receber as unidades antes que isso aconteça.

Entre as duas está todo o seu lead time de reposição, mais a folga que você decidiu manter. Com um fornecedor de 60 dias, um ASIN com 45 dias de cobertura não está confortável — já está quinze dias atrasado.

Esperar o estoque parecer baixo é uma estratégia que só funciona se o seu fornecedor for mais rápido do que os seus clientes.

Cada seção a seguir existe para tornar uma dessas duas datas mais honesta.

02O problema da janela, e como resolvê-lo de verdade

Velocidade de vendas é unidades vendidas ÷ dias. A aritmética é trivial. A escolha dos dias é a decisão inteira.

A escada é monotônica: cada janela mais curta é mais rápida que a anterior. Esse formato é o sinal — não uma linha isolada. Ele diz que a demanda está acelerando, e diz isso de forma mais convincente do que um número de 7 dias jamais conseguiria sozinho, porque um pico aparece em uma janela, enquanto uma tendência aparece em todas.

Um padrão que você consegue defender

Combine a janela que reage rápido com a estável, dando mais peso ao período recente:

velocidade ponderada = 0.6 × (últimos 7 dias)
                     + 0.4 × (últimos 30 dias)

                     = 0.6 × 47.1 + 0.4 × 40.0
                     = 44.3 unidades/dia

Isso reage a uma mudança real em cerca de uma semana e não se deixa arrastar por um único dia atípico, como acontece com um número bruto de 7 dias. Use-o como padrão e só o substitua de forma deliberada.

Quando substituí-lo

Desconte a janela curta quando você consegue nomear a causa e a causa tem data para acabar. Um cupom que vale até sexta-feira, um concorrente que volta a ter estoque em duas semanas, o efeito residual do Prime Day — isso são eventos, não demanda. Recalcule a previsão pelo patamar anterior ao evento e anote quando conferir de novo.

Confie na janela curta quando a escada é monotônica e a diferença persiste por duas semanas seguidas. Um salto sem causa identificável costuma ser uma mudança real de ranqueamento ou de posição competitiva.

03Ancore nos dados, não no dia de hoje

Esta é a falha que, sem alarde, estraga mais previsões de reposição do que qualquer escolha de modelagem.

Os seus dados de vendas terminam em alguma data. Raramente é hoje — os relatórios fecham com atraso, as importações rodam em horários programados, alguém esqueceu. Se os seus dados de transações vão até 5 de setembro e o seu sistema calcula os “últimos 30 dias” a partir da data de hoje, ele mistura na média vendas reais com dias que ainda não têm dado nenhum.

Doze dias de atraso numa janela de 30 dias subestimam a velocidade em cerca de 40%. Divida o seu estoque por esse número e o sistema mostra uma cobertura confortável para um SKU que está prestes a zerar — em verde, com toda a confiança.

Duas regras resolvem isso de vez:

• Calcule toda taxa em relação ao último dia que os dados realmente cobrem, não ao relógio.
• Projete toda data para a frente a partir dessa mesma âncora — e mostre a âncora na tela, onde quem lê possa vê-la.

Uma previsão que não diz quão antigos são os seus dados de entrada está pedindo a sua confiança justamente no ponto em que é mais fraca.

04O que realmente conta como disponível

Nem toda unidade ligada a um ASIN pode atender o próximo cliente. Antes de qualquer projeção, separe:

• Vendável — as únicas unidades que atendem a demanda hoje.
• Reservado — alocado a pedidos, em transferência entre centros de distribuição ou em processamento. Real, mas ainda não disponível.
• Não vendável — danificado, vencido, encalhado. Presente na conta, ausente da previsão.
• Em trânsito — não é estoque. Mas também não é nada. Veja a próxima seção.

Duas dessas categorias costumam inflar a previsão. Contar unidades reservadas como vendáveis rende alguns dias fantasmas; contar o estoque em trânsito como disponível rende semanas fantasmas.

05Estoque em trânsito é uma data, não uma quantidade

O atalho comum — somar o disponível e o em trânsito e dividir pela velocidade — produz um número que quase nunca está certo, porque supõe que 800 unidades num navio podem ser vendidas hoje.

Em vez disso, modele o estoque como uma curva. Ela cai no ritmo da sua velocidade, sobe em degrau na data de chegada e volta a cair.

Esse quase-desastre é invisível em qualquer cálculo que trate o estoque em trânsito como um bloco único. É o argumento mais forte para modelar o estoque como uma linha do tempo.

E significa que um aviso de atraso é um dado de entrada da previsão, não um incômodo: adie a chegada em dez dias e a projeção deve mudar no momento em que você registra isso.

06O lead time é uma faixa que você já mediu

A maioria dos erros de reposição vem de um lead time que alguém digitou uma vez, com otimismo, em outro ano.

Você não precisa estimá-lo. Você já fez os pedidos. Meça do pedido feito até as unidades vendáveis — a cadeia inteira, não só a fábrica:

fabricação 20d + preparação 5d + trânsito 25d + recebimento 5d

No AB-2210, os últimos cinco pedidos levaram 48, 53, 59, 67 e 72 dias. A média é 60. Ficar só com a média joga fora a coisa mais útil dessa lista — a dispersão.

lead time médio      = 60 dias
pior caso observado  = 72 dias
folga de lead time   = 72 − 60 = 12 dias

Esses doze dias não são gordura. São o custo observado de o seu fornecedor ser quem ele sempre é num mês ruim. Se o SKU for volátil, some por cima uma reserva para a variabilidade da demanda.

Seja qual for a sua escolha, a premissa tem de aparecer na tela. Uma data de reposição calculada a partir de um lead time que quem lê não consegue ver é um número do qual não há como discordar — e o vendedor costuma saber algo que o sistema não sabe.

07O cálculo completo, em um SKU

Agora cada dado de entrada tem um valor defensável. O ponto de reposição é o nível abaixo do qual você não pode cair:

ponto de reposição = velocidade × (lead time + folga)
                   = 44.3 × (60 + 12)
                   = 3,190 unidades

O AB-2210 tem 1,240 unidades disponíveis e 800 em trânsito. Mesmo contando as duas, fica em 2,040 — bem abaixo de 3,190. Ele cruzou o ponto de reposição há algum tempo.

A data diz a mesma coisa:

ruptura projetada      ≈ 21 out   (pela curva acima)
menos lead time            60 d
menos folga                12 d
──────────────────────────────────
data-limite do pedido  ≈ 10 ago   — há 30 dias

Este é o resultado para o qual o artigo vinha caminhando, e é o mais comum: um SKU que parece saudável — seis semanas de cobertura, uma remessa no mar — está um mês atrasado no próximo pedido. Os dias de cobertura esconderam isso. Só a data revelou.

Quando isso acontece, as perguntas mudam. Não é mais “devo fazer o pedido?”, e sim: quanto consigo acelerar, quanto custa o frete aéreo em comparação com a ruptura que ele evita e se vale dividir o pedido para colocar alguma coisa em movimento agora.

08Mostre a faixa, não a data

Um sistema que exibe “Repor até 10 de agosto” disse a verdade e criou uma impressão falsa ao mesmo tempo. O número parece um fato. É uma conclusão apoiada numa premissa de velocidade que poderia, com toda a razão, ter outros três valores.

Então mostre o peso dessa premissa:

Olhe esse bloco por um instante e você aprende algo que nenhuma data isolada poderia mostrar: o debate sobre a janela não importa aqui. Toda premissa plausível coloca a data-limite do pedido no passado. A questão da velocidade é real, mas não é a questão deste SKU — agora ela só decide a quantidade, não se é preciso agir.

Em outro SKU, as mesmas três linhas podem cobrir seis semanas e cair dos dois lados da data de hoje. Aí a premissa é a decisão, e merece uma tarde de análise. Mostrar a dispersão é o que permite ao vendedor distinguir essas duas situações num relance.

09O que “tempo real” deveria significar de verdade

Não é recalcular a cada segundo. Ninguém decide um pedido de compra num ritmo de cinco minutos, e uma previsão que se mexe a cada oscilação diária ensina você a ignorá-la.

Tempo real deveria significar orientado a eventos: a projeção se atualiza quando algo que a alimenta muda.

• Chegam novos dados de vendas
• O estoque se movimenta, ou unidades se tornam não vendáveis
• Uma remessa é despachada, chega ou atrasa
• Um pedido de compra é feito, recebido, ou tem as datas alteradas
• Você altera um lead time ou uma meta de cobertura

E deveria vir acompanhado de uma regra sobre quando avisar você. Alerte quando uma conclusão muda, não quando um número muda: uma data-limite do pedido que passa de hoje, uma data de ruptura que se move mais de uma semana, um SKU que cai abaixo do ponto de reposição. Todo o resto é uma tela que você pode consultar.

Uma atualização mensal deixa passar mudanças reais. Uma atualização constante fabrica mudanças falsas. O ritmo certo é o de um sistema que recalcula a cada evento e só interrompe você por conclusões.

10Medir os acertos é o que faz a previsão melhorar

Guarde o que você previu. Compare com o que aconteceu. Sem isso, um sistema de previsão nunca melhora — só continua errando com confiança, sempre na mesma direção.

Vale acompanhar três desvios por SKU:

• Desvio de velocidade — previsto 40/dia, real 52/dia. Um erro isolado é ruído; o mesmo sinal quatro semanas seguidas é um problema de configuração que você pode corrigir.
• Desvio de lead time — cada pedido de compra concluído é uma medição gratuita. Leve-a direto para a média e para o pior caso.
• Desvio de chegada — com que frequência o estoque em trânsito chega na data que informaram a você? Esse número é a sua necessidade real de folga, e costuma ser maior do que a que você escolheu.

Com o tempo, isso transforma o lead time e a folga de opiniões em observações. É aí que entra o efeito composto; a aritmética nunca foi a parte difícil.

11A lista de verificação

1. Encontre a última data coberta pelos seus dados de vendas. Ancore tudo nela.
2. Separe o vendável do reservado, do não vendável e do em trânsito.
3. Calcule a escada de velocidades — 7, 30, 60, 90 — e leia o formato dela.
4. Defina a velocidade de referência: ponderada por padrão, substituída só por uma causa que você consegue nomear.
5. Projete o estoque como uma curva, que sobe em degrau em cada data de chegada do estoque em trânsito.
6. Meça o lead time com base nos seus próprios pedidos de compra; guarde a média e o pior caso.
7. Defina a folga a partir da dispersão, mais uma reserva para a demanda se o SKU for volátil.
8. Calcule o ponto de reposição e a data-limite do pedido. Sinalize o que já tiver passado.
9. Mostre a data-limite do pedido em três velocidades, não em uma.
10. Recalcule a cada evento; alerte só quando uma conclusão mudar.
11. Registre a previsão e avalie o acerto depois.

Onze passos, e só dois deles são aritmética. O resto é decidir no que você acredita e anotar isso num lugar onde possa conferir depois.

Perguntas frequentes