SKU-håndtering for multi-vendor markedspladser: En praktisk guide

Enhver, der har arbejdet med e-handel i mere end et par måneder, har stødt på et SKU-problem. To produkter med den samme kode. En kode, der betyder ingenting seks måneder senere. Et supportticket, der tager tyve minutter at løse, fordi ingen kan fortælle, hvilken SKU der faktisk blev sendt.

I en enkeltmærke butik er dette irriterende. I et multi-leverandør marked, hvor dusinvis eller hundreder af leverandører hver især skaber deres egne produktdata, er det en strukturel risiko, der forstærkes med hver ny leverandør, der tilslutter sig.

SKU vs. UPC: forvirringen der skaber reelle problemer

Disse to termer bruges om hinanden, og det er en ægte fejl, ikke blot en teknikalitet.

En SKU, lagerbeholdningsenhed, er en intern kode, dit firma opretter for at spore en specifik produkttype, et eget system, meningsfuldt for dig og dine leverandører, ikke for nogen uden for dit marked. En UPC, universel produktkode, er en ekstern, standardiseret stregkode, der tildeles et produkt, så det kan genkendes af enhver detailhandler eller system, der scanner det.

Den praktiske forskel betyder noget her specifikt: en markedsplads kan og bør fuldt ud kontrollere sin egen SKU-struktur, da det er internt. En UPC er ikke noget, du opfinder; den udstedes og skal forblive konsistent med det, der er trykt på det faktiske produkt. At behandle disse som det samme fører direkte til duplicate opstillinger, brudt lager-synkronisering og returneringer, der ikke kan matches tilbage til den oprindelige ordre.

Hvorfor SKU-håndtering er et andet problem på en markedsplads

En enkeltmærke-butik skal kun håndhæve ét SKU-system, sit eget. Alle der indtaster produktdata arbejder for den samme virksomhed, under de samme regler, uanset om disse regler er nedskrevet eller ej.

Et marked ændrer dette. Hver sælger ankommer med deres egne vaner, deres egne regneark, nogle gange deres eget eksisterende SKU-system fra en butik, de allerede driver et andet sted. Uden en fælles struktur pålagt ved onboarding, ender du med lige så mange forskellige SKU-logikker, som du har sælgere, og ingen pålidelig måde at søge, rapportere eller afstemme på tværs af dem.

Dette er præcis derfor, at SKU-håndtering fortjener sin egen gennemarbejdede plan på en markedsplads, i stedet for at blive betragtet som en antaget detalje, som leverandørerne bare vil finde ud af.

Hvad en god SKU-struktur faktisk ser ud som

En konsekvent navngivningskonvention, anvendt på hver leverandør.

En en brugbar struktur kodes typisk leverandør, kategori og variant direkte ind i selve koden, noget som.VEND-KAT-FARVE-STØRRELSEDet præcise format betyder mindre end det faktum, at hver leverandør følger det samme.

Unikhed bliver håndhævet på platformniveau, ikke overladt til tillid.

Markedspladsen bør selv afvise en SKU, der allerede er i brug, i stedet for at stole på, at leverandørerne tjekker for konflikter selv, før de opfører et produkt.

Plads til at skalere uden at starte forfra.

En navngivningskonvention, der er bygget til 10 leverandører og 200 produkter, skal stadig give mening ved 100 leverandører og 20.000 produkter, uden at der er behov for et fuldt omdøbningsprojekt midtvejs.

En klar adskillelse mellem SKU og eventuel ekstern kode.

UPCs, stregkoder og producentens delenumre kan alle gemmes sammen med en SKU, men de bør ikke bruges som SKU'en selv, da de ikke altid er tilgængelige, ikke altid er unikke på tværs af kontekster og ikke er under markedspladsens kontrol.

Hvordan man faktisk fikser og vedligeholder dette: trin for trin

1. Definer dit SKU-format, før du onboarder din første leverandør.

