Çoğu işletme sahibi tedarikçi hatalarını tek bir kategoride toplar: "tedarikçi yine sorun çıkardı". Panelde kırmızı bir satır görür, müşteriye "kontrol ediyoruz" yazar, akşam elle çözmeye çalışır. Bu yaklaşım yanlış olduğu için değil, eksik olduğu için pahalıdır. Çünkü tedarikçinin sana döndürdüğü onlarca farklı hata kodunun her biri farklı bir davranış ister; hepsini aynı kovaya atmak, doğru davranışı seçme imkânını baştan yok eder.
Gerçek şu ki bekleyen siparişlerin çoğu tedarikçi arızasından değil, hatayı yorumlayamayan bir akıştan doğar. Aynı yanıt bazen "tekrar dene", bazen "asla tekrar deneme", bazen de "önce sorgula sonra karar ver" anlamına gelir. Bu ayrımı yapamayan bir e-pin satış scripti, ya boşa tekrar deneyerek çift teslimat üretir ya da gereksiz yere iptal ederek satışı çöpe atar. Bu yazıda tedarikçi hata kodlarını nasıl haritalayacağını, hangi sınıfın hangi davranışı hak ettiğini ve bunu bir dijital ürün satış yazılımı içinde nasıl kurumsallaştıracağını anlatıyorum.
Hata kodu neden mesaj değil, talimattır?
Tedarikçinin döndürdüğü metni müşteriye olduğu gibi göstermek en yaygın hatadır. "insufficient_balance" yazısını gören müşteri kendi bakiyesinin yetersiz olduğunu sanır, oysa bu senin tedarikçi bakiyendir. Hata kodu müşteriye gösterilecek bir mesaj değil, sisteme verilen bir talimattır. Talimatı okuyup uygun davranışı seçmek yazılımın işidir; müşteriye anlaşılır tek bir cümle gitmesi yeterlidir.
Bu nedenle her tedarikçi kodunun karşısına iki şey yazmalısın: sistemin ne yapacağı ve müşterinin ne göreceği. Bu iki kolon birbirinden tamamen bağımsızdır. Yirmi farklı teknik kod, müşteri tarafında üç farklı cümleye indirilebilir. Bir epin yazılım kurgusunda bu eşleme tablosu yoksa, destek ekibin her gün aynı çeviriyi elle yapıyor demektir.
Beş davranış sınıfı: hatayı sadeleştirme yöntemi
Yüzlerce kodla uğraşmak yerine hepsini beş sınıfa indir. Birinci sınıf kalıcı hata: ürün kapalı, kod geçersiz, yetki yok. Tekrar denemek anlamsızdır, sipariş hemen iptal ve iade edilir. İkinci sınıf geçici hata: zaman aşımı, ağ kopması, sunucu meşgul. Kontrollü tekrar denenir. Üçüncü sınıf belirsiz sonuç: istek gitti ama yanıt gelmedi. Burada asla körlemesine tekrar denenmez, önce durum sorgulanır.
Dördüncü sınıf kota ve hız sınırı: tedarikçi seni yavaşlatıyordur, bekleyip yeniden denemek doğrudur ama aynı hızda değil. Beşinci sınıf iş kuralı hatası: fiyat değişti, stok bitti, bölge uygun değil. Bu durumda ya alternatif tedarikçiye geç ya da müşteriye net bilgi ver. Bu beş sınıf, hata yönetimini sezgiden çıkarıp kurala bağlar.
| Hata sınıfı | Tipik yanıt | Sistem davranışı | Müşteri mesajı | Kayıt seviyesi |
|---|---|---|---|---|
| Kalıcı | Geçersiz ürün, yetki yok | Anında iptal + iade | Ürün şu an satışta değil | Uyarı |
| Geçici | Zaman aşımı, 503 | Artan aralıkla tekrar | İşlem hazırlanıyor | Bilgi |
| Belirsiz | Yanıt yok, bağlantı koptu | Durum sorgula, tekrar deneme | Doğrulama sürüyor | Kritik |
| Kota/hız | 429, limit aşıldı | Bekle, kuyruğa al | Sıradasın, birkaç dakika | Uyarı |
| İş kuralı | Stok bitti, fiyat değişti | Alternatif kaynağa geç | Alternatif sunuluyor | Bilgi |
Belirsiz sonuç: sessizce para yakan sınıf
Tüm sınıflar içinde en tehlikelisi belirsiz sonuçtur. İsteği gönderdin, tedarikçi tarafında işlem başladı, ama yanıt sana ulaşmadı. Panelinde hata görünür; tedarikçi tarafında ise sipariş başarılı. Burada sistem tekrar denerse aynı kodu ikinci kez satın alırsın ve bedelini sen ödersin. Bir ay boyunca fark edilmeyen bu tür çift alımlar, işletmelerin en sessiz gider kalemidir.
Çözüm iki parçalıdır. Birincisi benzersiz istek anahtarı: her sipariş için ürettiğin tek kimliği tedarikçiye gönder, aynı kimlikle gelen ikinci istek yeni işlem açmasın. İkincisi durum sorgulama önceliği: belirsiz sonuçta ilk hamle her zaman "bu işlemin durumu ne?" sorusu olmalı. Pinova bu iki mekanizmayı çekirdekte tutar; tedarikçi anahtar desteklemese bile kendi tarafında işlem parmak izi çıkarıp aynı siparişin ikinci kez gönderilmesini engeller.
Tedarikçi hatalarının sınıf dağılımı
- Geçici hata 40%
- İş kuralı hatası 28%
- Kalıcı hata 20%
- Belirsiz sonuç 12%
Müşteriye ne söyleyeceksin, paneline ne yazacaksın?
Hata yönetimi yarı teknik yarı iletişim işidir. Müşteri teknik kodu değil, sürecin nerede olduğunu ve ne zaman biteceğini bilmek ister. "İşlemin doğrulanıyor, en geç 10 dakika içinde e-postana düşecek; düşmezse tutar otomatik iade edilecek" cümlesi, yirmi farklı teknik kodu gereksiz kılar. Süre ve garanti verdiğin an destek yükün düşer.
Panel tarafında ise tam tersi geçerlidir: orada mümkün olan en çok ayrıntı bulunmalı. Ham tedarikçi yanıtı, istek kimliği, deneme sayısı, geçen süre, hangi kaynağa gidildiği. Bir itirazda seni kurtaran şey bu kayıttır. İyi bir e-pin satış yazılımı, sipariş detayında zaman çizgisi gösterir; kim ne zaman ne denedi sorusunu tek ekranda cevaplar. Bu yetenekleri özellikler bölümünde karşılaştırabilirsin.
Yanıt gelmediyse tekrar gönderme, durumu sorgula. Bu tek kural çift teslimat kaynaklı zararın neredeyse tamamını ortadan kaldırır.
Aynı hata üst üste geliyorsa sistem ne yapmalı?
Bir tedarikçi arka arkaya hata veriyorsa her siparişi ona göndermeye devam etmek zarardan başka bir şey üretmez. Burada devre kesici mantığı gerekir: belirli süre içinde belirlenen eşiği aşan hata sayısında o kaynak geçici olarak devre dışı kalır, trafik alternatif kaynağa akar. Belirli aralıklarla tek deneme ile yoklanır, sağlıklıysa yeniden devreye alınır.
Devre kesici olmayan sistemlerde bir tedarikçi arızası tüm siparişleri kuyruğa yığar, panel kilitlenir, destek boğulur. Olması gereken ise şu: müşteri hiçbir şey fark etmeden ikinci kaynaktan teslim alır, sen sabah raporunda "şu kaynak iki saat kapalıydı, 47 sipariş alternatiften karşılandı" satırını okursun. Aradaki fark, yazılımın hatayı bir felaket mi yoksa yönetilebilir bir olay mı saydığıdır.
Kendi hata haritanı nasıl kurarsın?
Hata yönetimini kurmanın en hızlı yolu, geçmiş logları tarayıp gerçekte hangi kodlarla karşılaştığını çıkarmaktır. Tahminle değil veriyle başla. En sık on kodu bul, her birini beş sınıftan birine yerleştir, davranış ve müşteri mesajını yaz. Tek oturumda yapılan bu çalışma, aylarca süren destek yorgunluğunu bitirir.
Aşağıdaki kontrol listesi, haritanı canlıya almadan önce doğrulamanı sağlar.
| Kontrol maddesi | Amaç | Kabul kriteri | Öncelik |
|---|---|---|---|
| En sık 10 hata kodu listelendi | Gerçek veriyle çalışmak | Log taraması yapıldı | Yüksek |
| Her kod bir sınıfa atandı | Davranış belirsizliğini bitirmek | Boş satır yok | Yüksek |
| Benzersiz istek anahtarı aktif | Çift teslimatı önlemek | Aynı sipariş 2 kez gitmiyor | Yüksek |
| Durum sorgulama akışı var | Belirsiz sonucu çözmek | Otomatik sorgu çalışıyor | Yüksek |
| Devre kesici eşikleri tanımlı | Arızalı kaynağı izole etmek | Eşik ve süre yazılı | Orta |
| Müşteri mesajları sadeleşti | Destek yükünü azaltmak | En fazla 4 farklı metin | Orta |
| Sipariş zaman çizgisi görünür | İtirazda kanıt üretmek | Tüm denemeler listeli | Orta |
Hataları olaya, olayları rapora çevir
Pinova; sınıf tabanlı hata haritası, benzersiz istek anahtarı, durum sorgulama ve devre kesici ile tedarikçi arızalarını müşterine yansıtmadan yönetir.
Tedarikçinin hata kodları belgelenmemişse ne yaparım?
Kendi loglarını kaynak kabul et. Gelen ham yanıtları biriktir, tekrarlayan kalıpları çıkar ve bunları beş davranış sınıfına eşle. Belge olmadan da çalışan bir harita kurabilirsin.
Her hatada otomatik iade vermek doğru mu?
Değil. Otomatik iade yalnızca kalıcı hatada ve süresi dolan belirsiz işlemde uygulanmalı. Geçici hatada iade vermek, birkaç saniye sonra başarıyla tamamlanacak satışı kaybetmek anlamına gelir.
Müşteriye teknik hata kodunu göstermeli miyim?
Hayır. Teknik kod panele, sade ve süre veren bir cümle müşteriye gider. Kod göstermek güven vermez, aksine destek mesajı sayısını artırır.
Devre kesici eşiğini nasıl belirlerim?
Basit başla: 5 dakikada 10 hata olursa kaynağı 10 dakika kapat, ardından tek deneme ile yokla. Trafiğin arttıkça eşikleri kendi verine göre kalibre edersin.
Tedarikçi hatalarını yönetmek, arızayı yok saymak değil onu öngörülebilir hale getirmektir. Beş sınıflı bir harita, benzersiz istek anahtarı, durum sorgulama önceliği ve devre kesici bir araya geldiğinde bekleyen sipariş sayın düşer, destek konuşmaların kısalır ve kâr tablondan sessizce sızan kalemler kapanır. Bu akışın gerçek panelde nasıl göründüğünü görmek için canlı demo üzerinde bir sipariş simüle et, sonra fiyat tarafına geç.