Dijital Ürün Scripti Çoklu Tedarikçi Yönlendirme Kuralları: Büyük Bayilerin Yıllardır Gizlediği Sıralama Mantığını Adım Adım Açıyoruz

Çoğu kişi çoklu tedarikçi meselesini şöyle sanır: iki tane API anahtarı alırsın, birini yedek olarak bir kenara yazarsın, biri çökerse elle diğerine geçersin. Oysa günde üç yüz sipariş geçen bir panelde bu yaklaşım tam olarak şu anlama gelir: gecenin ikisinde uyanıp hangi tedarikçinin stoğunun bittiğini tahmin etmeye çalışmak. Senin rakibinin aynı saatte hiçbir şey yapmasına gerek yok, çünkü onun dijital ürün satış scripti kararı kendi veriyor.

Gerçek fark, tedarikçi sayısında değil; yönlendirme kuralının yazılı olup olmamasında. Tek bir ürün için üç tedarikçin olabilir ama sistem "hangi koşulda hangisine gideceğim" sorusuna deterministik bir cevap üretmiyorsa, elinde üç tedarikçi değil üç ayrı risk var. Bu yazıda bir e-pin satış scripti içinde yönlendirmenin gerçekte hangi katmanlardan oluştuğunu, hangi metriğin hangi sırayla bakıldığını ve Pinova'nın bu kararı nasıl otomatikleştirdiğini tek tek konuşacağız.

Tedarikçi sırası neden "en ucuz olan önce" değildir?

Yeni başlayan herkesin ilk kurduğu kural aynıdır: en düşük alış fiyatına sahip tedarikçi birinci sırada olsun. Mantıklı görünür, çünkü marjı büyütür. Ama bu kural üç sipariş sonra kendini yer. En ucuz tedarikçi genellikle en dar stoklu, en yavaş cevap veren ve iade politikası en katı olandır. Sen 2 lira kazanırken müşteri 40 dakika beklediği için ticket açar, sen o ticket'a bakarken bir sonraki sipariş de aynı kuyruğa girer.

Sağlıklı bir sıralama, fiyatı tek başına değil ağırlıklı bir skor içinde kullanır. Alış fiyatı skorun bir bileşenidir; yanına son bir saatteki başarı oranı, ortalama teslim gecikmesi, o ürün için kalan stok adedi ve tedarikçinin bakiye durumu eklenir. Bir e-pin yazılımı bu skoru sipariş anında yeniden hesaplayabiliyorsa, sıralama artık senin dün yazdığın statik liste değil, o anki gerçekliktir.

Yönlendirme kuralı hangi dört katmandan oluşur?

Birinci katman uygunluk: tedarikçi bu ürünü gerçekten satıyor mu, eşleştirme tablosunda ürün kodu tanımlı mı, bölge/para birimi kısıtı var mı. İkinci katman yeterlilik: tedarikçideki bakiye bu siparişin alış tutarını karşılıyor mu, stok sayacı sıfırın üstünde mi. Üçüncü katman sağlık: son N istekteki hata oranı eşiğin altında mı, ortalama yanıt süresi kabul edilebilir mi. Dördüncü katman tercih: kalan adaylar arasından skoru en yüksek olan.

Bu dört katmanın sırası tartışmaya kapalıdır. Tercihi öne alırsan, bakiyesi bitmiş tedarikçiye sipariş yollayıp müşteriyi bekletirsin. Sağlığı en sona bırakırsan, çökmüş bir API'ye üç kez üst üste gidersin. Dijital ürün satış yazılımı tarafında bu sıralamayı koda gömmek yerine panelden yönetilebilir hale getirmek gerekir; çünkü tedarikçi davranışı sabit değil, kampanya dönemlerinde tamamen değişir.

Failover ile retry'ı karıştırmak neden para kaybettirir?