• Beslut hvad der skal kodes ind i SKU: leverandøridentifikator, kategori og variant er de mest almindelige.
• Skriv formatet ned som en kort, enkel regel, som leverandører kan følge uden at gætte.
• Behandl dette som en politik for hele platformen, ikke som et forslag som hver leverandør kan fortolke på deres egen måde.

2. Indbyg unikhedskontroller i onboarding- og listeflowet.

• Shipturtle's produktkonfigurationunderstøtter de strukturerede felter og validering, der er nødvendige for at fange en duplikeret SKU, før en opføring går live
• Afvis snarere end blot at flagge et SKU, der allerede findes andre steder på platformen.
• Gør dette automatisk, ikke et manuelt gennemgangstrin, som nogen skal huske at køre.

3. Migrer eksisterende leverandører til den nye struktur bevidst

• Leverandører, der allerede har deres eget SKU-system, vil ikke skifte frivilligt uden en klar grund og en enkel vej til at gøre det.
• Tilby et bulk remapping værktøj eller et kort migrationsvindue, i stedet for at forvente manuel genindtastning produkt for produkt.
• Kommuniker ændringen, før den træder i kraft, ikke efter at leverandørerne opdager, at deres gamle SKU'er ikke længere fungerer.

4. Adskil SKU-felter fra UPC- og stregkodefelter eksplicit.

• Giv leverandører et særskilt felt til UPC eller producentkode, adskilt fra SKU-feltet selv.
• Brug UPC til stregkodeskanning og produktgenkendelse, og SKU til intern sporing og rapportering.
• Undgå enhver opstillingsflow, der behandler disse to felter som danske, da det netop er her, forvirringen begynder.

5. Gennemgå for dubletter og uoverensstemmelser efter en regelmæssig tidsplan.

• En engangsoprydning forbliver ikke ren, da nye leverandører og nye produkter løbende tilføjes.
• Sæt en tilbagevendende kontrol, månedligt er rimeligt for de fleste markedspladser, for at fange afdrift før det bliver en reel supportbyrde.
• Betracht en stigende antal SKU-relaterede supportbilletter som et tidligt signal om, at den nuværende struktur skal genovervejes, ikke bare individuelle billetter, der skal lukkes.

6. Knyt SKU-kvalitet til leverandørens onboarding-træning.

• Nye leverandører bør se kravene til SKU-formatet under onboarding, og ikke opdage det, efter at deres første oplistning er blevet afvist.
• Et kort, konkret eksempel er mere effektivt end alene en skriftlig politik.
• Leverandører, der forstår ræsonneringen, hurtigere søgninger, færre tvister, renere rapportering, har en tendens til at overholde mere villigt end dem, der blot bliver bedt om at følge en regel.

Hvad driver omkostningerne ved at få dette forkert?

At rydde op i SKU-kaos efter faktum koster langt mere end at forhindre det. Et marked med tusindvis af inkonsekvente, duplikerede eller meningsløse SKU'er står over for et reelt datamigrationsprojekt for at rette op på det retroaktivt, omkortlægge produkter, opdatere historiske ordrer og genuddanne leverandører, der allerede har opbygget vaner omkring det beskadigede system.

En no-code markedspladsapp ændrer udgangspunktet betydeligt, da strukturerede SKU-felter og validering af unikke værdier allerede eksisterer som indbyggede funktioner i stedet for at være noget, der bygges fra bunden, efter problemet allerede er synligt.Se hvad der er inkluderet i Shipturtles funktionssætogtjek nuværende priserfor nøjagtige tal.

Fix dette, før det bliver et migrationsprojekt.

En ren SKU-struktur er langt lettere at håndhæve fra dag ét end at tilpasse, når hundredevis af leverandører allerede har bygget deres egne vaner omkring den. Omkostningen ved at få dette rigtigt tidligt er en politisk beslutning. Omkostningen ved at rette det sent er et dataprojekt.

Book en demofor at se, hvordan Shipturtle håndhæver SKU-struktur og forhindrer duplikering på tidspunktet for opstilling. Ellerudforsk hele funktionssættetfor at se, hvad der er indbygget, før du begynder.