Çoklu Satıcı Pazarları için SKU Yönetimi: Pratik Bir Rehber

E-ticaret sektöründe birkaç aydan fazla çalışmış olan herkes bir SKU problemiyle karşılaşmıştır. Aynı koda sahip iki ürün. Altı ay sonra hiçbir anlamı kalmamış bir kod. Hangi SKU'nun gerçekten gönderildiğini kimsenin söyleyemediği bir destek bileti, çözmesi yirmi dakikanızı alıyor.

Tek markalı bir mağazada bu sinir bozucu. Çoklu satıcı pazarında, her biri kendi ürün verilerini oluşturan onlarca veya yüzlerce satıcının bulunduğu bir ortamda, bu, her yeni satıcının katılmasıyla artan yapısal bir risk haline gelir.

SKU ve UPC: Gerçek sorunlara neden olan karışıklıklar

Bu iki terim birbirinin yerine kullanılıyor ve bu gerçek bir hata, sadece bir teknik detay değil.

Bir SKU, stok tutma birimi, işletmenizin belirli bir ürün varyantını izlemek için oluşturduğu dahili bir koddur; sizin ve tedarikçileriniz için anlamlı, pazarınızın dışındaki kimse için değil. Bir UPC, evrensel ürün kodu, bir ürünün tanınabilmesi için herhangi bir perakendeci veya tarama yapan sistem tarafından tanınabilmesi amacıyla atanan harici, standart bir barkoddur.

Pratik fark burada özellikle önemlidir: bir pazar yeri, kendi SKU yapısını tamamen kontrol edebilir ve etmelidir, çünkü bu dahili bir yapıdır. UPC, icat ettiğiniz bir şey değildir, bu bir numaradır ve gerçek ürün üzerinde basılanla tutarlı kalmalıdır. Bunları aynı şey gibi ele almak, doğrudan tekrar eden listelemelere, bozuk envanter senkronizasyonuna ve orijinal siparişle eşleştirilemeyen iadelerle sonuçlanır.

Marketplaces present unique challenges for SKU (Stock Keeping Unit) management due to several factors: 1. **Diverse Seller Base**: Marketplaces host a variety of sellers, each with their own inventory practices and SKU systems. This diversity can lead to inconsistencies in how SKUs are defined, managed, and utilized. 2. **Inventory Synchronization**: With multiple sellers offering similar products, keeping inventory synchronized can be difficult. If one seller sells out, it may not reflect immediately across the marketplace, leading to overselling or stockouts. 3. **Complex Pricing Structures**: Sellers may have different pricing strategies, promotions, and discounts for the same SKU. This complexity requires effective tracking and management to ensure consistency and competitiveness. 4. **Data Quality Issues**: In a marketplace, SKU data quality can vary widely. Poorly maintained SKU data from sellers can lead to issues such as misrepresentation of products, incorrect availability statuses, and customer confusion. 5. **Product Variations**: SKUs may represent variants of products (like size, color, etc.), and managing these variations across different sellers can be challenging, especially when consolidating data for search and display. 6. **Regulatory Compliance**: Depending on the market and product type, there may be specific regulatory requirements that need to be met in relation to product labeling and SKU information, complicating management further. 7. **Dynamic Marketplace Environment**: Marketplaces often experience rapid changes in demand, trends, and consumer preferences. This dynamic nature requires agile SKU management to quickly adapt to changing conditions. Managing SKUs effectively in a marketplace requires comprehensive strategies to address these challenges, including investing in technology for inventory management, data analytics for pricing strategies, and robust communication channels with sellers.

Tek marka mağazası yalnızca kendi SKU sistemini uygulamak zorundadır. Ürün verisi girmeye giren herkes aynı işletme için çalışır, yazılı ya da yazılı olmayan aynı kurallar altında.

Bir pazar yeri bunu tersine çeviriyor. Her satıcı kendi alışkanlıkları, kendi elektronik tabloları ve bazen de başka bir yerde zaten işletmekte oldukları mağazadan kendi mevcut SKU sistemleri ile geliyor. Onboarding sırasında paylaşılan bir yapı dayatılmadığında, sahip olduğunuz satıcı sayısı kadar farklı SKU mantığı ortaya çıkar ve bunlar arasında güvenilir bir şekilde arama, raporlama veya uyuşma sağlamak mümkün olmaz.

Bu, SKU yönetiminin bir pazar yerinde kendi özel planına sahip olmasının gerekliliğini tam olarak açıklıyor; bunun yerine, satıcıların sadece halledeceği varsayılan bir detay olarak bırakılmamalıdır.

İyi bir SKU yapısı aslında nasıl görünür?

Her tedarikçiye uygulanan tutarlı bir adlandırma yöntemi.

Çalışabilir bir yapı genellikle kodun içine tedarikçi, kategori ve varyantı dahil eder, şöyle bir şey gibi:SATIŞ-KATEGORİ-RENK-BEDENTam formatın önemi, her tedarikçinin aynı biçimi takip etmesidir.

Eşsizlik, platform düzeyinde zorunlu kılınmıştır, güvene bırakılmamıştır.

Pazar yeri, bir SKU'nun zaten kullanıldığını reddetmeli, bunun yerine satıcıların bir ürünü listelemeden önce çakışmalar için kendilerinin kontrol etmeye güvenmemelidir.

Yeniden başlamadan ölçeklenme imkanı.

10 satıcı ve 200 ürün için oluşturulmuş bir adlandırma kuralı, 100 satıcı ve 20.000 ürün ile de mantıklı olmalı, yarıda tam bir yeniden adlandırma projesine ihtiyaç duyulmamalıdır.

