STOK FİYAT SENKRONİZASYONU PLANLAMAK

Pazartesi sabahı bir müşteri Trendyol'dan kazak sipariş ediyor. Aynı dakika kendi sitende de aynı kazak satılıyor; ama stoğun tek bir tane vardı. Çarşamba günü iki müşteriye birden "ürün stoğumuzda yok, iade ediyoruz" mesajı atmak zorunda kalıyorsun. Bu olay haftada bir tekrarlanırsa marka itibarı çürümeye başlar.

Çok kanallı elektronik ticaret stok ve fiyat senkronizasyonu olmadan büyüyemez. İki kanal arasında bile manuel yönetim hata kabarır; üç kanaldan sonra felaket kaçınılmaz. Otomatik senkronizasyon kurulmadıysa her ek kanal "büyüme" değil "sorun çoğaltma" olur.

Stokta olmayan ürünü satmak iade ve kötü yorum, fiyatı eski kalan ürünü satmak doğrudan zarar üretir — senkronizasyon bu yüzden teknik detay değil ticari hayat sigortasıdır. Mimari seçenekleri, araç-senaryo eşleşmeleri ve sürdürülebilir altyapı kurulumu da bu sigortanın poliçe maddeleridir.

Problem Nerede Doğuyor

Çok kanallı satış yapan tipik bir e-ticaret operasyonu:

• Kendi web sitesi
• Trendyol
• Hepsiburada
• Amazon
• N11
• Belki fiziksel mağaza
• Belki B2B portalı

Her kanalın kendi stok ve fiyat sistemi var. Senkronizasyon olmadığında oluşan sorunlar:

• Over-selling: Stoğunun olmadığı ürünleri satıyorsun. Müşteri ödüyor, sen iptal ediyorsun. Kötü deneyim + iade işlem maliyeti.
• Under-selling: Stoğun var ama kanal "tükendi" gösteriyor. Satış kaybı.
• Fiyat tutarsızlığı: Aynı ürün bir kanalda 199, diğerinde 219. Müşteri fark ederse güveni sarsılır.
• Marketplace cezası: Trendyol gibi platformlar iptali artarsa hesabı askıya alır. Gerçek operasyonel risk.
• Personel zamanı: Her kanalı manuel güncellemek günde saatlerce iş.

Senkronizasyon Mimarileri

Stok ve fiyat senkronizasyonu için üç ana yaklaşım:

1. Single Source of Truth (Tek Doğru Kaynak)

Bir sistem (ERP, PIM, veya custom backend) tüm stok ve fiyat verisinin asıl kaynağı; diğer kanallar onun aynası.

• ERP'de stok düşer → web, Trendyol, Hepsiburada otomatik güncellenir.
• Her kanaldan gelen sipariş ERP'ye düşer → stok merkezi sistemden güncellenir.

Avantaj: Net mimari, çakışma yok.
Dezavantaj: Tek noktaya bağımlılık; merkezi sistem çökse her şey durur.

2. Push-Based

Stok değişen sistem (genelde web siteniz veya ERP) diğer kanallara API ile push yapar.

Avantaj: Gerçek zamanlı, gecikme yok.
Dezavantaj: API rate limit'leri, hata yönetimi karmaşıklığı.

3. Pull-Based

Kanal sistemleri periyodik olarak (örn. 15 dakikada bir) merkezi sistemden veri çekerler.

Avantaj: Daha basit, rate limit sorunu az.
Dezavantaj: Gecikme var (15 dk yetmez, 5 dk bile bazen yetmiyor).

Senkronizasyon Sıklığı

Hangi sıklıkla senkron yapılmalı? Karar verirken kriterler:

Çok sık senkronizasyon API rate limit'leri ve sunucu yükü yaratır; çok seyrek over-selling riski getirir. Doğru frekans operasyon karakterine göre değişir.

Senkron vs Asenkron

Senkronizasyon iki şekilde tetiklenebilir:

• Senkron (event-driven): Stok değiştiği anda kanallara push. Tipik: webhook.
• Asenkron (scheduled): Belirli zamanlarda (cron job) tüm değişikliklerin toplu push'ı.

İdeal hibrit: kritik değişiklikler (yeni sipariş, stok bitti) event-driven; toplu güncellemeler (fiyat ayarı, ürün ekleme) scheduled.

Veri Akışı Diyagramı

Tipik bir multi-channel senkronizasyon akışı:

[Web Sitesi] ─┐
              │
