Çok kanallı satışta temel problem nedir?
Temel problem aynı stoğun birden çok yerde satılmasıdır. Kendi siteniz, pazaryerleri ve fiziksel mağaza aynı depodan besleniyorsa, iki kanalda eşzamanlı gelen sipariş elinizde olmayan ürünü satabilir. Aşırı satış yalnızca bir iptal maliyeti değildir; pazaryerlerinde satıcı performans puanını da düşürür.
Aşırı satışı önleyen üç yaklaşım
- Kanal bazlı tahsis: stoğun bir kısmı her kanala ayrılır. Uygulaması en basit yöntemdir; dezavantajı, bir kanalda kullanılmayan stoğun diğerine geçememesidir.
- Güvenlik payı (buffer): merkezi stoktan sabit bir miktar düşülerek yayınlanır. Hızlı devreye alınır ancak düşük stoklu ürünlerde satış kaybı yaratır.
- Merkezi rezervasyon: sipariş anında merkezi stok üzerinde rezervasyon oluşturulur. En doğru sonucu verir; entegrasyonun gerçek zamanlıya yakın çalışmasını gerektirir.
Uygulamada yaygın çözüm, hızlı devreden ürünlerde rezervasyon, yavaş devreden ürünlerde güvenlik payı kullanmaktır.
Senkronizasyon gecikmesini kabul edin, gizlemeyin
Hiçbir entegrasyon anlık değildir. Doğru yaklaşım, gecikmeyi sıfırlamaya çalışmak yerine ölçmek ve sınırlamaktır: stok güncellemesinin ortalama ve en kötü durum gecikmesi izlenmeli, eşiği aşınca uyarı üretilmelidir. Ayrıca stok azaldıkça güncelleme sıklığı artırılmalıdır; 500 adetlik üründe on dakikalık gecikme sorun değildir, 3 adetlik üründe sorundur.
Sipariş → fatura akışı
Sipariş alındıktan sonraki zincir; stok rezervasyonu, ödeme doğrulaması, sevkiyat ve faturalandırma adımlarından oluşur. Faturalandırma tarafında e-belge yükümlülükleri devreye girer ve fatura numarası ile sipariş numarasının eşleştirilmesi, iade ve mutabakat için zorunludur. Pazaryeri siparişlerinde fatura kesme sorumluluğunun kimde olduğu kanal sözleşmesine göre değişir; bu, veri modelinde kanal bazlı bir ayar olmalıdır.
Aktarımların tekrar edildiğinde çift sipariş üretmemesi için işlem anahtarı kullanılır; ayrıntı için API entegrasyonu rehberi.
İade süreci veri modelinin parçasıdır
İade, siparişin silinmesi değildir; kendi yaşam döngüsü olan ayrı bir kayıttır: talep edildi → onaylandı → kargo alındı → incelendi → kabul/ret → bedel iadesi. Kısmi iade, kalem bazında modellenmelidir. Ayrıca iade edilen ürünün stoğa geri dönüp dönmeyeceği (hasarlı, açılmış, satılamaz) bir durum alanıyla ayrılmalıdır. Bu ayrım yoksa stok doğruluğu iadelerle birlikte bozulur.
Pazaryeri farklarını tek modelde eritmeyin
Her pazaryerinin kendi kategori ağacı, zorunlu özellik seti, komisyon yapısı ve kargo kuralı vardır. Ürün verisini tek bir "başlık + açıklama" alanına indirgemek, kanal bazlı zorunlulukları karşılayamaz. Doğru yapı, merkezde zengin bir ürün veri modeli tutup her kanal için eşleme (mapping) tanımlamaktır.
Sık sorulan sorular
Stok merkezi ERP'de mi tutulmalı?
Evet. Tek doğruluk kaynağı ERP olmalı, kanallar ondan beslenmelidir. Kanalların kendi stok sayaçlarını bağımsız yönetmesi, mutabakatı imkânsız hâle getirir.
Fiyat farklılaştırması nasıl yönetilir?
Kanal bazlı fiyat listeleri ve komisyon dâhil hesaplama tek bir yerde yapılmalıdır. Pazaryeri komisyonu ve kargo maliyeti kanal kârlılığını değiştirdiği için, aynı ürün farklı kanallarda farklı fiyatlanabilir; bu bilinçli bir karar olmalı, elle güncellemenin yan etkisi değil.
Mağaza stoğu online satışa açılmalı mı?
Açılabilir ancak mağaza sayımının güvenilirliği ön koşuldur. Sayım doğruluğu düşükken mağaza stoğunu yayına açmak, aşırı satışın en sık nedenidir. Mağaza tarafındaki stok doğruluğu konusunu perakende POS rehberinde ele alıyoruz.