SKU-hantering för flermarknadsplatser: En praktisk guide

Alla som har arbetat inom e-handel i mer än några månader har stött på ett SKU-problem. Två produkter med samma kod. En kod som betyder ingenting sex månader senare. En supportbiljett som tar tjugo minuter att lösa eftersom ingen kan avgöra vilken SKU som faktiskt skickades.

På en en-märkesbutik är detta irriterande. På en marknadsplats med flera säljare, där dussintals eller hundratals säljare var och en skapar sina egna produktdata, är det en strukturell risk som växer med varje ny säljare som ansluter sig.

SKU vs. UPC: förvirringen som orsakar verkliga problem

Dessa två termer används omväxlande, och det är ett äkta misstag, inte bara en teknikalitet.

En SKU, lagersaldokod, är en intern kod som ditt företag skapar för att spåra en specifik produktvariant, ett eget system som är meningsfullt för dig och dina leverantörer, men inte för någon utanför din marknad. En UPC, universell produktkod, är en extern, standardiserad streckkod som tilldelas en produkt så att den kan kännas igen av alla återförsäljare eller system som skannar den.

Den praktiska skillnaden är speciellt viktig här: en marknadsplats kan och bör kontrollera sin egen SKU-struktur helt och hållet, eftersom den är intern. En UPC är inte något du hittar på, den utfärdas och måste förbli konsekvent med vad som står på den faktiska produkten. Att behandla dessa som samma sak leder direkt till dubbla listningar, trasig inventariesynkronisering och returer som inte kan matchas tillbaka till den ursprungliga beställningen.

Varför är SKU-hantering ett annorlunda problem på en marknadsplats?

En butik som säljer ett enda märke behöver bara upprätthålla ett SKU-system, sitt eget. Alla som matar in produktdata arbetar för samma företag, under samma regler, oavsett om dessa regler är dokumenterade eller inte.

En marknadsplats vänder på detta. Varje leverantör anländer med sina egna vanor, sina egna kalkylblad, ibland sitt eget befintliga SKU-system från en butik de redan driver någon annanstans. Utan en gemensam struktur som påtvingas vid onboarding, får du lika många olika SKU-logiker som du har leverantörer, och inget pålitligt sätt att söka, rapportera eller sammanställas över dem.

Detta är precis varför SKU-hantering förtjänar sin egen genomtänkta plan på en marknadsplats, snarare än att lämnas som en antagen detalj som säljare bara kommer att lista ut.

Vad en bra SKU-struktur faktiskt ser ut som

En konsekvent namngivningskonvention, tillämpad på varje leverantör.

En fungerande struktur kodar vanligtvis in leverantör, kategori och variant i koden själv, något i stil medVISA-KATEGORI-FÄRG-STORLEKDet exakta formatet spelar mindre roll än att varje leverantör följer samma.

Unikhet upprättas på plattformsnivå, inte överlämnat till förtroende.

Marknadsplatsen bör själv avvisa en SKU som redan används, istället för att lita på att leverantörerna kontrollerar för konflikter själva innan de listar en produkt.

Utrymme för att växa utan att börja om.

En namngivningskonvention som är utformad för 10 leverantörer och 200 produkter bör fortfarande ge mening vid 100 leverantörer och 20 000 produkter, utan att behöva ett helt omdöpningsprojekt mitt under processen.

En tydlig åtskillnad mellan SKU och eventuell extern kod.

UPCs, streckkoder och tillverkarens artikelnummer kan alla lagras tillsammans med en SKU, men de bör inte användas som SKU i sig, eftersom de inte alltid är tillgängliga, inte alltid unika över olika kontexter och inte står under marknadsplatsens kontroll.

Hur man faktiskt fixar och underhåller detta: steg för steg

1. Definiera ditt SKU-format innan du onboardar din första leverantör.

