Multi-Channel Envanter Sapması: 5 Sebebi, 3 Çözümü

Çoklu kanalda satış yapan her satıcı eninde sonunda bu cümleyi kurar: “Stoğum tükendi ama sistemde 12 adet daha gözüküyor — Amazon listing’i hâlâ canlı.” Bir hafta sonra: “Aynı SKU’dan Amazon’da 3, Shopify’da 1 sipariş geldi ama elimde sadece 2 ürün var.” Ardından oversell — iki müşteriye iade, hesap puanına darbe, Amazon’da Buy Box kaybı.

Bu yazıda 5 yıllık fulfillment operasyonundan çıkardığımız sapma sebeplerini ve uygulanabilir 3 mimari çözümü paylaşıyoruz. Pazarlama broşürü yok, sahadan deneyim.

Sapma neden oluşur?

Sebep 1: “Last sync wins” anti-pattern’i

Birçok ERP/inventory tool şöyle çalışır: her kanaldan stok seviyesini periyodik (örn. saatte bir) çeker, en son geleni “doğru” kabul eder. Bu felaket:

Amazon FBA seviyesi 23, son güncelleme 14:00
Shopify seviyesi 21, son güncelleme 14:01
Sistem “Shopify doğru” der, Amazon’a 21 push eder
Aslında Amazon FBA’da 23 vardı (Amazon’un fulfillment merkezleri ayrı sayar)

Sonuç: Amazon’da 21 olarak görünür, ama Amazon depolarında 23 kullanılabilir → 2 satış kaybı (Buy Box etkisi). Tersi durumda oversell.

Sebep 2: FBA reserved inventory görünmüyor

Amazon FBA’da “available” ve “reserved” diye iki ayrı sayım vardır. Reserved:

Aktif siparişler için ayrılmış stok
Ürünlerin lokasyonlar arası transferinde olanlar
Hasarlı ürün incelemesi bekleyen
Prep center’da olan

Naif inventory tool’lar sadece “available” üzerinden hesaplar. Müşteri bir Amazon order verir, 10 dakika sonra Shopify’da aynı ürünü ararken stok hâlâ “var” görünür → ikinci sipariş alınır → oversell.

Sebep 3: Multi-warehouse split inventory

Çoklu lokasyonla satıyorsanız (Amazon FBA East + West + 3PL warehouse), her lokasyon ayrı sayar. Tool’lar bunu toplam olarak gösterir ama:

Amazon East: 10 adet
Amazon West: 5 adet
3PL: 8 adet
Toplam: 23

Müşteri Shopify’da NYC’den sipariş verir → 3PL’den çıkar (8 adet azalır). Tool toplamı 22’ye düşürür ama:

3PL’den daha fazla sipariş gelirse stok yetmez (oversell)
Amazon East/West’teki 15 adet erişilemez (NYC dışı için maliyet)

Doğru envanter modeli lokasyon bazlı olmalı, salt toplam değil.

Sebep 4: Webhook ≠ gerçek zamanlı

“Real-time webhook” bir efsanedir. Webhook’lar:

