Pazaryerlerinde stok eşitleme: aynı ürünü iki kez satmamak

Örnek bir iş senaryosu

Depoda beş adet ürün olduğunu, iki adedin hazırlanmakta olan siparişe ayrıldığını düşünün. Görünür stok beş fakat satılabilir miktar üçtür. İki kanal aynı anda sipariş getirdiğinde rezervasyonun tek merkezde uygulanması gerekir. API güncellemesinin gecikmesi ihtimaline karşı ürün bazında güvenlik payı değerlendirilebilir. Bu pay stok hatasını saklamak için değil, bilinen senkronizasyon gecikmesini yönetmek için kullanılmalıdır.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

Stok eşitlemenin başarısını yalnızca son gönderilen miktarla ölçmeyin. Hedef kanalın kabul ettiği değer ve kabul zamanı da önemlidir. İstek kuyruğunda biriken eski güncellemeler yeni miktarın üstüne yazılmamalıdır. Ürün için sürüm veya güncelleme sırası korunarak en güncel durumun hedefe ulaşması sağlanabilir. Bağlantı yeniden kurulduğunda bütün hareketleri körlemesine tekrar göndermek yerine hangi işlerin tamamlandığını kontrol edin. Kritik ürünlerde fark raporu oluşturup merkez miktar, kanal miktarı ve açık siparişleri yan yana gösterin. Sayım düzeltmesi gibi toplu değişiklikler sırasında kanalların geçici tutarsızlık yaşayabileceği süreyi operasyon ekibi bilmelidir.

Siparişten iadeye bir deneme turu

Test için az sayıda ama farklı özellikte ürün hazırlayın: tek varyant, çok varyant, paket ürün ve stoğu sınırlı ürün. Her ürünü kullanılan kanallarla eşleştirin. Normal siparişin yanında iptal, kısmi gönderi ve iade senaryosu oluşturun. Her adımda merkez kaydı ile kanalın gördüğü durumu karşılaştırın. Dış sistemde sonuç hemen görünmüyorsa bunu hata saymadan önce beklenen senkronizasyon süresini kontrol edin. Ancak gecikmenin süresiz kalmasını da kabul etmeyin; izleme ekranında bekleme ve son deneme bilgisi bulunmalıdır. Test işlemlerinin gerçek müşterilere gönderi veya mesaj üretmemesine dikkat edin.

Depo personeliyle müşteri iletişimi ekibinin aynı sipariş hakkında farklı ayrıntılara ihtiyaç duyduğunu unutmayın. Depo ürün ve lokasyonu, destek ekibi iletişim ve durum geçmişini görmelidir. Her rolün görevini tamamlamak için kaç ekrana geçtiğini inceleyin. Kayıt üzerinde değişiklik yapılırken başka kullanıcı aynı işi yürütüyorsa sistemin çakışmayı nasıl ele aldığını deneyin. Paketleme sırasında iptal gelen sipariş bunun iyi bir örneğidir. Gün sonunda sipariş sayısı, paket sayısı ve stok hareketleri aynı şeyi ölçmez; bu toplamların hangi ilişkiyle uzlaştırılacağı açıklanmalıdır.

Canlı kullanımda kanalın güncel API ve operasyon kuralları esas alınır. Bir entegrasyonun belli bir adı taşıması bütün işlemlerin desteklendiğini göstermez. Ürün, sipariş, stok, iade ve soru akışlarının kapsamını ayrı ayrı teyit edin. Sık karşılaşılan hataları örnek kayıtlarla inceleyin ve sorumluluğu belirleyin. Amaç bütün hata mesajlarını sıfırlamak değil, hiçbir işin sessizce kaybolmamasıdır. Günlük kısa kontrol listesinde en eski bekleyen işlem, eşleşmeyen ürün ve sonuçlanmayan iade gibi iş göstergeleri yer alabilir. Uyarıların ekibin gerçekten müdahale edebileceği konulara odaklanması gerekir.

Ekibinize sorabileceğiniz sorular

• Stok sayısı hangi sistemden doğuyor?
• İptal ve iade farklı işleniyor mu?
• Başarısız güncelleme ne kadar sürede fark ediliyor?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.