Gestion des SKU pour les places de marché multi-vendeurs : Un guide pratique

Quiconque a travaillé dans l'e-commerce pendant plus de quelques mois a rencontré un problème de SKU. Deux produits avec le même code. Un code qui ne veut plus rien dire six mois plus tard. Un ticket de support qui prend vingt minutes à résoudre parce que personne ne peut dire quel SKU a réellement été expédié.

Dans un magasin à marque unique, c'est ennuyeux. Dans une marketplace multi-vendeurs, où des dizaines ou des centaines de vendeurs créent chacun leurs propres données produits, c'est un risque structurel qui se cumule avec chaque nouveau vendeur qui rejoint.

SKU vs. UPC : la confusion qui entraîne de réels problèmes

Ces deux termes sont utilisés de manière interchangeable, et c'est une véritable erreur, pas juste une question de technique.

Un SKU, un code de gestion des stocks, est un code interne que votre entreprise crée pour suivre une variante de produit spécifique, son propre système, significatif pour vous et vos vendeurs, mais pas pour quiconque en dehors de votre marché. Un UPC, un code universel de produit, est un code-barres standardisé externe attribué à un produit afin qu'il puisse être reconnu par n'importe quel détaillant ou système qui le scanne.

La différence pratique est importante ici : un marché peut et doit contrôler complètement sa propre structure SKU, car elle est interne. Un UPC n'est pas quelque chose que vous inventez, il est attribué et doit rester cohérent avec ce qui est imprimé sur le produit réel. Traiter ces deux éléments comme la même chose conduit directement à des annonces en double, à une synchronisation d'inventaire rompue, et à des retours qui ne peuvent pas être associés à la commande originale.

Pourquoi la gestion des SKU est-elle un problème différent sur un marché ?

Un magasin de marque unique n'a qu'à appliquer un seul système de SKU, le sien. Tous les employés qui saisissent les données produits travaillent pour la même entreprise, selon les mêmes règles, que ces règles soient écrites ou non.

Un marché inverse cela. Chaque vendeur arrive avec ses propres habitudes, ses propres tableurs, parfois son propre système SKU existant d'un magasin qu'il gère déjà ailleurs. Sans une structure partagée imposée lors de l'intégration, vous vous retrouvez avec autant de logiques SKU différentes que de vendeurs, et aucune manière fiable de rechercher, de rendre compte ou de concilier entre elles.

C'est exactement pourquoi la gestion des SKU mérite son propre plan délibéré sur un marché, plutôt que d'être laissée comme un détail supposé que les vendeurs vont simplement résoudre.

À quoi ressemble réellement une bonne structure de SKU ?

Une convention de nommage cohérente, appliquée à chaque fournisseur.

Une structure fonctionnelle encode généralement le vendeur, la catégorie et la variante directement dans le code lui-même, quelque chose commeVEND-CAT-COLOR-TAILLELe format exact compte moins que le fait que chaque fournisseur suive le même.

Unicité appliquée au niveau de la plateforme, pas laissée à la confiance.

Le marché lui-même devrait rejeter un SKU qui est déjà utilisé, plutôt que de compter sur les vendeurs pour vérifier eux-mêmes les conflits avant de lister un produit.

Une marge de manœuvre pour évoluer sans tout recommencer.

Une convention de nommage conçue pour 10 vendeurs et 200 produits devrait toujours avoir du sens pour 100 vendeurs et 20 000 produits, sans nécessiter un projet de renommage complet en cours de route.

Une séparation claire entre le SKU et tout code externe.

Les UPC, les codes-barres et les numéros de pièce du fabricant peuvent tous être stockés aux côtés d'un SKU, mais ils ne doivent pas être utilisés comme le SKU lui-même, car ils ne sont pas toujours disponibles, pas toujours uniques dans différents contextes et ne sont pas sous le contrôle du marché.

Comment vraiment réparer et entretenir cela : étape par étape

1. Définissez votre format SKU avant d'intégrer votre premier fournisseur.

