Çoğu bayi şüpheli siparişi bir kart sorunu sanır. Ödeme geldi, sistem kodu gönderdi, üç hafta sonra banka itiraz bildirimi düştü; suçlu olarak da ödeme sağlayıcısı seçilir. Oysa olayın merkezinde ne banka ne sağlayıcı vardır. Merkezde, siparişin ödeme onayı ile teslimat arasında geçen o birkaç saniyelik boşluğu kimsenin yönetmiyor olması vardır. E-pin işinde ürün geri alınamaz; gönderdiğin kod kullanıldıysa iade diye bir şey yoktur, sadece zarar vardır.
İşte bu yüzden ciddi hacimli satıcıların paneli, küçük bayilerin panelinden tek bir şeyle ayrılır: araya bir karar penceresi koymuş olmak. Doğru kurulmuş bir e-pin satış scripti her siparişi ikiye ayırır; temiz akış saniyeler içinde otomatik teslim edilir, riskli akış bir kuyruğa düşer ve orada insan kararı bekler. Bu yazıda o kuyruğun nasıl kurulduğunu, hangi sinyallere bakıldığını ve inceleme kararının kaç dakikada verilmesi gerektiğini kendi paneline uyarlayabileceğin netlikte anlatıyorum.
Çoğu Bayi "Şüpheli Sipariş" Sanıyor, Oysa Sen Bir Zaman Penceresi Yönetiyorsun
Şüpheli sipariş bir etiket değil, bir zamanlama problemidir. Fiziksel ürün satan bir mağazada kargo hazırlığı zaten sana yarım gün tampon verir; şüphelendiğinde paketi durdurursun. Dijital üründe o tampon yoktur, çünkü otomatik teslimat senin en büyük satış argümanındır. Müşteri "anında teslim" yazdığın için senden alıyor. Dolayısıyla çözüm teslimatı yavaşlatmak değil, siparişlerin küçük bir yüzdesini bilinçli olarak bekletmektir.
Burada kritik oran şudur: toplam siparişin yüzde üçünü inceleme kuyruğuna almak, dönüşümüne neredeyse hiç dokunmaz; ama itiraz kaybının çoğunu keser. Yüzde yirmisini kuyruğa alırsan hem ekibini boğar hem müşteriyi kaçırırsın. İyi bir dijital ürün satış scripti bu eşiği sabit bir kurala değil, senin kendi verine göre ayarlanabilir bir skora bağlar. Pinova'da kuyruk eşiği bu yüzden yönetici tarafından değiştirilebilir bir parametredir; çünkü 50 TL'lik oyun parası satan bir mağazanın riski, 4.000 TL'lik toplu lisans satan bir mağazanın riskiyle aynı değildir.
Manuel İnceleme Kuyruğu Neden Otomatik Redden Daha Kârlı?
Yeni başlayan satıcıların en pahalı hatası, riski gördüğü anda siparişi reddetmektir. Red, riski sıfırlar ama geliri de sıfırlar. Üstelik reddedilen siparişlerin büyük kısmı gerçek müşterilerdir: yurt dışından bağlanan bir öğrenci, iş yerinin VPN'inden alışveriş yapan bir çalışan, telefonunu yeni değiştirmiş bir düzenli alıcı. Bunları topluca kapıdan çevirdiğinde, dolandırıcılığın sana yaptığı zarardan daha fazlasını kendi elinle yaparsın.
Kuyruk mantığı bu ikilemi çözer. Sipariş ne onaylanmıştır ne reddedilmiştir; askıya alınmıştır ve müşteri bunu "Siparişin güvenlik kontrolünde, en geç 15 dakika içinde teslim edilecek" gibi net bir mesajla görür. Bu cümlenin dönüşüme etkisi şaşırtıcı derecede düşüktür, çünkü müşteri belirsizlikten değil sessizlikten kaçar. Aynı kuyruk sana ikinci bir kazanç daha verir: incelediğin her sipariş, bir sonraki kararını iyileştiren etiketli veri üretir. Altı ay sonra elinde, hangi sinyal bileşiminin gerçekten kayba dönüştüğünü gösteren kendi tarihçen olur.
Risk Skorunu Hangi Sinyaller Oluşturur? Panelde Görmediğin Katman
Risk skoru sihir değildir; ölçülebilir birkaç sinyalin ağırlıklı toplamıdır. Önemli olan sinyal sayısını artırmak değil, yanlış pozitif üretmeyen sinyalleri doğru ağırlıklamaktır. Tek başına "yeni üyelik" bir şey ifade etmez, herkes bir gün yeni üyeydi. Ama "yeni üyelik + ilk siparişte en pahalı ürün + adres ile kart ülkesinin uyuşmaması" üçlüsü ciddi bir uyarıdır.
Sinyalleri üç kümede düşün. Kimlik sinyalleri: e-posta yaşı, telefon doğrulaması, aynı cihazdan açılmış hesap sayısı. Davranış sinyalleri: sepete ekleme ile ödeme arasındaki süre, ödeme denemesi sayısı, kupon zorlaması. Ödeme sinyalleri: kart ülkesi, BIN tipi, aynı karttan farklı hesaplara yapılan ödeme. Aşağıdaki tablo, sık kullanılan sinyalleri hem ağırlık hem de yanlış alarm eğilimiyle birlikte veriyor; bu iki sütunu birlikte okumazsan iyi müşterileri eleyen bir sistem kurarsın.
| Risk sinyali | Skor ağırlığı | Yanlış pozitif eğilimi | Önerilen aksiyon |
|---|---|---|---|
| Aynı karttan 24 saatte 3+ farklı hesaba ödeme | Çok yüksek | Düşük | Doğrudan kuyruk + kart son 4 hane eşleştirme |
| Hesap yaşı < 10 dakika ve sepet en yüksek fiyat bandında | Yüksek | Orta | Kuyruk + telefon doğrulama isteği |
| Başarısız ödeme denemesi 4 ve üzeri | Yüksek | Düşük | Geçici ödeme kilidi (15 dk) |
| IP ülkesi ile fatura ülkesi farkı | Orta | Yüksek | Tek başına engellemez, skora eklenir |
| Tek oturumda çoklu cihaz parmak izi değişimi | Orta | Orta | Kuyruk, düşük tutarlıysa otomatik geç |
| E-posta alan adı tek kullanımlık servis | Orta | Düşük | Kayıt aşamasında uyarı + kuyruk etiketi |
| Sipariş saati 03:00-06:00 ve yüksek tutar | Düşük | Çok yüksek | Sadece destekleyici sinyal olarak kullan |
İtirazla sonuçlanan siparişlerde baskın sinyal dağılımı
- Kart–hesap uyuşmazlığı 45%
- Yeni hesap + yüksek tutar 25%
- Çoklu ödeme denemesi 20%
- Diğer / sınıflanamayan 10%
7 Dakikalık Karar Zinciri: Sipariş Beklemedeyken Neyi Sırayla Kontrol Ediyorsun?
İnceleme akışının en büyük düşmanı sezgidir. "Bana şüpheli geldi" ile karar veren bir ekip, iki farklı temsilcinin aynı siparişte zıt karar verdiği bir yapı üretir. Bunun panzehiri sıralı ve kısa bir zincirdir. Birinci dakika: müşterinin geçmiş sipariş sayısı ve iade geçmişi. İkinci dakika: kartın son dört hanesi ile hesaptaki kayıtlı bilgi eşleşmesi. Üçüncü dakika: aynı cihaz veya IP ile ilişkili başka hesaplar. Dördüncü dakika: tutarın müşterinin normal sepet ortalamasına oranı.
Beşinci dakikada müşteriyle temas kurulur; panelden gönderilen tek bir doğrulama mesajı, gerçek müşterinin saniyeler içinde cevapladığı ama kart sahibi olmayan kişinin cevaplamadığı bir filtredir. Altıncı ve yedinci dakikalar karar ve gerekçeli not içindir. Notun zorunlu olması şart; çünkü ay sonunda "neden bu sipariş teslim edilmiş" sorusunun cevabı yoksa akışın hiç yoktur. Bir e-pin satış yazılımı bu zinciri ekranın kendisine gömdüğünde temsilcinin hafızasına ihtiyaç kalmaz; alanlar önüne sırayla gelir.
İnceleme süresince ilgili kod rezerve edilmezse, aynı kodu başka bir müşteriye satma riski doğar. Rezervasyon süresi dolduğunda kod otomatik olarak havuza dönmeli ve bu hareket loga yazılmalı.
İnceleme Kararını Kim Verir? Rol, Log ve Geri Alınamaz Teslimat Sorunu
Manuel inceleme, yetki tasarımı olmadan kurulduğunda riski azaltmaz, sadece yerini değiştirir. Destek ekibindeki her kullanıcının "onayla ve teslim et" butonuna basabildiği bir panelde, en büyük tehdit dışarıdan değil içeriden gelir. Bu yüzden akışı iki yetkiye bölmek gerekir: inceleme yetkisi kanıt toplar ve öneri yazar, karar yetkisi belirli bir tutarın üzerinde onayı verir. Küçük ekipte bu ayrım tutar eşiğiyle yapılır; 1.000 TL altını temsilci kapatır, üstünü yönetici onaylar.
İkinci zorunluluk değiştirilemez log kaydıdır. Her onay, red, not ve müşteri mesajı; kullanıcı kimliği ve zaman damgasıyla birlikte saklanmalı ve silinemez olmalı. Bunun sebebi sadece iç denetim değil; bankaya itiraz dosyası sunarken elindeki tek kozun bu kayıtlar olması. "Kod şu saatte şu IP'den görüntülendi, müşteri şu mesajla doğrulandı" diyebilen satıcı itirazların önemli bir kısmını kazanır; diyemeyen satıcı hepsini kaybeder. Pinova'nın teslim ve inceleme kayıtlarını ayrı ayrı tutmasının nedeni tam olarak budur.
İnceleme Akışını Ölçmeden Yönetemezsin: Hangi Metrikler Panelde Durmalı?
Akışın kurulmuş olması yetmez, sağlıklı çalıştığını gösteren üç sayıya ihtiyacın var. Birincisi kuyruk oranı: toplam siparişin kaçı incelemeye düşüyor. Yüzde beşi geçiyorsa eşiğin çok hassastır. İkincisi onay oranı: kuyruğa düşenlerin kaçı sonunda teslim ediliyor. Bu sayı yüzde doksanın üzerindeyse, boşuna iyi müşteri bekletiyorsun; yüzde ellinin altındaysa trafiğinde ciddi bir kalite problemi var. Üçüncüsü ortalama karar süresi: on beş dakikayı aşan kuyruk, iptal talebine dönüşür.
Bu üç sayıyı haftalık okuyup eşikleri kaydırdığında, sistem kendi kendini kalibre eder hale gelir. Aşağıdaki kontrol listesini ilk kurulumda bir kez, sonra her çeyrekte tekrar geç; özellikle rezervasyon ve log maddeleri, büyüyen mağazalarda ilk bozulan halkalardır.
| Kontrol adımı | Sorumlu | Süre | Kanıt |
|---|---|---|---|
| Risk skoru eşiği tutar bandına göre ayarlandı | Yönetici | Kurulum | Ayar ekranı kaydı |
| Kuyruğa düşen siparişte kod rezerve ediliyor | Sistem | Otomatik | Stok hareket logu |
| Müşteriye beklemede bilgisi otomatik gidiyor | Sistem | < 30 sn | Bildirim logu |
| Karar zinciri 4 alan zorunlu doldurularak kapanıyor | Temsilci | 7 dk | İnceleme notu |
| Tutar eşiği üstü onay ikinci yetkiye düşüyor | Yönetici | Anlık | Yetki kaydı |
| Teslim sonrası kod görüntüleme zamanı saklanıyor | Sistem | Otomatik | Teslim logu |
| Haftalık kuyruk/onay/süre raporu okundu | Yönetici | Haftalık | Rapor ekranı |
İnceleme akışını sıfırdan kurmak zorunda değilsin
Risk skoru, inceleme kuyruğu, kod rezervasyonu ve değiştirilemez teslim logu; Pinova'da hazır gelen ve panelden ayarlanan parçalardır. Özellik listesini ve lisans paketlerini incele.
Manuel inceleme müşteri kaybına yol açmaz mı?
Toplam siparişin yüzde üç ila beşini kapsayan ve on beş dakikayı aşmayan bir kuyruk, dönüşümde ölçülebilir bir düşüş yaratmaz. Kayıp, bekletmeden değil müşteriye hiçbir açıklama yapmamaktan doğar; beklemede bildirimi otomatik gittiğinde iptal talepleri belirgin şekilde azalır.
Risk skorunu kendim mi ayarlamalıyım, hazır eşik yeterli mi?
Hazır eşikle başla, ilk ay verini topla, sonra kendi tutar bandına göre kaydır. 50 TL ortalama sepetli bir mağaza ile 2.000 TL ortalama sepetli bir mağazanın aynı eşikle çalışması mantıksızdır. Önemli olan eşiğin panelden değiştirilebilir olmasıdır.
Kuyrukta bekleyen sipariş için kodu ayırmak şart mı?
Evet. Rezervasyon yoksa aynı kod ikinci bir müşteriye satılabilir ve bu, dolandırıcılıktan daha hızlı itibar kaybettiren bir hatadır. Rezervasyon süresi dolduğunda kodun otomatik olarak havuza dönmesi ve bu hareketin loglanması gerekir.
Banka itirazında hangi kayıtlar işe yarıyor?
Ödeme onayı, teslim zamanı, kodun ilk görüntülenme zamanı ve IP'si, müşteriyle yapılan doğrulama yazışması ve inceleme notu. Bu beş kaydı zaman damgalı sunabilen satıcı itirazların ciddi bir kısmını kazanır; sunamayan satıcı savunmasızdır.
Şüpheli sipariş yönetimi, sonradan eklenen bir eklenti değil; e-pin işinin omurgasıdır. Bugün elle takip ettiğin her kontrolü yarın hacim ikiye katlandığında elle yapamayacaksın, çünkü karar süresi büyürken hata payı da büyür. Akışın panelin içinde, ekranın akışına gömülü olarak gelmesi bu yüzden bir konfor değil zorunluluktur. Risk skorunun, inceleme kuyruğunun ve teslim logunun gerçek bir panelde nasıl göründüğünü kendi gözünle görmek istiyorsan canlı demo üzerinden bir test siparişi geçir; kararı sen ver, sistemin arkada ne kaydettiğine bak.