[Mağaza POS] ─┼─→ [Merkezi ERP / PIM] ──→ [Tüm Marketplace API'ler]
              │           ↑
[Marketplace] ─┘           │
   (sipariş               │
    geliyor)              ↓
                    [Bildirim / Dashboard]

Her sipariş hangi kanaldan gelirse gelsin, merkezi sisteme akar. Merkezi sistem stoğu günceller; diğer tüm kanallara güncellenmiş stoğu push eder. Bu döngü her sipariş için dakikalar içinde tamamlanır.

Senkronizasyon Araçları

Türkiye pazarında yaygın araçlar:

• Vendomate: Türkiye'ye özel multi-channel listing ve senkronizasyon.
• SaleMetrics: Pazaryeri yönetimi ve stok-fiyat senkronu.
• NCommerce: Trendyol, Hepsiburada, N11 entegrasyonu.
• Sentos / Onerce: Yerel multi-channel araçlar.
• Pazarama, Çiçeksepeti API'leri: Doğrudan platform API'leri ile custom entegrasyon.
• Mikro, Logo Tiger, Netsis ERP: ERP'lerin marketplace eklentileri.
• Shopify + Stocky: Shopify e-ticaret platformu için yerli marketplace entegrasyonu.

Global pazarda Channable, ChannelEngine, ChannelAdvisor gibi araçlar daha kapsamlı ama Türkiye marketplace'lerine native destek genelde yetersiz.

API Limit Yönetimi

Her marketplace API rate limit'i var; aşıldığında bloklanırsın. Tipik limitler:

• Trendyol: 100 request/dakika başına
• Hepsiburada: 1000 request/saat başına
• N11: 60 request/dakika başına
• Amazon: Throttling-based; product type'a göre

10.000 ürünlü kataloğu olan biri her dakikalık senkronizasyonda 10.000 request atamaz; limit aşılır. Çözüm yaklaşımları:

• Diff sync: Tüm katalogu değil, son değişiklikleri push.
• Bulk update: Tek request'te birden çok ürün güncellemesi.
• Queue ile rate limiting: Senkronizasyon görevleri kuyruğa giriyor, kontrollü hızda işleniyor.
• Backoff strategy: Rate limit hata kodunda otomatik geri çekilme.

Bu mimari endişeleri başlangıçtan değil; senkron 1000 ürüne geldikten sonra fark edilir. O yüzden senkronizasyon altyapısı baştan iyi tasarlanır; sonradan refactor maliyetli.

Hata Yönetimi

Senkronizasyon sırasında hata kaçınılmaz. İyi sistemin özellikleri:

• Retry: Hata alındığında otomatik tekrar deneme; exponential backoff ile.
• Logging: Her hata kaydı tutulur; sonradan analiz edilir.
• Alerting: Kritik hatalarda (örn. stok eski versiyonla kaldı) anlık bildirim.
• Manual override: Belirli ürün için manuel müdahale; otomatik senkron geçici devre dışı.
• Reconciliation: Periyodik (günlük veya haftalık) tam denetim; tüm kanal verilerinin merkezi sistemle birebir eşit olup olmadığı kontrol.

Reconciliation süreci özellikle değerli; küçük drift'leri yakalar, büyük krizleri önler. "Bugün tüm kanallar senkron mu" sorusunun cevabını otomatik veren bir kontrol.

Stok Rezerv Mekanizması

Bir kullanıcı kanal A'da sepete ürün koyduğunda diğer kanallarda o stok hâlâ "var" gösteriyor. Eğer aynı stoktan başka bir kullanıcı kanal B'de hızlı satın alırsa, A'da satın almaya geçen kullanıcı over-sell olur.

Çözüm: Stok rezerv mekanizması. Sepete eklendiği anda merkezi sistemde "rezerve" stat'i alır; diğer kanallardan da düşülür. Satın alma tamamlanırsa kalıcı düşüm; vazgeçilir veya zaman aşımı (örn. 30 dk) olursa rezerv kalkar.

Bu mekanizma karmaşık ama kritik. Özellikle az stoklu ürünlerde (1-3 adet) zorunlu.

Fiyat Senkronizasyonu Nüansları

Fiyat senkronizasyonu stok'tan daha kompleks olabilir çünkü her kanalın kendi fiyat dinamikleri var:

• Marketplace komisyonu: Trendyol %15-25 komisyon alır; aynı marj için fiyat farklı olur.
• Kampanyaların farklı zamanları: Bir kanalda indirim, diğerinde değil.
• Kanal-specific kupon ve teklif: Cep telefonu uygulaması fiyatı, masaüstü fiyat farklı olabilir.
• KDV varyasyonu (uluslararasıysa): Farklı ülkelerde farklı KDV oranları.
• Dinamik fiyatlama: Rakip fiyatına göre otomatik ayarlama (Amazon repricing).

İyi bir fiyat senkronizasyonu hem base price hem kanal-specific ayarları yönetir. Tipik yapı: master price + channel rules (% ekle, sabit ekle, kampanya uygula).

Sipariş Akışı Senkronizasyonu

Stok-fiyat dışında, sipariş akışı da senkronizasyon konusu. Bir marketplace'ten gelen siparişin:

• Anlık olarak merkezi sisteme akması
• Müşteri bilgileri CRM'e işlenmesi
• Stok düşümü tüm kanallara push
• Sipariş durumu (kargolandı, teslim edildi) marketplace'e bildirilmesi
• Fatura kaydı (e-arşiv için)

Bu döngü düzgün çalışmadığında müşteri "kargom nerede" sorusuyla telefon eder; sen sistemde sipariş bulamazsın. Doğru senkronize çalışan altyapıda her şey görünür ve takip edilebilir.

Çoklu Depo Senkronizasyonu

Birden fazla depo (örn. İstanbul, Ankara, İzmir) varsa stok dağılımı da senkronize edilir:

• Her ürün için depo başına stok bilgisi
• Müşteri lokasyonuna göre en yakın depodan kargo
• Bir depoda stok bitince diğerinden tamamlama
• Depolar arası transfer sırasında "in transit" durumu

Tek depolu senaryodan çoklu depoya geçiş ciddi mimari değişiklik. Başlangıçta planlamak; sonradan eklemek refactor maliyetli.

Performans ve Yük

Stok senkronizasyonu yoğun bir veri akışı:

• Her sipariş için 5-10 API çağrısı (her kanal güncellenmek için)
• Saniyede onlarca sipariş gelirse yüzlerce API çağrısı
• Database'de stok tablosu çok sık güncelleniyor; lock contention sorunu

Çözüm yaklaşımları:

• Event sourcing: değişiklikleri event olarak kaydet, replay et
• Caching layer: Redis ile hot data hızlı erişim
• Eventual consistency: tüm kanalların aynı anda eşit olması zorunlu değil; saniyeler içinde tutarlı
• Queue tabanlı sync: RabbitMQ, AWS SQS ile sıralı işleme

Kapsamlı e-ticaret eğitimi içinde çok kanallı satış altyapısı, stok-fiyat yönetimi ve operasyon ölçeklemesi pratik anlatılır.

Maliyet — ROI Hesabı

Senkronizasyon altyapısının maliyeti:

• Aylık SaaS abonelik (1.500-15.000 TL aralığında, kanal ve ürün sayısına göre)
• Veya tek seferlik custom geliştirme (50.000-500.000 TL arası)
• Bakım maliyeti (aylık)

ROI nasıl hesaplanır:

• Eski sistemde over-sell maliyeti: kaç iptal/ay × ortalama sipariş tutarı × hata oranı
• Manuel yönetim personel zamanı: kaç saat/hafta × hourly rate
• Marketplace cezaları (iptal oranı yüksekse hesap askısı, ciro kaybı)
• Müşteri itibar maliyeti (long-term)

Tipik orta ölçek e-ticaret için senkronizasyon altyapısı 3-6 ayda kendini ödüyor. 5+ kanaldan satış yapan operasyon için yatırım değil zorunluluk.

Tipik Hatalar

• Tek bir manual master: Excel'de stok takibi + günde bir kanal güncelleme. 2 kanalda işe yarar, 4 kanaldan sonra felaket.
• Hata loglarını izlememek: Senkronizasyon hatası sessizce başarısız; bir hafta sonra büyük drift.
• Rate limit aşımı: Çok sık senkronizasyon yaparken API ban yenilir.
• Reconciliation eksik: Düzenli denetim yok; küçük farklar birikiyor.
• Rezerv mekanizması yok: Az stoklu ürünlerde over-sell garanti.
• Manuel müdahale alanı yok: Otomatik sistem hata yapınca elle düzeltme zor.
• Performans düşünmemek: 10K ürünlü katalogla başlayan sistem 100K'ya çıkınca çöküyor.

Senkronizasyon mimarisi e-ticaret operasyonunun belki en görünmez ama en kritik altyapısı. Yatırımı erken yapan operasyonlar büyürken sorun çıkarmaz; ihmal eden operasyonlar büyüme yüküne dayanamaz. "Sonra çözeriz" yaklaşımı bu konuda iflasla biter; ölçeklendikçe sorun katlanır. Doğru kurulan senkronizasyon altyapısı, çok kanallı satışın görünmez kahramanıdır.