• Décidez ce qui doit être encodé dans le SKU : l'identifiant du fournisseur, la catégorie et la variante sont les plus courants.
• Rédigez le format en tant que règle courte et simple que les fournisseurs peuvent suivre sans deviner.
• Considérez cela comme une politique à l'échelle de la plateforme, pas comme une suggestion que chaque vendeur peut interpréter à sa façon.

2. Intégrer des vérifications d'unicité dans le processus d'intégration et de mise en ligne.

• Configuration du produit de Shipturtleprend en charge les champs structurés et la validation nécessaires pour détecter un SKU en double avant qu'une annonce ne soit mise en ligne
• Rejeter, plutôt que simplement signaler, un SKU qui existe déjà ailleurs sur la plateforme.
• Rendez cela automatique, sans étape de révision manuelle que quelqu'un doit se souvenir d'exécuter.

3. Migrer les fournisseurs existants vers la nouvelle structure de manière délibérée.

• Les vendeurs qui ont déjà leur propre système SKU ne changeront pas volontairement sans une raison claire et un chemin simple pour le faire.
• Proposez un outil de remappage en gros ou une courte fenêtre de migration, plutôt que d'attendre une saisie manuelle produit par produit.
• Communiquez le changement avant de l'appliquer, et non après que les fournisseurs découvrent que leurs anciens SKU ne fonctionnent plus.

4. Séparez explicitement les champs SKU des champs UPC et code-barres.

• Donnez aux fournisseurs un champ distinct pour le code UPC ou le code du fabricant, distinct du champ SKU lui-même.
• Utilisez le code UPC pour le scan des codes-barres et la reconnaissance des produits, et le SKU pour le suivi interne et les rapports.
• Évitez tout flux de liste qui traite ces deux champs comme interchangeables, car c'est exactement là que commence la confusion.

5. Auditez régulièrement pour détecter les doublons et les incohérences.

• Un nettoyage ponctuel ne reste pas propre car de nouveaux fournisseurs et de nouveaux produits sont continuellement ajoutés.
• Définissez un contrôle récurrent, mensuel est raisonnable pour la plupart des places de marché, afin de détecter les dérives avant qu'elles ne deviennent un véritable fardeau de support.
• Considérez une augmentation du nombre de tickets de support liés aux SKU comme un signal précoce que la structure actuelle doit être réexaminée, et pas seulement des tickets individuels à fermer.

6. Lier la qualité des SKU à la formation d'intégration des fournisseurs

• Les nouveaux fournisseurs devraient voir l'exigence de format SKU lors de l'intégration, et non la découvrir après que leur première annonce a été rejetée.
• Un exemple court et concret est plus efficace qu'une politique écrite seule.
• Les vendeurs qui comprennent la logique, une recherche plus rapide, moins de litiges, des rapports plus clairs, ont tendance à se conformer plus volontiers que ceux qui se contentent de suivre une règle.

Qu'est-ce qui influence le coût de cette erreur ?

Nettoyer le chaos des SKU après coup coûte bien plus cher que de le prévenir. Un marché avec des milliers de SKU incohérents, dupliqués ou sans signification fait face à un véritable projet de migration de données pour corriger rétroactivement, en remappant les produits, en mettant à jour les commandes historiques et en reconduisant les fournisseurs qui ont déjà pris des habitudes autour du système défectueux.

Une application de marketplace sans code change considérablement le point de départ, car les champs SKU structurés et la validation d'unicité existent déjà en tant que fonctionnalités intégrées plutôt que d'être quelque chose construit à partir de zéro une fois que le problème est déjà visible.Découvrez ce qui est inclus dans l'ensemble des fonctionnalités de Shipturtle.etvérifiez les prix actuelspour des chiffres exacts.

Corrigez cela avant que cela ne devienne un projet de migration.

Une structure de SKU propre est bien plus facile à appliquer dès le premier jour que de la rétro-fitter une fois que des centaines de fournisseurs ont déjà pris leurs habitudes à ce sujet. Le coût de bien faire les choses dès le début est une décision politique. Le coût de la correction tardive est un projet de données.

Réservez une démopour voir comment Shipturtle applique la structure SKU et empêche la duplication au moment de la liste. Ouexplorez l'ensemble des fonctionnalitéspour voir ce qui est intégré avant de commencer.