Era 8h de uma segunda-feira e meu café ainda não tinha terminado de passar quando o telefone tocou. Um cliente jogou um print no nosso chat em grupo: 47 pedidos parados na fila de exceções do OMS, todos marcados como «produto não correspondente». A Black Friday tinha ficado três semanas para trás, a temporada de devoluções estava a todo vapor, e se aqueles 47 pedidos ficassem ali por muito mais tempo, o atendimento ao cliente ia afundar.
Entrei remotamente, dei uma olhada e tive que rir. Nada estava quebrado. Na semana anterior, eles tinham aberto uma nova loja na TikTok Shop, e a operação tinha publicado cerca de vinte best-sellers usando as convenções de SKU da TikTok, que não batiam com nada no OMS. Os pedidos entravam normalmente — o OMS simplesmente não reconhecia nenhum desses SKUs, então fez a única coisa que podia: colocou todos na fila de exceções, esperando que um humano viesse reclamá-los.
Este é o problema mais comum, e o mais subestimado, das vendas multicanal: o mapeamento de produtos por canal. Um produto, cinco nomes. Na Amazon é AMZ-BLK-HOODIE-L, no Walmart é WM_98213, na loja Shopify é HOODIE-BLK-L-2024, na TikTok Shop é TTS@hoodie-black-l. Cinco nomes, um único moletom físico. No momento em que um pedido é puxado de um canal para o OMS, o sistema precisa saber que esses cinco nomes apontam para a mesma coisa. Caso contrário, na melhor das hipóteses você ganha uma pilha de exceções — na pior, envios errados e baixas de estoque erradas.
Vinte anos nesse negócio me ensinaram uma coisa com certeza: a tabela de mapeamento não é uma planilha. É a fundação sob todo o fluxo de pedidos do OMS. Erre a fundação e tudo a jusante — o fulfillment no WMS, a conciliação financeira — inclina junto.
Como é de verdade uma tabela de mapeamento
Direto ao ponto: a granularidade correta do mapeamento não é «canal». É «canal × loja».
Muitas empresas constroem sua primeira tabela de mapeamento no nível do canal — SKUs da Amazon para produtos do OMS, SKUs do Walmart para produtos do OMS. Aí abrem uma segunda loja na Amazon, digamos uma loja principal da marca mais um outlet de liquidação, ambas vendendo o mesmo produto com SKUs de canal diferentes, e a tabela desmorona. Então desde o dia um, a chave de mapeamento deve ter três partes: canal mais loja mais SKU do lado do canal.
Uma tabela de mapeamento funcional precisa de apenas um punhado de colunas: código do canal, ID da loja, o SKU cru do lado do canal, uma foto do título do lado do canal, o ID do produto correspondente no OMS, um status e uma data de vigência. Sempre me perguntam por que insisto na foto do título. Porque quando alguém faz a triagem da fila de exceções, um olhar no título diz do que provavelmente se trata o pedido — dez vezes mais rápido do que adivinhar a partir de uma string de SKU. E não pule a coluna de status. Quando um produto sai de catálogo num canal, marque o mapeamento como desabilitado; não o apague. Apagou, e seus pedidos históricos perdem todo o registro de como foram traduzidos. A conciliação vira um pesadelo.
Mais três lições de campo.
Primeiro, sempre compare pelo SKU do lado do canal, nunca pelo título. Títulos são o que o pessoal de operação reescreve o dia todo — «Hot Sale» hoje, novas palavras-chave amanhã. Comparar por títulos significa reconstruir seus mapeamentos diariamente. SKUs são comparativamente estáveis. São a âncora mais confiável num pedido de canal.
Segundo, normalize caixa e espaços antes de comparar. Um SKU chega da Shopify com um espaço no final, o lado da Amazon é tudo em maiúsculas e o OMS guarda em minúsculas — três strings diferentes para o sistema, um produto para o olho humano. Coloque tudo em minúsculas e apare os espaços antes da tradução, e uma linha de código elimina cerca de um terço das suas exceções «falsas».
Terceiro, mantenha o UPC como chave de reserva. SKUs são nomes que cada canal inventa; o UPC é o número de identidade do produto, e é o mesmo em todo lugar. Registre-o no cadastro de produtos quando cadastrar um item novo. Quando um SKU não coincidir, faça uma passagem contra o UPC. Ele resgata um número surpreendente de pedidos.
Para onde vão os pedidos sem correspondência
Pedidos que falham na tradução pertencem a uma fila de exceções. Não se apagam, e definitivamente não se criam à força.
A fila precisa resolver três problemas: impedir que exceções bloqueiem pedidos bons, deixar as pessoas resolverem rápido e recuperar pedidos automaticamente depois de corrigidos. Minha configuração padrão: quando o job de puxar pedidos encontra um SKU sem mapeamento, ele não cria um pedido no OMS. Escreve um registro de exceção — canal, loja, SKU do canal, título, quantidade, hora do pedido — marcado como «não reclamado». Os pedidos bons continuam fluindo sem um segundo de atraso.
Um humano varre a fila duas vezes por dia — 10h e 16h, quatro vezes na alta temporada. Há apenas três jogadas. Reivindicar: confirmar a qual produto do OMS corresponde este SKU do canal, adicionar o mapeamento e o pedido se retraduz sozinho. Mesclar: o mesmo comprador pediu em vários canais, então mescle os pacotes conforme a política da empresa. Ou eliminar: pedidos de teste e fraudes são encerrados.
Aqui está a dolorosa lição por trás dessa rotina. Thanksgiving 2023, um cliente 3PL em Ontario, Califórnia, colocou mais de duzentos SKUs novos no ar para a Black Friday sem construir os mapeamentos primeiro. O job de puxar enfileirou obedientemente cada exceção — e ninguém olhou, porque todos assumiram que «o sistema cuida». Três dias depois a fila tinha mais de novecentos pedidos, e o atendimento ao cliente já tinha aguentado três rodadas de ligações furiosas. Desde então minha regra para cada cliente: a fila de exceções deve ter um dono, é verificada pelo menos quatro vezes por dia no pico, e mais de 50 pedidos enfileirados dispara um alerta por SMS. Uma fila que ninguém vigia é o mesmo que não ter fila.
Um caso especial merece seu próprio parágrafo: bundles. Um SKU de canal mapeado para dois produtos do OMS — o clássico SKU de pacote «compre um moletom, ganhe meias» — é uma relação um-para-muitos. A tradução precisa dividi-lo em duas linhas de pedido, cada uma baixando seu próprio estoque. Muitos produtos OMS suportam apenas mapeamentos um-para-um, então pergunte sobre suporte um-para-muitos durante a seleção. Descobrir depois do go-live significa ficar remendando um sistema em produção.
Integrar um canal novo em três etapas
Todo canal novo começa seus mapeamentos do zero. Meu manual padrão é de três etapas, e até hoje nunca me falhou.
Etapa um: exporte a lista completa de SKUs e concilie antes de vender qualquer coisa. Uma vez construída a loja e publicados os produtos, o primeiro trabalho não é vender — é exportar a lista viva de SKUs do backend do canal e confrontá-la linha a linha com o cadastro de produtos do OMS para construir a primeira tabela de mapeamento. Para cada falha, decida na hora: o produto está faltando no OMS (crie-o), ou a operação nomeou errado o SKU do canal (corrija)? A ordem é sempre «mapeamentos primeiro, vendas depois». Inverta-a e você ganha aquelas 47 exceções da segunda-feira de manhã.
Etapa dois: conecte a extração de pedidos, e entregue tradução e tratamento de exceções juntos. Quando a integração API estiver pronta, não vá a volume total. Repita os últimos sete dias de pedidos reais pelo fluxo de tradução e confira a cobertura do mapeamento. Minha régua é 98% — abaixo disso, a primeira tabela de mapeamento tem buracos, então vá preenchê-los. Uma vez aprovado o replay, ligue a extração ao vivo, e certifique-se de que as regras de alerta da fila estejam configuradas antes de os problemas reais chegarem, não depois.
Etapa três: concilie por uma semana. O canal não está integrado até a cobertura se sustentar. Todo dia, cruze três números: a contagem de pedidos do lado do canal, a contagem de pedidos bem-sucedidos no OMS e as novas exceções na fila. Diariamente na primeira semana, em dias alternados na segunda, e depois passe para as verificações de rotina quando estiver limpo. A tabela de mapeamento de um canal novo ganhará algumas linhas quase todo dia nas primeiras duas semanas — isso é normal. SKUs de cauda longa sempre escapam, e uma vez que o processo esteja rodando redondo, adicionar um mapeamento leva dois minutos.
Percorra essas três etapas e um canal novo está genuinamente no ar no OMS. Quando a operação quiser adicionar um sexto ou sétimo canal, ela roda o mesmo manual e fica pronto em um dia.
Apêndice: a tabela de mapeamento, pronta para copiar
- mapping_id: chave primária, gerada pelo sistema
- channel_code: p. ex. amazon, walmart, shopify, tiktok-shop
- store_id: distingue múltiplas lojas num canal
- channel_sku: SKU cru do lado do canal; índice único em (channel_code, store_id, channel_sku)
- channel_title: foto do título para triagem humana
- oms_product_id: a chave do produto correspondente no OMS
- qty_factor: multiplicador de quantidade para dividir bundles um-para-muitos (padrão 1)
- upc: chave de reserva quando o SKU falha
- status: ativo ou desabilitado — fora de catálogo significa desabilitado, nunca apagado
- effective_from: quando o mapeamento passa a valer
- updated_by, updated_at: quem mexeu, quando
- note: contexto, p. ex. "first batch, TikTok new store, BF 2026"
Uma tabela, uma dúzia de colunas. Mantenha-a limpa e os pedidos multicanal não têm como dar errado.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
