Gestão de SKU para Marketplaces Multi-Vendedor: Um Guia Prático

Qualquer pessoa que tenha trabalhado em ecommerce durante mais de alguns meses já se deparou com um problema de SKU. Dois produtos com o mesmo código. Um código que não significa nada seis meses depois. Um ticket de suporte que demora vinte minutos a resolver porque ninguém consegue dizer qual SKU foi realmente enviado.

Num loja de marca única, isso é chato. Numa marketplace de múltiplos vendedores, onde dezenas ou centenas de vendedores estão a criar os seus próprios dados de produtos, é um risco estrutural que se acumula com cada novo vendedor que se junta.

SKU vs. UPC: a confusão que causa problemas reais

Estes dois termos são usados de forma intercambiável, e isso é um erro genuíno, não apenas uma tecnicalidade.

Um SKU, unidade de manutenção de stock, é um código interno que a sua empresa cria para rastrear uma variante específica de produto, um sistema próprio, significativo para si e para os seus fornecedores, mas não para ninguém fora do seu mercado. Um UPC, código universal de produtos, é um código de barras externo e padronizado atribuído a um produto para que possa ser reconhecido em qualquer retalhista ou sistema que o digitalize.

A diferença prática importa aqui especificamente: um marketplace pode e deve controlar completamente a sua própria estrutura de SKU, uma vez que é interna. Um UPC não é algo que se inventa, é emitido e deve manter-se consistente com o que está impresso no produto real. Tratar estes como a mesma coisa leva diretamente a listagens duplicadas, sincronização de inventário quebrada e devoluções que não podem ser associadas ao pedido original.

Porque a gestão de SKUs é um problema diferente num mercado.

Uma loja de marca única apenas tem de implementar um sistema SKU, o seu próprio. Todos os que inserem dados de produtos trabalham para o mesmo negócio, sob as mesmas regras, estejam essas regras escritas ou não.

Um marketplace inverte isto. Cada vendedor chega com os seus próprios hábitos, as suas próprias folhas de cálculo, às vezes o seu próprio sistema de SKU existente de uma loja que já opera em outro lugar. Sem uma estrutura partilhada imposta durante o onboarding, acaba com tantas lógicas de SKU diferentes quantos são os vendedores, e sem uma forma fiável de pesquisar, reportar ou reconciliar entre eles.

É exatamente por isso que a gestão de SKU merece um plano deliberado próprio num marketplace, em vez de ser deixada como um detalhe assumido que os vendedores vão simplesmente resolver.

Como é realmente uma boa estrutura de SKU?

Uma convenção de nomenclatura consistente, aplicada a todos os fornecedores.

Uma estrutura funcional tipicamente codifica o fornecedor, a categoria e a variante no próprio código, algo comoVEND-CAT-COR-COMPRIMENTO. O formato exato importa menos do que o fato de que todos os fornecedores seguem o mesmo.

A unicidade é imposta a nível da plataforma, não deixada à confiança.

O marketplace em si deve rejeitar um SKU que já está em uso, em vez de depender dos vendedores para verificar conflitos por conta própria antes de listar um produto.

Espaço para escalar sem começar do zero.

Uma convenção de nomenclatura construída para 10 fornecedores e 200 produtos deve continuar a fazer sentido para 100 fornecedores e 20.000 produtos, sem necessidade de um projeto completo de renomeação a meio caminho.

Uma separação clara entre SKU e qualquer código externo.

Os UPCs, códigos de barras e números de parte do fabricante podem ser todos armazenados junto com um SKU, mas não devem ser usados como o SKU em si, uma vez que nem sempre estão disponíveis, nem sempre são únicos em diferentes contextos e não estão sob o controle do mercado.

Como realmente corrigir e manter isto: passo a passo

1. Defina o seu formato de SKU antes de integrar o seu primeiro fornecedor.