Retry aynı tedarikçiye tekrar denemektir; failover farklı tedarikçiye geçmektir. İkisini aynı akışta yönetmezsen ya çift teslimat ya hiç teslimat yaşarsın. Kural basit: idempotent olmayan istekte asla kör retry yapılmaz. Tedarikçi "zaman aşımı" döndüğünde sipariş gerçekten düşmüş olabilir de olmayabilir de. Bu durumda yapılacak şey yeniden sipariş değil, sorgu ile durum doğrulamaktır.

Doğru akış şu: istek gönderildi, zaman aşımı alındı, aynı referans numarasıyla durum sorgusu çekildi. Sonuç "başarılı" ise sipariş kapatılır. "Bulunamadı" ise tek bir retry hakkı kullanılır. Yine sonuç yoksa tedarikçi karantinaya alınır ve sipariş bir sonraki adaya yönlendirilir. Bir e-pin scripti bu üç adımı otomatik yürütmediği sürece, her zaman aşımı bir insan müdahalesi demektir.

Ürün eşleştirme tablosu olmadan yönlendirme kurulabilir mi?

Kurulamaz. Her tedarikçi aynı ürüne farklı kod verir: biri "PUBG-60UC", diğeri "pubgm_60", üçüncüsü sadece numerik bir id. Senin kendi kataloğundaki ürün ise tek bir kayıt. Arada bir eşleştirme tablosu yoksa yönlendirme mantığı çalışmaya bile başlayamaz, çünkü "bu ürünü kim satıyor" sorusunun cevabı yoktur.

Eşleştirmenin ikinci işlevi daha az fark edilir: birim farkını normalize etmek. Bir tedarikçi 60 UC'yi tek kalem satarken diğeri 3x20 UC olarak verir. Yönlendirme kuralı bunu bilmiyorsa müşteriye eksik teslimat gider. Pinova'da eşleştirme kaydı ürün kodu, çarpan, para birimi ve minimum adet bilgisini birlikte tutar; böylece aynı sipariş hangi tedarikçiye giderse gitsin müşteri tarafında sonuç aynı kalır.

Hangi kontrol listesini kurulumdan önce işaretlemelisin?

Yönlendirme kurmak teknik bir iş gibi görünür ama esasen bir operasyon kararıdır. Aşağıdaki listeyi tek tek işaretlemeden canlıya çıkmak, kuralı müşteri siparişleri üstünde test etmek anlamına gelir. Bunun bedeli genellikle iade ve itibar olarak ödenir.

Yönlendirme kararını nasıl ölçer ve iyileştirirsin?

Kural yazmak işin yarısı; ikinci yarısı kuralın gerçekten para kazandırdığını görmek. Bunun için üç rapor yeter. Birincisi tedarikçi bazlı başarı oranı: aynı ürün için kimin kaç siparişte ilk denemede teslim ettiği. İkincisi ortalama teslim süresi dağılımı. Üçüncüsü gerçekleşen marj; yani skor hesabındaki teorik marj değil, iade ve telafi sonrası elinde kalan.

Bu üç rapor yan yana konduğunda genellikle şu ortaya çıkar: en ucuz tedarikçi gerçekleşen marjda üçüncü sırada, çünkü iade oranı yüksek. İşte yönlendirme ağırlıklarını tam olarak burada değiştirirsin. Pinova'nın raporlama tarafı bu üç metriği aynı ekranda tuttuğu için ağırlık değişikliğinin etkisini bir hafta içinde görebilirsin. Detayları özellikler bölümünde, paket farklarını ise fiyat tablosunda bulabilirsin.

Yönlendirme mantığını yazıdan okumak bir şey, çalışırken görmek başka bir şey. Kural sıralamasının, karantina sayacının ve sipariş bazlı yönlendirme logunun gerçek panelde nasıl göründüğüne bakmak istiyorsan canlı demo üzerinden tek tek gez; sonra kendi tedarikçi listeni aynı dört katmana oturt.