Çoğu kişi tedarikçi kesintisini bir şanssızlık sanır. "API çöktü, elden ne gelir" der, sitesine büyük puntolarla bakım yazısı koyar ve akşam gelen siparişlerin buhar olup gitmesini izler. Oysa bu işi yıllardır yapan bayilerin çoğunda aynı kesinti yaşanır, aynı saatte, aynı tedarikçide. Fark şu: onların sitesi o kesintiyi müşteriye hiç göstermez. Müşteri siparişi verir, kodu alır, çıkar. Arka tarafta neyin yandığını bilmez bile.
Bu farkı yaratan şey daha iyi bir tedarikçi değil. Daha akıllı bir e-pin scripti mimarisi. Yani siparişin tek bir kaynağa zincirlenmediği, teslimatın anlık API cevabına bağımlı olmadığı, hata durumunda kimsenin elle müdahale etmesini beklemeyen bir kurgu. Bu yazıda o kurgunun katmanlarını tek tek açıyorum: hangi hata tipine hangi yanıt, tampon stok kaç adet olmalı, sıra sistemi kaç dakika beklemeli, müşteriye ne zaman ne söylenmeli.
Tedarikçi çöktüğünde gerçekte ne çöküyor?
Burada ilk yanlış teşhis şu: "tedarikçi çöktü" dediğimiz şey çoğu zaman tedarikçinin tamamen kapanması değildir. Çok daha sık görülen senaryo, API'nin cevap vermeye devam ettiği ama anlamsız cevap verdiği durumdur. Bakiye sorgusu 0 döner, stok listesi boş gelir, sipariş isteği 200 koduyla döner ama içinde kod yoktur. Bu tür kısmi bozulmalar, tam kesintiden çok daha tehlikelidir; çünkü senin sistemin bunu hata saymaz, satışı başarılı kabul eder ve müşteriye boş bir teslimat yapar.
İkinci sık senaryo zaman aşımıdır. Tedarikçi ayaktadır, ama yoğunluktan cevap 30 saniyede gelir. Senin dijital ürün satış scripti 10 saniyede vazgeçip "başarısız" derse, tedarikçi tarafında sipariş aslında geçmiş olur. Yani kodu düşmüşsün, müşteriye vermemişsin, parayı da iade etmişsin. Bu sessiz kaçak, ay sonu mutabakatında "nedense açık veriyoruz" diye baktığın kalemin ta kendisi. Bu yüzden yedekleme stratejisi kurmadan önce hata sınıflandırması yapmak şarttır: kesinti mi, bozulma mı, gecikme mi?
| Arıza tipi | Belirti | Tipik süre | Doğru otomatik yanıt |
|---|---|---|---|
| Tam kesinti | Bağlantı reddi, DNS hatası | 5-30 dk | Anında ikinci kaynağa yönlendir |
| Zaman aşımı | Cevap 20 sn üstü | 10-60 dk | Siparişi sıraya al, tekrar sorgula |
| Kısmi bozulma | Boş kod, 0 bakiye | Belirsiz | Teslimatı durdur, doğrulama isteği gönder |
| Stok tükenmesi | "out of stock" cevabı | Saatler | Tampon stoktan düş, kaynağı kapat |
| Kimlik hatası | 401 / 403 | Manuel çözülür | Kaynağı devre dışı bırak, yöneticiye bildir |
| Fiyat sapması | Beklenenin %20 üstü maliyet | Anlık | Satışı durdur, kâr korumasına gir |
Neden tek tedarikçi asla yeterli değil?
Tek kaynak mimarisi, işin hacmi küçükken zararsız görünür. Günde on beş sipariş alıyorsan kesintiyi telefonla, elle, WhatsApp'tan çözersin. Ama aynı kurgu günde iki yüz siparişte seni bitirir. Çünkü kesinti süresi sabittir, sipariş yoğunluğu değildir. Akşam 21.00 ile 23.00 arası gelen talebin tedarikçi tarafındaki yoğunlukla çakışması tesadüf değil; herkes aynı saatte aynı kaynağa yükleniyor.
Çözüm, her ürün için en az iki, tercihen üç kaynak tanımlamak ve bunları öncelik sırasına dizmektir. Birinci kaynak en düşük maliyetli olan, ikinci kaynak en hızlı cevap veren, üçüncü kaynak ise en pahalı ama en stabil olan olsun. Sistem sırayla dener; birinci başarısız olursa ikinciye, o da olmazsa üçüncüye geçer. Üçüncü kaynaktan yapılan satışta kârın düşer ama sipariş kaybolmaz. Bir siparişte iki lira kâr kaybetmek, o müşteriyi tamamen kaybetmekten kıyaslanamayacak kadar iyidir. İyi bir e-pin satış yazılımı bu sıralamayı ürün bazında tutmalı, kategori bazında değil; çünkü bir tedarikçi bir oyunda güçlü, diğerinde zayıftır.
Tampon stok kaç adet olmalı, nasıl hesaplanır?
Çoklu kaynak bile yetmediği anlar olur; bazen üç tedarikçi aynı üst sağlayıcıya bağlıdır ve hep birlikte düşerler. Burada devreye tampon stok girer: kendi veritabanında duran, önceden satın alınmış ve şifreli saklanan kod havuzu. Bu havuz sadece acil durumda açılır, normal satışta kullanılmaz.
Hesabı şöyle yaparsın: son 30 günün en yoğun 2 saatindeki sipariş adedini al, ikiyle çarp. Günde 200 sipariş yapan ve zirve saatinde 40 sipariş alan bir bayi için ürün başına 80 adetlik tampon mantıklıdır. Elbette bunu her ürün için tutmazsın; ciroyun %80'ini getiren ilk 10-15 ürün yeterlidir. Pareto burada acımasızca çalışır. Tampon stokta kritik nokta şifrelemedir: kodlar veritabanında açık metin durursa, tek bir sızıntı bütün sermayeni siler. Kod alanı mutlaka uygulama seviyesinde şifreli olmalı ve çözme anahtarı web kök dizininin dışında durmalı.
Tedarikçi kaynaklı sipariş başarısızlıklarının dağılımı
- Zaman aşımı ve gecikme 45%
- Stok tükenmesi 25%
- Tam kesinti 20%
- Kimlik ve yetki hatası 10%
Sıra sistemi olmadan hiçbir yedekleme çalışmaz
Yedeklemenin kalbi kaynak çeşitliliği değil, kuyruktur. Sipariş geldiği anda teslimat denemesi yapılır; başarısız olursa sipariş iptal edilmez, "beklemede" durumuna alınır ve arka planda çalışan bir işçi süreç onu belirli aralıklarla yeniden dener. Artan bekleme aralığı kullanmak doğru yaklaşımdır: 30 saniye, 2 dakika, 5 dakika, 15 dakika. Dört deneme sonunda hâlâ sonuç yoksa sipariş insan onayına düşer.
Bu yapının müşteri tarafındaki karşılığı şeffaflıktır. Sipariş ekranında "hata" yazmaz; "kodun hazırlanıyor, en geç 10 dakika içinde hesabında ve e-postanda olacak" yazar. Deneyim gösteriyor ki net süre taahhüdü verilen müşterilerin iptal isteği, belirsiz bekletilenlere göre çok daha az. Kuyruk ayrıca sana veri de kazandırır: hangi tedarikçi hangi saatte kaç kez düştü sorusunun cevabı orada birikir. Üç ay sonra o veriyle tedarikçinle pazarlık yaparsın, bu da epin yazılım yatırımının en beklenmedik getirisidir.
Bir kaynak üst üste 5 kez hata verdiyse o kaynağı 10 dakika boyunca tamamen devre dışı bırak. Aksi halde her yeni sipariş ölü kaynağa çarpar, kuyruk şişer ve tüm teslimat hattı yavaşlar. Devre kesici, kesintiyi tek üründen tüm siteye yayılmaktan kurtarır.
Müşteriye ne söyleyeceğini önceden yazmış olmak
Teknik yedekleme kadar önemli olan ikinci katman iletişimdir. Kesinti anında panikle yazılan mesajlar hep aynı hatayı yapar: suçu tedarikçiye atar. Müşteri senin tedarikçini tanımıyor, senden aldı. "Sağlayıcı kaynaklı gecikme" cümlesi güven değil şüphe üretir. Bunun yerine hazır şablonlar tut: gecikme bildirimi, tamamlandı bildirimi, alternatif ürün teklifi, iade bildirimi. Dördü de sistemde kayıtlı olsun, tek tuşla gitsin.
Ayrıca gecikmeyi telafi eden küçük bir mekanizma kur. 10 dakikayı aşan her siparişe otomatik olarak küçük bir bakiye puanı ya da sonraki alışverişte geçerli indirim kodu tanımlanması, şikâyetin büyük kısmını kaynağında bitirir. Maliyeti sipariş başına kuruşlar, kazandırdığı şey ise ikinci siparişin kendisi. Bunu manuel yapmaya çalışırsan yapmazsın; kural olarak e-pin satış scripti içine gömülü olması gerekir.
Kesintiyi önceden görmek: izleme ve alarm
Son katman, kesintiyi müşteriden önce senin öğrenmen. Her tedarikçi için dakikada bir çalışan basit bir sağlık kontrolü yeterlidir: bakiye sorgusu at, cevap süresini ve durumunu kaydet. İki ölçü izle: son 5 dakikadaki hata oranı ve ortalama cevap süresi. Hata oranı %20'yi geçtiğinde veya cevap süresi normalin üç katına çıktığında alarm çalsın.
Alarmın nereye gideceği de kritik. E-posta gece 02.00'de işe yaramaz; anlık bildirim kanalı kullan. Kendi telefonuna düşen tek satırlık bir mesaj -"Kaynak B: hata oranı %34, otomatik devre dışı"- sana müdahale için yarım saat kazandırır. Bu izleme kurulduktan sonra fark edeceğin şey şu olacak: tedarikçi kesintileri zaten her hafta oluyordu, sen sadece görmüyordun. Görünür hale geldiği gün, ciroyun ne kadarının sessizce sızdığını da anlarsın. Özellikler sayfasında bu katmanların hangisinin hazır geldiğini inceleyebilirsin.
| Kontrol maddesi | Durum ölçütü | Öncelik |
|---|---|---|
| Her ürün için 2+ kaynak tanımlı | Ciroyun %80'ini yapan ürünlerde zorunlu | Kritik |
| Kaynak öncelik sırası ürün bazlı | Kategori değil ürün seviyesinde | Kritik |
| Sipariş kuyruğu ve artan tekrar denemesi | 4 deneme, 30sn-15dk aralık | Kritik |
| Devre kesici eşiği | 5 hata / 10 dk devre dışı | Yüksek |
| Tampon stok havuzu | Zirve 2 saatin 2 katı adet | Yüksek |
| Kod alanı şifreleme | Anahtar web kökü dışında | Kritik |
| Boş/geçersiz kod doğrulaması | Teslimat öncesi biçim kontrolü | Yüksek |
| Hazır müşteri bildirim şablonları | 4 senaryo kayıtlı | Orta |
| Gecikme telafi kuralı | 10 dk üstü otomatik puan | Orta |
| Dakikalık sağlık kontrolü + anlık alarm | Hata %20 veya 3x gecikme | Yüksek |
Kesintiyi müşterinin göremediği bir altyapı kur
Çoklu kaynak, sipariş kuyruğu, devre kesici ve şifreli tampon stok; Pinova'da bunların hepsi hazır gelir. Sen sadece tedarikçi bilgilerini ve öncelik sırasını gir.
Tek tedarikçim var, yedekleme kurmam yine de mantıklı mı?
Evet. Tek tedarikçiyle bile sipariş kuyruğu, tekrar deneme ve tampon stok kurabilirsin. Bunlar zaten kesintilerin büyük kısmını görünmez hale getirir. İkinci kaynağı sonradan eklersin, mimari hazır olur.
Tampon stok için ne kadar sermaye bağlamam gerekir?
Genelde aylık cironun %2-4'ü yeterlidir. Sadece en çok satan 10-15 ürün için zirve saatin iki katı adet tutmak, çok büyük bir sermaye gerektirmez ama kesinti anında satışın tamamını kurtarır.
Otomatik tekrar denemede aynı kodu iki kez düşme riski var mı?
Her siparişe tekil bir işlem kimliği verilir ve tedarikçiye her denemede aynı kimlik gönderilir. Böylece tedarikçi tarafında mükerrer sipariş oluşmaz. Bu kontrol yoksa gerçekten çift düşme riski vardır.
Kesintiyi müşteriden gizlemek etik mi?
Gizlemek değil, gereksiz teknik detayla müşteriyi yormamak söz konusu. Net süre taahhüdü vermek ve tutmak şeffaflıktır. Süreyi tutamıyorsan haber vermek ve telafi etmek gerekir.
Yedekleme stratejisi anlatılacak bir şey değil, çalıştığı görülecek bir şey. Kuyruğun nasıl döndüğünü, bir kaynak devre dışı kaldığında siparişin nasıl sessizce ikinciye kaydığını ve yönetim ekranında bunun nasıl raporlandığını kendi gözünle görmek istiyorsan canlı demo üzerinden test siparişi geçir, sonra fiyat tablosuna bakarsın.