• Decida o que deve ser codificado no SKU: o identificador do fornecedor, a categoria e a variante são os mais comuns.
• Escreva o formato como uma regra curta e simples que os fornecedores possam seguir sem adivinhações.
• Trate isto como uma política abrangente da plataforma, e não como uma sugestão que cada fornecedor possa interpretar à sua maneira.

2. Incorpore verificações de unicidade no processo de integração e listagem.

• Configuração de produto da Shipturtlesuporta os campos estruturados e a validação necessária para detectar um SKU duplicado antes que uma listagem entre em vivo
• Rejeitar, em vez de apenas sinalizar, um SKU que já existe em outra parte da plataforma.
• Torne isso automático, não um passo de revisão manual que alguém tenha de se lembrar de executar.

3. Migrar os vendedores existentes para a nova estrutura de forma deliberada.

• Os fornecedores que já têm o seu próprio sistema de SKU não mudarão voluntariamente sem uma razão clara e um caminho simples para o fazer.
• Ofereça uma ferramenta de remapeamento em massa ou uma janela de migração curta, em vez de esperar uma reintrodução manual produto a produto.
• Comunique a alteração antes de a implementar, e não depois de os fornecedores descobrirem que os seus antigos SKUs já não funcionam.

4. Separe os campos de SKU dos campos de UPC e código de barras de forma explícita.

• Dê aos fornecedores um campo distinto para o código UPC ou código do fabricante, separado do campo SKU em si.
• Use o UPC para escaneamento de códigos de barras e reconhecimento de produtos, e o SKU para rastreio e relatórios internos.
• Evite qualquer fluxo de listagem que trate estes dois campos como intercambiáveis, pois é exatamente aí que a confusão começa.

5. Auditar em busca de duplicados e inconsistências numa programação regular.

• Uma limpeza única não permanece limpa à medida que novos fornecedores e novos produtos vão sendo adicionados continuamente.
• Defina uma verificação recorrente, mensal é razoável para a maioria dos mercados, para detetar desvios antes que se tornem um verdadeiro fardo de suporte.
• Trate um aumento no número de tickets de suporte relacionados com SKU como um sinal precoce de que a estrutura atual precisa de ser revista, e não apenas como tickets individuais a serem fechados.

6. Vincular a qualidade do SKU ao treinamento de integração de fornecedores

• Novos fornecedores devem ver o requisito de formato SKU durante o processo de integração, e não descobrir após a sua primeira listagem ser rejeitada.
• Um exemplo curto e concreto é mais eficaz do que uma política escrita sozinha.
• Os fornecedores que compreendem a razão por trás, a pesquisa mais rápida, menos disputas e relatórios mais claros, tendem a cumprir mais voluntariamente do que aqueles que são simplesmente instruídos a seguir uma regra.

O que impulsiona o custo de errar nesta situação?

Limpar o caos de SKUs após o facto custa muito mais do que preveni-lo. Um mercado com milhares de SKUs inconsistentes, duplicados ou sem significado enfrenta um verdadeiro projeto de migração de dados para corrigir retroativamente, remapeando produtos, atualizando pedidos históricos e requalificando fornecedores que já desenvolveram hábitos em torno do sistema avariado.

Uma aplicação de marketplace sem código altera significativamente o ponto de partida, uma vez que os campos de SKU estruturados e a validação de unicidade já existem como funcionalidades integradas, em vez de serem algo criado do zero após o problema já ser visível.Veja o que está incluído no conjunto de funcionalidades do Shipturtle.everifique os preços atuaispara números exatos.

Corrija isto antes que se torne um projeto de migração.

Uma estrutura de SKU limpa é muito mais fácil de impor desde o primeiro dia do que adaptar uma vez que centenas de fornecedores já tenham desenvolvido os seus próprios hábitos em torno dela. O custo de acertar isto cedo é uma decisão política. O custo de corrigir isso tarde é um projeto de dados.

Agendar uma demonstraçãopara ver como o Shipturtle impõe a estrutura de SKU e previne duplicações no momento da listagem. Ouexplore o conjunto completo de funcionalidadespara ver o que está incluído antes de começares.