Stoksuz satışın satıcı puanına ve Buy Box'a maliyeti, webhook ile periyodik sorgunun birlikte kullanımı, tampon stok stratejisi ve kanal başına farklı fiyat gerekliliği.
Aynı ürünü üç kanalda satarken elle stok güncellemek matematiksel olarak sürdürülemez. Bu yazıda stoksuz satışın gerçek maliyetini, senkronizasyon mimarisinin nasıl kurulduğunu, tampon stok stratejisini ve kanal başına farklı fiyat gerektiren durumları anlatıyoruz.
Çok kanallı satışta en pahalı hata, kâr marjını yanlış hesaplamak değil — elinizde olmayan bir ürünü satmak. Stoksuz satış (overselling) tek bir siparişi iptal ettirmekle kalmıyor, satıcı puanınızı düşürüyor, Buy Box'tan çıkmanıza yol açıyor ve toparlanması haftalar süren bir zincir başlatıyor.
Stoksuz satışın gerçek maliyeti
Elinizde 3 adet kalan bir ürünü Trendyol, Hepsiburada ve kendi sitenizde aynı anda satıyorsunuz. Üç kanaldan aynı gün ikişer sipariş gelirse, üçünü karşılayıp üçünü iptal etmek zorunda kalırsınız. Sonuçlar:
- Tedarik edememe puanı. Trendyol'da bu kriter satıcı puanının doğrudan bileşeni ve ağırlığın büyük kısmı son 30 güne bakıyor — mağaza yönetimi yazımızda ayrıntılı anlattık.
- Buy Box kaybı. Hepsiburada'da stok kesintisi listelemeyi düşürüyor; geri kazanmak zaman alıyor.
- Müşteri şikayeti. İptal edilen sipariş genelde olumsuz değerlendirmeye dönüşüyor.
- Reklam israfı. O ürüne reklam veriyorsanız, satamadığınız stok için tıklama parası ödemiş oluyorsunuz.
Yani tek bir stok hatası, dört farklı yerden maliyet yazıyor. Bu yüzden senkronizasyon bir "verimlilik" konusu değil, doğrudan ciro koruma konusu.
Elle yönetmek neden çalışmıyor
Kanal sayısı arttıkça güncelleme yükü çarpan etkisiyle büyüyor. 500 ürünü 3 kanalda satıyorsanız, günde bir güncelleme bile 1.500 işlem demek. Gerçekte ise güncellemenin sipariş anında yapılması gerekiyor, günde bir değil.
Pratik eşik şu: iki kanalı ve birkaç düzine ürünü elle yönetmek mümkün; üçüncü kanal ya da birkaç yüz ürün eklendiğinde otomasyon zorunlu hale geliyor.
Senkronizasyon mimarisi
Tek doğruluk kaynağı
İlk kural: stoğun tek bir yerde tutulması. Bu genelde ERP ya da stok yönetim sistemi oluyor; kanallar bu kaynaktan besleniyor. Kanalların birbirini güncellemeye çalıştığı kurgular çakışma üretiyor ve hangi rakamın doğru olduğu belirsizleşiyor.
Webhook mu, periyodik sorgu mu
| Webhook (olay tabanlı) | Polling (periyodik sorgu) | |
|---|---|---|
| Gecikme | Saniyeler | Sorgu aralığı kadar (5–30 dk) |
| Sistem yükü | Düşük — yalnızca değişimde çalışır | Yüksek — değişim olmasa da sorgular |
| Kurulum | Kanalın desteklemesi gerekir | Her API ile çalışır |
| Kaçırma riski | Bildirim düşerse kaçar | Bir sonraki turda yakalar |
Doğru kurgu ikisinin birlikte kullanılması: webhook ile anlık güncelleme, güvenlik ağı olarak da düzenli aralıklarla tam mutabakat. Yalnızca webhook'a güvenen sistemler, tek bir düşen bildirimde sessizce yanlış stokla çalışmaya devam ediyor.
Tampon stok
Senkronizasyon ne kadar hızlı olursa olsun, iki kanaldan aynı saniyede gelen sipariş ihtimali sıfırlanmıyor. Bunun çözümü teknik değil ticari: kanal başına 1–2 adetlik tampon bırakmak.
Hızlı dönen ürünlerde tamponu artırmak, yavaş dönenlerde sıfıra yaklaştırmak mantıklı. Tampon, satılmayan stok anlamına geldiği için maliyetli; ama bir iptalin puan üzerindeki maliyetinden genelde daha ucuz.
Fiyat senkronizasyonu: aynı fiyat her kanalda doğru değil
Stok her kanalda aynı olmalı; fiyat olmamalı. Sebebi basit: kesinti yapıları farklı. Hepsiburada'nın sipariş başına sabit işlem bedeli, Amazon'un stopajı ve hesap bedeli, Trendyol'un kargo baremleri aynı ürünün her kanaldaki gerçek marjını değiştiriyor. Ayrıntılı karşılaştırmayı komisyon ve kâr marjı yazımızda bulabilirsiniz.
Doğru kurgu, kanal başına hedef marjdan türetilen fiyat: aynı ürün için tek bir maliyet tabanı tutulur, her kanalın efektif kesinti oranı uygulanır, fiyat oradan hesaplanır. Bunu elle yapmak pratikte imkânsız olduğu için fiyat kuralları da senkronizasyon katmanına taşınmalı.
Hazır entegrasyon mu, özel geliştirme mi
Hazır entegrasyon paketleri standart senaryoları hızlı çözüyor: temel stok, fiyat ve sipariş aktarımı. Özel geliştirme ise şu durumlarda gerekiyor:
- Kendi ERP'niz ya da özel bir stok sisteminiz varsa
- Varyant, set ya da paket ürün mantığınız standart dışıysa
- Kanal başına farklı fiyat kuralları ve kampanya mantığı işletiyorsanız
- Depo, üretim ya da tedarikçi tarafıyla iki yönlü akış gerekiyorsa
Karar için genel çerçeveyi hazır paket mi özel yazılım mı yazımızda ele aldık.
Kurulum kontrol listesi
- Stoğun tek doğruluk kaynağını belirleyin ve yazılı hale getirin.
- Her kanal için güncelleme yönünü netleştirin (tek yön mü, çift yön mü).
- Webhook desteğini kontrol edin; desteklenmeyen kanallarda sorgu aralığını belirleyin.
- Düzenli tam mutabakat işini kurun (günde en az bir kez).
- Ürün grubu bazında tampon stok kuralını tanımlayın.
- Kanal başına fiyat kuralını hedef marjdan türetin.
- Senkronizasyon hatası için alarm kurun — sessiz başarısızlık en tehlikelisidir.
Sık yapılan hatalar
- Yalnızca webhook'a güvenmek. Düşen tek bir bildirim, fark edilmeden günlerce yanlış stok demektir.
- Tampon stok bırakmamak. Eşzamanlı sipariş ihtimali hiçbir zaman sıfır değildir.
- Fiyatı tüm kanallarda eşitlemek. Kesinti yapıları farklıyken aynı fiyat, bazı kanallarda zarar demektir.
- Alarm kurmamak. Entegrasyon sessizce durduğunda bunu genelde iptal edilen siparişten öğrenirsiniz.
- Varyantlı ürünleri tekil ürün gibi eşlemek. Beden/renk kırılımı yanlış eşlenirse yanlış varyant satılır.
Sonuç
Çok kanallı satışta stok senkronizasyonu bir altyapı konusu gibi görünse de doğrudan satıcı puanınızı, Buy Box konumunuzu ve reklam verimliliğinizi belirliyor. Doğru kurulmuş bir senkronizasyon katmanı, üçüncü kanalı açmayı bir risk olmaktan çıkarıp büyüme kaldıracına dönüştürüyor.
Commerslab olarak pazaryeri, e-ticaret sitesi ve ERP arasındaki stok–fiyat–sipariş akışını kendi entegrasyonlarımızla kuruyoruz. Sistem entegrasyonları hizmetimizi inceleyin veya mevcut kurgunuz için bize yazın.
