E-ticaret operasyon yönetimi, her siparişin doğru ürün, doğru stok ve doğru müşteri kaydıyla ilerlemesini sağlamaktır. Stok, ödeme, paketleme, kargo ve iade birbirine bağlı durum değişimleridir. Bir adımın tamamlandığını diğer sistemin varsayması yerine hangi kayıt ve sorumluyla doğrulanacağını belirlemek gerekir.
Stok yönetimini depo sayısından sipariş taahhüdüne taşıyın
Mağaza, pazaryeri ve depo aynı ürün miktarını farklı sistemlerde gösterebilir. Satılabilir stok, fiziksel stoktan ayrılmalıdır; ayrılmış, hasarlı veya kalite kontrolündeki ürün hemen satışa açılmamalıdır. SKU eşleşmesi ve varyant kimliği bütün kanallarda tutarlı olmalıdır. Aynı ürünün iki farklı kodla tutulması fazla satış riskini görünmez kılar.
Entegrasyon varsa güncelleme sıklığı ve hata davranışını öğrenin. Bağlantının kurulmuş olması bütün stok değişimlerinin anında işlendiğini göstermez. Son başarılı güncelleme zamanı ve başarısız görevler izlenmelidir. Bağlantı koptuğunda hangi ürün veya kanalın geçici durdurulacağı önceden kararlaştırılmalıdır.
Fiziksel, ayrılmış ve satılabilir stok aynı alan değildir
Depoda bulunan bir ürün başka sipariş için ayrılmış, kalite kontrolünde bekliyor veya hasarlı olabilir. Satılabilir stok tanımında bu durumları açıkça ayırın. Birden fazla kanala aynı fiziksel adedi ayrı ayrı tam kullanılabilir olarak göndermek, son ürünü iki müşteriye satma riski yaratır. Güvenlik stoğu bu riski azaltmak için değerlendirilebilir; ancak veri gecikmesinin veya hatalı rezervasyonun kalıcı çözümü olarak görülmemelidir.
Temsili sorun: Son kalan ürün aynı anda web mağazasında ve pazaryerinde sipariş edilir. Her iki ekran da eski stok kaydını görmüştür. İnceleme yalnız “stok yanlış” notuyla kapatılmaz: stok okuma zamanı, sipariş kabul zamanı, rezervasyonun oluşturulduğu sistem ve diğer kanala güncellemenin ulaştığı zaman karşılaştırılır. Ekip aynı stok için iki rezervasyon oluşmasını hangi katmanda önleyeceğine karar verir; kullanılacak kilit veya işlem yöntemi mevcut altyapıya göre geliştirme ekibince seçilir.
SKU değişimi eski siparişin kimliğini bozmamalı
Ürün adı müşteri için okunabilir bir açıklamadır; sistem eşlemesi için tek başına güvenilir anahtar değildir. Ana ürün, varyant, barkod ve kanal ürün kimliğinin hangi ilişkiyi temsil ettiğini yazın. Bir varyant silinip yeniden açıldığında geçmiş sipariş satırları yeni ürüne yanlış bağlanmamalıdır. Katalog dönüşümünde eski-yeni kimlik eşleme dosyası saklanmalı ve gerçek ürün örnekleriyle kontrol edilmelidir.
Sipariş durumunu gerçekleşen olayla eşleştirin
- Sipariş alındı: mağaza kaydı oluştu.
- Ödeme/işletme kabulü: iş modeline göre gerekli doğrulama tamamlandı.
- Stok ayrıldı: satılabilir miktar doğru güncellendi.
- Hazırlanıyor: sorumlu ekip ürünü topladı ve kontrol etti.
- Gönderildi: kargo kaydı ve müşteriye bildirilen durum doğrulandı.
- Teslim/iptal/iade: operasyon ve mali kayıt aynı işlemle ilişkilendirildi.
Bunlar işletme süreç örneğidir, platformların birebir API status adları değildir. Entegrasyonda sağlayıcının güncel durumlarını kendi operasyon sözlüğünüzle eşleştirin. Trendyol resmî entegrasyon portalı ürün ve sipariş servisleri için başvurudur; hesabınızdaki kurulumun gerçekten çalıştığını ayrıca test etmeniz gerekir.
Operasyon ekranındaki “tamamlandı” ifadesi hangi olayı anlatıyor? Etiket üretmek, paketi taşıyıcıya vermek ve müşteriye teslim etmek farklı durumlardır. Taşıyıcı verisi gelmeden teslim edilmiş kabul edilen sipariş, destek ve iade incelemesini yanıltır. Her geçiş için tetikleyen kaydı, yetkili sistemi, zaman bilgisini ve geri alınabilir olup olmadığını belirleyin. Durum isimlerini platformlar arasında birebir aynı sanmak yerine anlam eşlemesi yapın.
Diğer sütunları görmek için yatay kaydırın.
| İş durumu | Kabul kanıtı | Yanlış yorum riski |
|---|---|---|
| Ödeme kabulü | Sağlayıcı ve sipariş kaydının eşleşmesi | Yalnız teşekkür ekranını ödeme sanmak |
| Hazırlama | Depoda ayrılmış sipariş satırları | Eksik ürünle paket kapatmak |
| Kargoya devir | Gerçek taşıyıcı teslim kaydı | Etiket basımını teslim saymak |
| İade incelemesi | Gelen ürün ve ilgili sipariş satırı | Talep açılışını para iadesi saymak |
Entegrasyon hatalarında tekrar denemeyi güvenli tasarlayın
Başarılı siparişler kadar hata durumu da yönetilmelidir. Ödeme kabul edilmiş ama sipariş kaydı oluşmamış, kargo etiketi hazırlanmış ama stok bulunamamış veya aynı işlem yeniden gelmiş olabilir. Bu olayların sahibi, inceleme süresi ve müşteri iletişim adımı belli olmalıdır. “Sistem hatası” diye sınırsız bekleyen kayıtlar operasyon kontrolü değildir.
Yeniden deneme aynı siparişi iki kez işleme sokmamalıdır. Sipariş veya işlem kimliği üzerinden tekrar kaydın nasıl ayırt edileceğini geliştiriciyle değerlendirin. Stok uyuşmazlığında kanalları körlemesine eşitlemek yerine hangi kaydın gerçek olduğunu kontrol edin.
Zaman aşımı işlemin başarısız olduğunu tek başına göstermez
Sistem sipariş oluşturmuş fakat yanıt bağlantıda kaybolmuş olabilir. Aynı isteği körlemesine yeniden göndermek ikinci kayıt üretebilir. Kanal sipariş kimliği ve işlem türüyle mevcut sonucu sorgulama, yinelenen işlemi ayırt eden anahtar kullanma ve sonuç bilinmiyorsa inceleme kuyruğuna alma gibi yaklaşımları entegrasyon ekibiyle değerlendirin. Her API'nin aynı güvenli tekrar mekanizmasını desteklediğini varsaymayın.
Uygulama veritabanı güncellenirken dış sisteme bildirim gönderilememesi ayrı bir tutarsızlıktır. İşlem kaydının ve gönderilecek mesajın birlikte izlenmesi, başarısız bildirimin sonradan bulunmasını kolaylaştırabilir. Teknik seçimden önce hangi kaybın önleneceğini tanımlayın: kaybolan sipariş mi, tekrarlanan fatura mı, güncellenmeyen stok mu? Her sorun aynı yeniden deneme kuralıyla çözülmez.
Trendyol entegrasyon dokümantasyonu ürün ve sipariş işlemleri için resmî başlangıç noktasıdır. Servis sürümü, yetkilendirme ve güncel hata yanıtları kullanılan uç noktadan kontrol edilmelidir. Bu rehber sabit bir istek limiti veya bütün entegratörlerde aynı durum kodları bulunduğu iddiasında bulunmaz.
İadede ürün, para ve belgeyi ayrı izleyin
İade talebi, ürünün depoya ulaşması, ürün durumunun değerlendirilmesi ve para iadesi ayrı aşamalardır. Kontrol edilmemiş ürünün yeniden satışa alınması kalite ve stok hatası oluşturabilir. İade gerekçelerini ürün bilgisi, hasar, yanlış seçim ve teslimat gibi işletmeye yararlı sınıflarda takip edin; her talebi tek kategoriye koymayın.
Mali düzeltmeyi sipariş kimliğiyle ilişkilendirin. Komisyon, kargo veya vergi işlemi için kişisel sözleşme ve muhasebe değerlendirmesi gerekir. Komisyon ve katkı rehberi bu ayrımı anlatır; otomatik hukuki veya vergisel onay yerine kullanılmamalıdır.
Kısmi iadede siparişin tamamını stok geri dönüşü olarak işlemek elde olmayan ürün yaratabilir. Gelen ürünün varyantını, miktarını ve yeniden satılabilir durumunu satır düzeyinde kaydedin. Müşteriye para iadesi ile depoya geri giriş farklı günlerde gerçekleşebilir; birinin tamamlanması diğerini otomatik tamamlamaz. İlgili belge ve vergi işlemleri işletmenin koşullarına göre muhasebe sorumlusuyla değerlendirilmelidir.
İstisna kaydının bir sahibi ve kapanış kanıtı olmalı
İade kaydı “entegratöre iletildi” diye kapanmamalıdır. Sonucun doğrulandığı ekran veya işlem kimliği, etkilenen sipariş satırları ve kontrol eden kişi kayıtta bulunmalıdır. Sorun başka ekibe devredildiğinde sorumluluk boşluğu oluşmaması için kabul eden kişi belirtilir. Geciken kayıtların yaşı takip edilir; bütün hata türleri için uydurma tek bir çözüm süresi verilmez.
Günlük kapanış ve yoğun dönem provası
- Bekleyen ödeme/sipariş uyuşmazlığı var mı?
- Ayrılmış stok ve fiziksel stok örneklerde eşleşiyor mu?
- Hazırlık süresini aşan siparişin sahibi belli mi?
- İptal ve iade kayıtları ilgili sistemlere işlendi mi?
- Entegrasyonun başarısız veya tekrar eden görevleri incelendi mi?
Pazaryeri yönetimi rehberi kanal sorumluluklarını tamamlar. Operasyon akışını e-ticaret danışmanlığı kapsamında değerlendirmek isterseniz örnek sipariş, stok kaynağı ve hata kayıtlarıyla başlayın. Doğru çıktı yeni bir genel kontrol listesi değil, işletmenizin gerçek durum ve istisnalarını yöneten uygulanabilir akış olmalıdır.
Gün sonunda yalnız toplam sipariş sayısına bakmak yeterli değildir. Aynı dönemde ödeme kabulü olup sipariş kaydı olmayan işlemleri, stok ayrıldığı hâlde iptal edilmiş siparişleri ve etiket üretilip taşıyıcı hareketi başlamayan paketleri ayrı listelerle karşılaştırın. Farkları otomatik düzeltmeden önce kaynak verinin güncellenme gecikmesini kontrol edin. Kapanış dosyası kişisel veriyi gereksiz çoğaltmamalıdır.
Yoğun kampanya öncesinde küçük bir kontrollü prova yapın: son stok, kısmi iptal, taşıyıcı kesintisi ve aynı siparişin tekrar bildirilmesi senaryolarını çalıştırın. Canlı müşteriye sahte sipariş veya bildirim göndermeden uygun test ortamını kullanın. Prova sonunda “sistem çalışıyor” yerine hangi durumda hangi kaydın oluştuğunu ve ekiplerin hangi sırayla devreye girdiğini belgeleyin. Operasyon kalitesi, yalnız hızdan değil hatanın görünür ve geri izlenebilir olmasından da oluşur.