SKU ve herhangi bir dış kod arasında belirgin bir ayrım.

UPC'ler, barkodlar ve üretici parça numaraları bir SKU ile birlikte saklanabilir, ancak SKU'nun kendisi olarak kullanılmamalıdır çünkü her zaman mevcut değillerdir, her bağlamda her zaman benzersiz değildirler ve pazar yerinin kontrolü altındadırlar.

Bunu nasıl gerçekten onarıp sürdüreceğiniz: adım adım

1. İlk tedarikçinizi entegre etmeden önce SKU formatınızı tanımlayın.

• SKU'ya neyin kodlanacağına karar verin: tedarikçi kimliği, kategori ve varyant en yaygın olanlardır.
• Satıcıların tahmin etmeden takip edebileceği kısa ve basit bir kural yazın.
• Bunu her satıcının kendi yorumlayabileceği bir öneri değil, platform genelinde bir politika olarak değerlendirin.

2. Onboarding ve listeleme sürecine benzersizlik kontrolleri ekleyin.

• Shipturtle'ın ürün yapılandırmasıduyuru öncesinde bir listeye eklenmeden önce bir tekrar eden SKU'yu tespit etmek için gerekli olan yapılandırılmış alanları ve doğrulamayı destekler.
• Platformda zaten mevcut olan bir SKU'yu yalnızca işaretlemek yerine reddedin.
• Bunu otomatik hale getirin, unutmaması gereken bir manuel inceleme adımı olmasın.

3. Mevcut tedarikçileri yeni yapıya bilerek taşımak

• Kendi SKU sistemine sahip olan satıcılar, belirgin bir neden ve basit bir yol olmadan gönüllü olarak geçiş yapmayacaklar.
• Toplu yeniden eşleme aracını veya kısa bir geçiş süresini sunun, ürün bazında manuel tekrar giriş beklemek yerine.
• Değişikliği uygulamadan önce iletin, satıcılar eski SKU'larının artık çalışmadığını keşfetmeden önce.

4. SKU alanlarını UPC ve barkod alanlarından açıkça ayırın.

• Satıcılara SKU alanından ayrı, UPC veya üretici kodu için belirgin bir alan verin.
• Barkod taraması ve ürün tanıma için UPC'yi, iç takip ve raporlama için ise SKU'yu kullanın.
• Bu iki alanı birbirinin yerine koyan herhangi bir listeleme akışından kaçının, çünkü karışıklığın başladığı yer tam olarak burasıdır.

5. Düzenli bir programda yinelenmeleri ve tutarsızlıkları denetleyin.

• Tek seferlik bir temizlik kalıcı olmaz çünkü sürekli yeni satıcılar ve yeni ürünler ekleniyor.
• Aylık olarak, çoğu pazar yeri için makul bir süre olan, kaymaların gerçek bir destek yüküne dönüşmeden önce yakalanması için tekrarlayan bir kontrol ayarlayın.
• Artan SKU ile ilgili destek biletlerini, yalnızca kapatılması gereken bireysel biletler olarak değil, mevcut yapının gözden geçirilmesi gerektiğini gösteren erken bir sinyal olarak değerlendirin.

6. SKU kalitesini satıcıya onboarding eğitimine bağlayın.

• Yeni satıcılar, ilk listelemeleri reddedildikten sonra değil, onboarding sırasında SKU format gereksinimini görmelidir.
• Kısa, somut bir örnek, yazılı bir politika ile karşılaştırıldığında daha etkilidir.
• Kurallara uyması istenen, ancak nedenini anlamayan satıcılar, daha hızlı arama, daha az tartışma ve daha temiz raporlama sağlayanları anlamaya daha istekli olma eğilimindedir.

Bunu yanlış yapmanın maliyetini ne driver?

Sonrasında SKU karmaşasını temizlemek, önlemekten çok daha pahalıdır. Binlerce tutarsız, yinelenen veya anlamsız SKU'ya sahip bir pazar, ürünleri yeniden eşleştirmek, geçmiş siparişleri güncellemek ve zaten bozuk sisteme alışkanlık geliştirmiş tedarikçileri yeniden eğitmek için gerçekten bir veri taşıma projesi ile karşı karşıya kalır.

No-code bir pazar yeri uygulaması, yapılandırılmış SKU alanları ve benzersizlik doğrulaması zaten yerleşik özellikler olarak mevcut olduğundan, başlangıç noktasını önemli ölçüde değiştirir; bu, sorun görünür hale geldikten sonra sıfırdan oluşturulan bir şey değildir.Shipturtle'ın özellik setinde nelerin bulunduğunu görünvemevcut fiyatlandırmayı kontrol ettam sayılar için.

Bunu, bir göç projesi haline gelmeden önce düzeltin.

Temiz SKU yapısını, yüzlerce satıcının bu yapıya kendi alışkanlıklarını oluşturmaya başlamasından önce, ilk günden uygulamak çok daha kolaydır. Bunu erken bir biçimde doğru yapmanın maliyeti bir politika kararını gerektirir. Bunu geç yaptığınızda, maliyet bir veri projesine dönüşür.

Bir demo rezervasyonu yapın.Shipturtle'ün SKU yapısını nasıl uyguladığını ve listeleme sırasında tekrarları nasıl engellediğini görmek için. Ya datam özellik setini keşfedinbaşlamadan önce neyin yerleşik olduğunu görmek için.