A resposta curta: não comece por um modelo de previsão de demanda. Crie primeiro uma camada de elegibilidade entre ERP ou OMS, catálogo, mídia e CRM. Para cada SKU, variante, local e mercado, ela deve responder se o produto pode ser promovido agora, com qual prazo, preço e contribuição, e qual fallback usar quando a resposta estiver vencida. Regras tratam restrições duras; previsão e otimização entram depois. Meça gasto e contatos em itens elegíveis, cancelamentos e contribuição após atendimento e fulfillment — com alcance e conversão como contramétricas.
O problema raramente é apenas falta de estoque. Um item pode existir fisicamente, mas estar comprometido com pedidos, separado como estoque de segurança, indisponível em uma região, sem capacidade de instalação ou com margem insuficiente depois de frete. Se cada canal recebe uma versão diferente desse estado, a plataforma continua comprando cliques e o CRM continua enviando ofertas que a operação não consegue cumprir.
Escreva o Contrato de Elegibilidade de Demanda
- Unidade — SKU, variante, local, mercado e canal em que a decisão vale.
- Estado vendável — disponível, comprometido, reservado, indisponível, a caminho, backorder e estoque de segurança.
- Promessa — prazo, retirada, instalação, capacidade de atendimento e região atendida.
- Economia — preço, desconto, contribuição mínima e custo variável de fulfillment.
- Vigência — instante de atualização, idade máxima aceita e próxima atualização esperada.
- Ação — promover, reduzir, redirecionar, substituir, esperar ou suprimir.
- Fallback — categoria, substituto, aviso de reposição ou mensagem institucional segura.
- Resultado — gasto elegível, venda, cancelamento, atraso, substituição, margem e experiência.
- Owner — responsáveis por fonte, regra, canal, incidente e decisão de escala.
O Contrato impede que um score opaco substitua uma regra operacional. Um modelo pode prever reposição ou probabilidade de venda, mas não deve declarar disponibilidade quando o sistema de pedidos reservou as últimas unidades. A decisão precisa ser versionada para explicar qual estado foi enviado a cada canal e quando expirou.
Conecte cinco fontes antes de otimizar
- Identidade — SKU e variante consistentes entre PIM, catálogo, OMS, site, CRM e plataformas.
- Inventário — disponível por local depois de comprometidos, reservas e segurança.
- Promessa — prazo e capacidade por CEP, região, serviço ou loja.
- Economia — preço, desconto, custo de mídia, frete e contribuição mínima.
- Demanda — impressão, clique, contato, carrinho, pedido, cancelamento, substituição e atraso.
O Shopify distingue disponível, comprometido, indisponível, em mãos e a caminho. O Google Merchant Center exige que a disponibilidade enviada corresponda à página e ao checkout. Juntas, essas definições expõem o erro comum: publicar quantidade física como se fosse disponibilidade comercial. O estado promocional precisa refletir reserva, localização, promessa e política, não somente a coluna de estoque.
Escolha a tecnologia proporcional à decisão
- Regra e feed — quando há um canal, poucos mercados e restrições claras.
- Atualização nativa — útil como proteção contra divergência de preço ou disponibilidade, não como fonte de verdade.
- Camada de integração — necessária quando mídia, CRM e loja precisam consumir a mesma decisão.
- Previsão — faz sentido quando o horizonte de reposição e a incerteza alteram quanto promover.
- Otimização — só depois, quando produtos, mercados e orçamentos competem pela mesma capacidade.
Não confunda sincronização com inteligência. Um feed rápido pode propagar uma decisão errada; um modelo sofisticado pode trabalhar sobre dados atrasados. Primeiro prove identidade, latência, fallback e reconciliação. Depois compare regras, recursos nativos e previsão em modo sombra.
Um piloto de oito semanas
- Semanas 1–2 — escolher uma categoria, um canal pago e uma jornada de CRM; medir gasto inelegível, cancelamento, atraso e contribuição.
- Semana 3 — reconciliar SKU, variante, local, estoque vendável, promessa e economia.
- Semana 4 — publicar decisões em modo sombra e medir divergência, idade do dado e cobertura.
- Semana 5 — ativar regras duras, fallback e logs em um canal, sem previsão.
- Semanas 6–7 — liberar orçamento ou contatos limitados e preservar comparador por mercado, produto ou período.
- Semana 8 — decidir se integração e regras bastam ou se previsão e otimização pagam a complexidade.
Meça demanda que a operação consegue cumprir
- Elegibilidade — parcela do gasto, impressões e contatos destinada a itens válidos.
- Frescor — idade do estado, atraso de propagação e divergência entre canal e checkout.
- Venda — conversão, receita, substituição, backorder e cancelamento.
- Economia — contribuição após desconto, mídia, frete, atendimento e exceção operacional.
- Experiência — prazo quebrado, reclamação, aviso de reposição e satisfação.
- Operação — fallback, override, incidente, tempo de resolução e horas manuais.
- Contramétricas — alcance, descoberta de produto novo, velocidade de giro e demanda suprimida por excesso de cautela.
Reduzir impressões de itens indisponíveis não prova receita incremental. A campanha pode perder alcance ou aprendizagem; o estoque pode mudar depois do clique; produtos novos podem ser excluídos por falta de histórico. Use um comparador e avalie contribuição, cancelamento e experiência no mesmo recorte.
Custos, responsabilidades e limites
O custo cresce com SKUs, locais, países, canais, frequência de atualização, reservas, moedas, promessas e operação contínua. Commerce mantém catálogo e política; operações define estoque vendável e capacidade; marketing define objetivo e fallback; CRM governa contato; dados reconcilia eventos; tecnologia integra ERP, OMS, PIM e APIs; finanças define contribuição; atendimento devolve causas de falha. O NIST recomenda governar, mapear, medir e gerenciar riscos ao longo do ciclo.
Leve um feed real para o diagnóstico
Conecte o projeto às recomendações de produto em https://makinai.co/insights/pt/ia-recomendacoes-produtos-ecommerce-conversao-margem, à prevenção de devoluções em https://makinai.co/insights/pt/ia-reduzir-devolucoes-ecommerce-proteger-margem, à mídia além da automação das plataformas em https://makinai.co/insights/pt/ia-midia-paga-alem-automacao-google-meta e à decisão entre tempo real e batch em https://makinai.co/insights/pt/ia-tempo-real-crm-quando-batch-basta. A MAKINAI implementa CRM e commerce em https://makinai.co/services/pt/consultoria-crm-ecommerce-commerce. Traga uma categoria, o feed atual e quatro semanas de pedidos, cancelamentos e mídia; podemos delimitar o menor piloto útil.
O piloto não garante mais receita ou margem. Inventário de parceiros pode permanecer incompleto, plataformas podem manter cache e regras conservadoras podem suprimir demanda válida. As fontes sustentam consistência de disponibilidade, estados de inventário e controles contínuos; o Contrato e o desenho do piloto são recomendações editoriais da MAKINAI a validar na operação.