Çoğu satıcı iadeyi bir müşteri ilişkileri sorunu sanır; oysa iade, yüzde doksan oranında bir karar verme sorunudur. Sen her talebi okuyup "bu haklı mı" diye düşündüğün sürece, aynı soruya her gün yeniden cevap veriyorsun. Üstelik cevabın sabah dokuzda verdiğinle akşam onda verdiğin birbirinden farklı oluyor. Yorgunluk, marjını sessizce eritir.
Gerçek şu: iade taleplerinin büyük bölümü birbirinin kopyasıdır. Kod kullanılmamış, sipariş iki saatten yeni, tutar küçük, müşterinin geçmişi temiz. Böyle bir talebi insanın okuması kaynak israfıdır. Bu yazıda iade kararını bir kurallar motoruna nasıl devredeceğini, hangi koşulları hangi sırayla değerlendirmen gerektiğini ve bir e-pin satış scriptinin bu işi suistimale kapı açmadan nasıl yürüttüğünü somut tablolarla anlatacağım.
Kurallar motoru nedir, basit bir "if" yığınından nasıl ayrılır?
Kod içine gömülmüş şartlar da karar verir, ama onları değiştirmek için geliştirici gerekir. Kurallar motoru ise kararı veriden okur: her kural bir koşul kümesi, bir öncelik sırası ve bir eylemden oluşur ve yönetim panelinden düzenlenebilir. Böylece iade politikanı değiştirmek dağıtım yapmayı değil, bir satır güncellemeyi gerektirir.
Ayrımın ikinci boyutu izlenebilirliktir. Bir "if" yığını kararı verir ama neden verdiğini söylemez. Motor ise her kararın hangi kuralla, hangi girdilerle alındığını kaydeder. Aylar sonra bir müşteri "bana neden reddedildi" dediğinde elinde cevap olur. Bu yüzden ciddi bir dijital ürün satış yazılımında iade mantığı kodda değil, kural tablosunda yaşar.
Hangi sinyaller karar verir? Kanıt puanı mantığı
Tek bir koşula bakarak karar veren sistem ya çok cömert ya çok katı olur. Doğru yaklaşım, birden fazla sinyali puanlayıp toplamı eşiklerle karşılaştırmaktır. Kodun görüntülenip görüntülenmediği, siparişten bu yana geçen süre, müşterinin önceki iade oranı, ödeme yöntemi, ürünün tedarikçi tarafında iptal edilebilir olup olmaması: her biri ayrı bir ağırlık taşır.
| Sinyal | Değer | Puan etkisi | Gerekçe |
|---|---|---|---|
| Kod görüntülenmedi | Evet | +40 | Ürün fiilen tüketilmemiş |
| Sipariş yaşı | 0-2 saat | +20 | Tedarikçi iptali hâlâ mümkün |
| Sipariş yaşı | 24 saat üstü | -25 | Piyasa fiyatı değişmiş olabilir |
| Müşteri iade oranı | %0-5 | +15 | Geçmiş davranış güvenilir |
| Müşteri iade oranı | %25 üstü | -35 | Sistematik suistimal şüphesi |
| Tutar | Ortalama sepetin altı | +10 | Riskin maliyeti düşük |
| Ödeme yöntemi | Havale / EFT | -10 | Geri ödeme eli zorlaştırır |
| Aynı ürüne 3. talep | Evet | -45 | Kalıplaşmış davranış |
Toplam puan 60 ve üstündeyse otomatik onay, 20 ile 59 arasındaysa insan incelemesi, 20 altındaysa gerekçeli otomatik ret. Bu üç bantlı yapı, hem hızı hem kontrolü aynı anda verir. Önemli olan eşikleri kutsallaştırmamak: ilk ay 70 ile başla, ret itirazlarını izle, sonra aşağı çek.
Gelen iade taleplerinin karar bandına dağılımı
- Otomatik onay 45%
- İnsan incelemesi 25%
- Gerekçeli otomatik ret 20%
- Kısmi çözüm / kupon 10%
Eylem tarafı: iade tek bir şey değildir
Kurallar motorunun zayıf kaldığı yer genellikle koşullar değil, eylemlerdir. "Onayla" veya "reddet" ikilisi gerçek hayatı karşılamaz. Elinde en az beş farklı eylem olmalı: tam para iadesi, mağaza bakiyesi olarak iade, ürün değişimi, kısmi indirim kuponu ve talebi bekletip tedarikçiden teyit isteme. Bunların her biri farklı maliyet taşır.
Bakiye iadesi, para iadesine kıyasla çoğu işletmede nakit akışını korur ve müşteriyi sistemde tutar. Bu yüzden puanı sınırda olan taleplerde ilk teklif olarak bakiyeyi sunmak akıllıcadır. Müşteri kabul etmezse motor bir üst kademeye geçer. İyi bir e-pin yazılımı bu kademeli teklif mantığını da kural olarak tanımlamana izin verir.
Sınırda kalan taleplerde önce bakiye, kabul edilmezse para iadesi sun. Bu tek kural, iade maliyetini ortalama üçte bir oranında aşağı çeker.
Suistimal savunması: motoru kim kandırır?
Otomatik onay eşiği, bir süre sonra keşfedilir. Birileri hangi tutarın altında sorgusuz iade aldığını fark eder ve o sınırın hemen altında sipariş vermeye başlar. Bu yüzden kurallar motorunun yanında bir hız sınırlayıcı şart: aynı hesap için günde en fazla bir otomatik onay, ayda en fazla üç. Sınır aşıldığında talep otomatik olarak insan bandına düşer.
İkinci savunma, kimlik birleştirmedir. Aynı kart parmak izi, aynı IP bloğu veya aynı telefon numarası farklı hesaplarda görünüyorsa bunlar tek bir davranış profili sayılmalıdır. Aksi hâlde her yeni hesap, temiz geçmiş puanını yeniden kazanır. Üçüncüsü ise gölge mod: yeni yazdığın kuralı bir hafta boyunca karar vermeden yalnızca kaydet, insanın verdiği kararla karşılaştır. Uyum oranı yüzde doksanı geçmeden kuralı canlıya alma.
Kural setini canlıya almadan önce ne denetlenmeli?
Aşağıdaki liste, ister kendi sistemini kurgularken ister hazır bir epin yazılım paketini değerlendirirken önüne koyacağın denetim tablosudur. Her satır için "nasıl" sorusunu sor; "destekliyoruz" cevabıyla yetinme.
| Denetim maddesi | Neden gerekli | Kabul ölçütü |
|---|---|---|
| Kural sıralaması | Çelişen kurallarda sonuç belirli olmalı | Öncelik alanı zorunlu, ilk eşleşen kazanır |
| Gölge mod | Canlıda hasar vermeden test | Karar kaydedilir, uygulanmaz |
| Karar günlüğü | İtirazlara cevap verebilmek | Kural kimliği + girdi anlık görüntüsü |
| Hız sınırı | Eşik keşfi suistimalini kesmek | Hesap ve cihaz bazında sayaç |
| Geri alma | Hatalı kuralı anında durdurmak | Tek tıkla devre dışı bırakma |
| Muhasebe eşlemesi | İade kaydının raporla tutması | Her iade karşı kayıt üretir |
| Müşteri mesajı | Gerekçesiz ret güven kırar | Her karara şablonlu açıklama |
| Tedarikçi teyidi | İptal edilebilir üründe zarar yok | Bekletme durumu ve süre aşımı |
Bu sekiz maddeyi karşılayan bir yapı, iadeyi maliyet kalemi olmaktan çıkarıp rekabet avantajına çevirir. Çünkü hızlı ve tutarlı iade politikası, satın alma anındaki tereddüdü düşürür; dönüşüm oranındaki artış, verdiğin iadelerin çoğunu zaten karşılar. Sistemin bu tarafını özellikler listesinden, maliyet tarafını fiyat bölümünden karşılaştırabilirsin.
İade kararını sen değil, yazdığın kural versin
Pinova'nın kural tabanlı iade akışı; puanlama, kademeli teklif, hız sınırı ve karar günlüğüyle taleplerin üçte ikisini sen bakmadan kapatır.
Otomatik iade beni zarara sokar mı?
Eşiği doğru kurarsan hayır. Otomatik onayı yalnızca kodu görüntülenmemiş, yeni ve düşük tutarlı siparişlerle sınırlarsan onayladığın taleplerin neredeyse tamamı zaten haklı olan taleplerdir.
Kuralları kim yazmalı, geliştirici mi?
Politikayı işi yöneten kişi yazmalı. Kurallar motorunun amacı tam olarak budur: koşul ve eylem panelden tanımlanır, geliştirici yalnızca yeni sinyal alanları eklendiğinde devreye girer.
Gölge modu ne kadar süre çalıştırmalıyım?
En az bir hafta veya yüz karar, hangisi daha uzunsa. Motorun kararı ile insanın kararı arasındaki uyum yüzde doksanı geçtiğinde kuralı canlıya almak güvenlidir.
Reddedilen müşteriye ne söylenmeli?
Kararın hangi somut nedene dayandığı ve varsa alternatif çözüm. "Politikamız gereği" cümlesi itirazı büyütür; "kod hesabında görüntülendiği için" cümlesi tartışmayı bitirir.
İade otomasyonu, müşteriye sırtını dönmek değil; aynı soruya her seferinde aynı adil cevabı vermeyi garantilemektir. Kural setinin panelde nasıl tanımlandığını, puanların hangi alanlardan beslendiğini ve bir talebin karar günlüğünde nasıl göründüğünü incelemek istersen canlı demo içinde örnek bir iade talebi açıp motoru gerçek veriyle çalıştırırken izleyebilirsin.