• Besluta vad som ska kodas in i SKU: leverantörsidentifierare, kategori och variant är de vanligaste.
• Skriv ner formatet som en kort, enkel regel som leverantörer kan följa utan att gissa.
• Betrakta detta som en plattformsövergripande policy, inte som en rekommendation som varje leverantör kan tolka på sitt eget sätt.

2. Bygg in unika kontroller i onboarding- och listningsflödet

• Shipturtle's produktkonfigurationstödjer de strukturerade fälten och validering som behövs för att fånga en duplikat SKU innan en listing går live
• Neka, istället för att bara flagga, en SKU som redan finns på plattformen.
• Gör detta automatiskt, inte ett manuellt granskningsteg som någon måste komma ihåg att köra.

3. Migrera befintliga leverantörer till den nya strukturen medvetet

• Leverantörer som redan har sitt eget SKU-system kommer inte att byta frivilligt utan ett tydligt skäl och en enkel väg för att göra det.
• Erbjud ett verktyg för massremappning eller ett kort migrationsfönster, istället för att förvänta dig manuell ommatning produkt för produkt.
• Kommunicera förändringen innan den genomförs, inte efter att leverantörerna upptäcker att deras gamla SKU:er inte längre fungerar.

4. Separera SKU-fält från UPC- och streckkodsfält explicit.

• Ge leverantörer ett distinkt fält för UPC eller tillverkarens kod, åtskilt från SKU-fältet självt.
• Använd UPC för streckkodsskanning och produktigenkänning, och SKU för intern spårning och rapportering.
• Undvik alla listflöden som behandlar dessa två fält som utbytbara, eftersom det är precis där förvirringen börjar.

5. Granska för dubbletter och inkonsekvenser enligt en regelbunden schema

• En engångsrengöring förblir inte ren eftersom nya leverantörer och nya produkter kontinuerligt läggs till.
• Ställ in en återkommande kontroll, månadsvis är rimligt för de flesta marknadsplatser, för att fånga upp avvikelser innan de blir en verklig supportbörda.
• Betrakta ett ökande antal supportärenden relaterade till SKU som en tidig signal på att den nuvarande strukturen behöver ses över, inte bara individuella ärenden som ska stängas.

6. Koppla SKU-kvalitet till leverantörens onboardingutbildning

• Nya leverantörer bör se kravet på SKU-formatet under introduktionen, istället för att upptäcka det efter att deras första upplistning har blivit avvisad.
• Ett kort, konkret exempel är mer effektivt än enbart en skriven policy.
• Leverantörer som förstår resonemanget, snabbare sökningar, färre tvister, renare rapportering, tenderar att följa regler mer villigt än de som bara blir tillsagda att följa en regel.

Vad driver kostnaden för att göra detta fel?

Att städa upp SKU-kaos i efterhand kostar mycket mer än att förebygga det. En marknadsplats med tusentals inkonsekventa, duplicerade eller meningslösa SKU:er står inför ett verkligt datamigreringsprojekt för att åtgärda detta retroaktivt, omkartlägga produkter, uppdatera historiska beställningar och omutbilda leverantörer som redan har byggt vanor kring det trasiga systemet.

En no-code marknadsplatsapp förändrar startpunkten avsevärt, eftersom strukturerade SKU-fält och validering av unikhet redan finns som inbyggda funktioner snarare än något som byggs från grunden efter att problemet redan är synligt.Se vad som ingår i Shipturtles funktionsuppsättning.ochkontrollera aktuella priserför exakta siffror.

Åtgärda detta innan det blir ett migrationsprojekt.

En ren SKU-struktur är mycket lättare att genomföra från dag ett än att åtgärda när hundratals leverantörer redan har skapat sina egna vanor kring den. Kostnaden för att få detta rätt i ett tidigt skede är en policysatsning. Kostnaden för att åtgärda det sent är ett dataprojekt.

Boka en demoatt se hur Shipturtle upprätthåller SKU-strukturen och förhindrar duplicering vid listningstillfället. Ellerutforska hela funktionsuppsättningenför att se vad som är inbyggt innan du börjar.