Você tem três unidades daquela peça. O anúncio no marketplace diz três. O balcão vende duas de manhã. À tarde, o marketplace vende duas.
Agora você precisa cancelar um pedido.
No marketplace, cancelar não custa só a venda. Custa posição no ranking, custa o selo de reputação, custa a visibilidade dos seus outros anúncios. Um cancelamento por falta é mais caro do que a margem de vários pedidos bem entregues.
O problema não é o controle de estoque
É comum concluir que o culpado é a falta de controle. Mas a maioria dessas empresas tem controle de estoque — o número está certo no sistema.
O problema é outro: o canal e a loja estão disputando o mesmo número.
Entre a venda no marketplace e a baixa no seu sistema existe um intervalo. Pode ser de minutos, pode ser de uma hora. Nesse intervalo, o balcão continua vendendo. E ninguém está errado — os dois estão olhando o mesmo saldo.
A lógica da consignação
A saída que adotamos no InfoKaw é tratar o marketplace como consignação, e não como uma vitrine do estoque inteiro.
Na prática: você faz uma remessa para o canal. Aquelas unidades passam a ser do marketplace. O anúncio publica o saldo dessa remessa — não o estoque geral da empresa.
O que isso resolve de imediato:
- O balcão para de disputar. O que está no canal já saiu do saldo disponível da loja.
- Você decide a exposição. Tem 10 peças, quer arriscar 3 no canal? Remete 3. O restante continua atendendo a loja.
- O número do anúncio passa a ter dono. Não é “o estoque”, é “o que está no canal”.
É a mesma lógica que qualquer lojista já usa com consignado, só que aplicada a um canal digital. E ela baixa exatamente como consignação: quem consome a remessa é a venda, não a publicação.
Você vai ver esse mesmo conceito com outro nome por aí: estoque reservado, reserva de estoque, estoque dedicado ao canal. A ideia é a mesma — tirar do saldo disponível o que já está comprometido. A diferença é que, aqui, a reserva não é um campo escondido no cadastro do produto: ela tem forma de remessa, com data, quantidade e responsável. Reserva que ninguém enxerga vira número travado que ninguém sabe explicar seis meses depois. Se quiser entender só essa parte, escrevi um artigo separado sobre como funciona a reserva de estoque no Mercado Livre.
As duas decisões técnicas que separam integração boa de integração perigosa
Essa parte é onde integrações se diferenciam, e vale conhecer mesmo que você não vá implementar nada.
Reescrever, nunca somar
Quando o sistema sincroniza o anúncio, ele pode fazer duas coisas com a quantidade: somar ao que já está lá, ou reescrever com o saldo atual.
Tem que reescrever.
Se somar, cada republicação duplica o estoque do anúncio. Você remete 3, sincroniza duas vezes, e o marketplace passa a anunciar 6. Aí o overselling não é azar — é consequência.
Há um efeito colateral dessa escolha que também importa: a publicação não pode atender a própria remessa. Se ela baixasse a pendência, a sincronização seguinte encontraria saldo zero e tiraria o anúncio do ar sozinha. A remessa fica em aberto justamente para alimentar o anúncio; quem a consome é o pedido.
Na conferência, a verdade muda de lado
Toda integração precisa de uma rotina que compare o que está no ERP com o que está no canal. E aqui mora a armadilha.
O instinto é fazer o ERP mandar em tudo: “o sistema é a fonte da verdade, então reescreve tudo no marketplace”. Isso quebra.
Porque:
- Quantidade é nossa. O anúncio deve refletir a remessa em aberto.
- Venda é deles. O marketplace sabe de pedidos que você ainda não importou.
Se a rotina reescrever a quantidade antes de importar as vendas, ela devolve ao anúncio um item que já foi vendido. O produto sai duas vezes, e você descobre na expedição.
Por isso a ordem da correção não é detalhe de implementação, é regra de negócio: primeiro importa a venda, depois acerta a quantidade.
Conferir e corrigir são coisas diferentes
Uma terceira decisão, mais sutil: a rotina que confere não deve ser a mesma que corrige.
Conferência que conserta sozinha esconde a causa. Se um produto diverge toda semana, o que interessa saber é por quê — não que alguém arrumou em silêncio.
É o mesmo princípio do inventário: você confere, olha a divergência, entende, e só então ajusta. Sistema que “se auto-corrige” sem relatório é sistema que transforma um problema de processo em ruído permanente.
O que fazer quando acaba mesmo
Vai acontecer. E há uma diferença enorme entre duas reações:
- Anúncio pausado por estoque zerado: correto. Sai do ar, para de vender, e volta quando você remeter mais. A reputação não sofre.
- Anúncio ativo sem estoque: recebe pedido, você cancela, a reputação sofre.
Pausar não é derrota — é a proteção funcionando. Por isso vale ter alerta de saldo baixo no canal, e não só no estoque geral.
Preço é decisão, não rotina
Um princípio que vale explicitar, porque muita integração erra nisso: a sincronização automática mexe só na quantidade.
Preço muda por decisão sua. Uma rotina que reescreve preço automaticamente — por regra de markup, por câmbio, por qualquer automatismo — mais cedo ou mais tarde publica um valor que você não queria, e no marketplace isso vira venda imediata.
Quantidade se corrige sozinha. Preço se decide.
Por onde começar
- Escolha poucos produtos para o canal. Os de giro previsível e margem folgada. Marketplace não é lugar para estrear com o catálogo inteiro.
- Remeta um saldo que você aceita perder do balcão. Se a peça é crítica para a loja, ela não deveria estar no canal.
- Estabeleça a rotina de conferência e leia o relatório toda semana nas primeiras semanas.
- Meça uma coisa só no primeiro mês: quantos pedidos você cancelou por falta. Esse número vai direto para a sua reputação.
- Só amplie o catálogo depois de um mês sem cancelamento.
No InfoKaw, a integração com o Mercado Livre é direta com a API do canal, sem intermediário no meio — e o estoque do anúncio vem da remessa em aberto, com a baixa acontecendo pela venda. O pedido importado vira lançamento no mesmo sistema que cuida do estoque, do financeiro e da emissão fiscal.
Quer avaliar se o seu catálogo está pronto para o canal? A gente olha junto, com os seus produtos.