Saniyeler sonra düşer (network latency)
Ara sıra düşmez (Amazon’un %0.3 webhook drop oranı)
Sıralı gelmeyebilir (order #2 önce, order #1 sonra)

Eğer envanter güncellemenizi sadece webhook’a bağlıysanız, drop olan event tüm hesabı bozar. Mutlaka periyodik reconciliation (saatte 1 veya 4 saatte 1) gerekir.

Sebep 5: Refund/cancel’larda iade hattı yok

Müşteri sipariş verir, hemen iptal eder. Order canceled. Ama:

Amazon: stok otomatik geri eklenir
Shopify: stok otomatik geri eklenir
Tool: cancel event’i izlemediği için stoğu tekrar düşürmemiş olabilir
Sonuç: gerçek 23, sistem 22 — 1 satış kaybı

Bu sapma çok küçük gözükür ama birikir. 100 cancel/ay × 12 ay = 1200 sapma → ay sonu envanter sayımında “kayıp” gibi görünen ama aslında satılmamış ürünler.

3 mimari çözüm

Çözüm 1: Source of Truth (SoT) seç ve disiplinle uygula

Hangi sistem gerçek envanter sayısını tutar? Üç seçenek var:

Amazon FBA-first — FBA available + reserved tek toplam, diğer kanallar buna bağlanır. Sadece FBA satıyorsanız OK.
3PL/WMS-first — Her şey 3PL sayar, FBA sadece bir alıcı. Multi-channel için doğru model.
ERP-first — NetSuite/Cin7 vb. tek source. Büyük operasyonlar için.

Bizim önerimiz: 3PL/WMS-first (1.000+ SKU, multi-channel, $1M+ ciro için). FBA inbound shipment yapıldıktan sonra “Amazon allocation” başka bir sayım — ana envanter 3PL’de.

Çözüm 2: Lokasyon-aware stok modeli

Envanter veri yapınız böyle olmalı:

type StockLevel = {
  sku: string;
  location: "AMZ-FBA-EAST" | "AMZ-FBA-WEST" | "3PL-NYC" | "3PL-LA";
  available: number;
  reserved: number;
  inbound: number;
  lastSync: Date;
};

Toplam hesaplanmış bir alan, kaynak değil. Bir kanaldan satış geldiğinde:

Hangi lokasyondan fulfill edileceğini belirle (allocation rule)
O lokasyonun available -= 1, reserved += 1
Order shipped olduğunda reserved -= 1
Order canceled olduğunda reserved -= 1, available += 1

Bu disiplinle 5. sebeptaki sapma sıfırlanır.

Çözüm 3: Hibrit sync — webhook + reconciliation

Tek başına webhook yetmez. Tek başına periyodik sync yavaş. Hibrit:

Real-time webhook — order/refund/cancel event’leri ≤ 30sn
Periyodik reconciliation — saatte 1, lokasyon başına FBA API ve 3PL API’den tam sayım çek
Drift alert — webhook ve reconciliation farkı >%2 ise Slack #ops alert

Bu yapıda webhook drop’u 1 saat sonra otomatik yakalanır. Daha kritik kalemler için 15dk reconciliation yapabilirsiniz.

Çözüm matrisi

Operasyon büyüklüğü	Önerilen mimari	Tool önerisi
<500 SKU, tek kanal	Amazon FBA-first	Amazon dashboard yeterli
500-2.000 SKU, 2 kanal	3PL-first hibrit	tsmartb2b (yakında envanter modülü)
2.000+ SKU, çoklu kanal	ERP-first	NetSuite + custom middleware

Saha hikayesi: 18 günde 0’a inen oversell

Bir müşterimizde (1.200 SKU, Amazon US + Shopify + Trendyol) ayda 47 oversell vardı. Yaptığımız:

Hafta 1: 3PL’i tek SoT olarak sabitledik. FBA inbound shipment gönderirken bunu “tahsis” olarak işaretledik, asıl sayım 3PL’de kaldı.

Hafta 2: Lokasyon-aware veri modelini kurduk. Allocation rule: NYC’den sipariş 3PL-NYC’den, LA’dan sipariş Amazon FBA-West’ten.

Hafta 3: Webhook + 15dk reconciliation hibrit’i devreye aldık. İlk 3 günde 4 webhook drop yakalandı (otomatik retry’la kapandı).

Sonuç: Ayın sonunda oversell 47’den 3’e düştü. 3’ü de “müşteri çift sekme açmıştı, art arda iki sipariş verdi” gibi mimari değil kullanıcı davranışı kaynaklıydı.

tsmartb2b’nin yaklaşımı

tsmartb2b Sprint 5+‘da envanter modülünü ekliyor (şu an QB + Amazon sync canlı). Mimari prensip aynı: lokasyon-aware, hibrit sync, drift alert. Erken kullanıcı olmak isteyen pricing’i görebilir veya strateji görüşmesi talep edebilir.

KolayAmazon hizmet tarafında ise multi-warehouse setup’ı kurulum aşamasında size hazırlıyoruz — 3PL anlaşması + lokasyon haritası + ilk allocation rule’lar 45 günlük plan içinde.

Özet

Sapmanın ana sebebi veri modeli yetersizliği, tool eksikliği değil. Tool’unuz lokasyon-aware ise, hibrit sync yapıyorsa, refund/cancel event’lerini hesaplıyorsa — sapma 0’a yakındır.

Sıkı kural: envanter, bilgi sistemine olan güveniniz kadar doğrudur. Bu güveni inşa eden mimaridir, ne kadar geç başlarsanız sapma o kadar pahalıya patlar.

İlgili: QuickBooks ile Amazon satışlarını otomatik senkronize etme — finansal mutabakat tarafı için.