Epin Yazılımı Ödeme Zaman Aşımı Yönetimi: Stokunu Kilitleyip Satışını Öldüren O Görünmez Sayaç Hakkında Kimse Konuşmuyor

Çoğu satıcı, bekleyen siparişlerin zararsız olduğunu düşünür. "Müşteri ödemedi, sipariş orada durur, ne olacak ki?" Ama e-pin gibi adet bazlı ve anlık teslim edilen bir üründe her bekleyen sipariş, aslında rafından çekilmiş bir koddur. Kampanya saatinde otuz kişi sepeti ödemeye götürüp yarısı vazgeçtiğinde, elinde stok olmasına rağmen sitende "tükendi" yazısı görünür. Satış kaybı, hiç fark etmediğin bir sayaçtan doğar.

Diğer taraf da bir o kadar riskli: süreyi çok kısa tutan sistemler, banka transferiyle ya da havale ile ödeyen müşterinin siparişini o ödeme gelmeden iptal eder. Sonra bildirim ulaşır, sipariş yoktur, para ortada kalır. İyi kurulmuş bir e-pin satış yazılımı bu iki uç arasında ince bir denge kurar ve bu dengeyi rastgele seçilmiş bir sayıyla değil, ödeme yöntemine göre değişen kurallarla yönetir. Bu yazıda o kuralları tek tek çıkaracağız.

Zaman aşımı tek bir sayı mı? Ödeme yöntemine göre neden farklı olmalı?

Tek bir süre değeriyle tüm ödeme yöntemlerini yönetmek, en yaygın ve en pahalı basitleştirmedir. Kartlı ödemede müşteri işlemi ya iki dakikada bitirir ya da hiç bitirmez; on beş dakika sonra o siparişin dönme olasılığı neredeyse sıfırdır. Havale ve EFT'de ise mesai, hafta sonu ve banka kesinti saatleri araya girer; on beş dakikalık bir sayaç burada doğrudan müşteri kaybıdır.

Doğru kurgu, süreyi ödeme yöntemi tanımının bir alanı yapmaktır. Kart için kısa, cüzdan ve anlık havale için orta, manuel havale için uzun. Üstüne bir de ürün bazlı istisna koyabilmen işe yarar: çok kıt bir kodun bekleme süresi, bol stoklu bir üründen daha kısa olmalıdır. Bir e-pin scripti içinde bu ayarların yönetim panelinden değiştirilebilir olması, sonradan kod dosyası açmaktan kurtarır.

Stoğu ne zaman düşmelisin? Rezervasyon ile satışın farkı

Burada üç yaklaşım var ve hangisini seçtiğin işletmenin karakterini belirler. Birincisi, stoğu sipariş oluşurken düşmek: müşteri kaybı olmaz ama vazgeçenler stoğunu kilitler. İkincisi, stoğu sadece ödeme onaylandığında düşmek: kilitlenme olmaz ama aynı son kodu iki müşteriye satma riski doğar. Üçüncüsü, doğru olanı: rezervasyon.

Rezervasyonda kod stoktan çıkmaz, "ayrılmış" işaretlenir ve hangi siparişe hangi saate kadar ayrıldığı yazılır. Satılabilir adet hesabı "toplam eksi ayrılmış" olur. Süre dolduğunda işaret kalkar, kod yine satışa açılır. Ödeme onaylandığında rezervasyon satışa dönüşür. Bu yapı hem çift satışı hem de gereksiz kilitlenmeyi aynı anda önler; ciddi bir dijital ürün satış scripti stok defterini bu üç durumla tutar: serbest, ayrılmış, satılmış.

Süreyi kim sayıyor? Sayfayı kapatan müşteri sayacı durdurmaz

Sıkça karşılaştığım bir hata, geri sayımı yalnızca tarayıcıda göstermek ve iptal işini de oraya bırakmaktır. Müşteri sekmeyi kapatırsa sipariş sonsuza kadar beklemede kalır. Sayaç mutlaka sunucu tarafında, sipariş kaydındaki bir bitiş zamanı alanı üzerinden tutulmalı ve düzenli çalışan bir arka plan görevi süresi geçenleri toplamalıdır.

Bu arka plan görevini de körlemeden yazmamak lazım. Her koşuda sınırlı sayıda sipariş al, her birini kilitleyerek işle, iptal ederken rezervasyonu serbest bırak ve ne yaptığını kayda geç. Görevin kendisi de izlenmeli: son çalışma zamanı panelde görünmüyorsa, bir gün sessizce durduğunda bunu ancak stok tükendiğinde anlarsın. Pinova gibi kurulumlarda bu görevin sağlık durumu yönetim ekranında bir satır olarak durur; özellikler sayfasında otomasyon başlığına bakabilirsin.

Sipariş iptal edildikten sonra ödeme gelirse ne yapacaksın?

Bu senaryo istisna değil, rutindir. Sayaç doldu, sipariş kapandı, rezerv serbest kaldı ve tam o sırada sağlayıcıdan "tahsil edildi" bildirimi ulaştı. Bildirimi görmezden gelmek en kötü seçenektir: müşterinin parası alınmış, karşılığı verilmemiş olur ve bu hem itiraz hem itibar kaybıdır.

Uygulanabilir kural şudur: geç gelen tahsilat asla reddedilmez, ödeme kaydı her zaman işlenir. Ardından üç yol açılır. Stok hâlâ varsa sipariş yeniden canlandırılır ve teslim yapılır. Stok yoksa tutar müşterinin site bakiyesine yazılır ve kendisine bildirilir. Müşteri bakiye istemiyorsa iade süreci başlatılır. Üç yolun hepsi kayıt bırakır, hiçbirinde para havada kalmaz. Bu akışı desteklemeyen bir epin yazılım kurgusu seni her hafta elle düzeltmeye mahkûm eder.

Müşteriyi süre boyunca yönetmek: sessizlik dönüşümü düşürür

Zaman aşımı yönetimi yalnızca teknik bir konu değil; doğrudan dönüşüm oranıyla ilgilidir. Müşteriye kalan süreyi göstermek, havale yönteminde ödeme bilgilerini net vermek ve süre dolmadan bir hatırlatma göndermek, terk edilen siparişlerin kayda değer bir kısmını geri getirir. Özellikle manuel havalede, sipariş numarasını açıklama alanına yazma talimatının net görünmesi eşleştirme sorunlarını da azaltır.

Süre dolduğunda gönderilen bilgilendirme de kritik: "siparişin iptal edildi" demekle kalmayıp aynı sepeti tek tıkla yeniden oluşturan bir bağlantı sunmak, müşterinin ikinci denemesini kolaylaştırır. Burada ölçmen gereken metrik şudur: süre aşımına uğrayan siparişlerin yüzde kaçı 24 saat içinde yeniden sipariş oluyor? Bu oran yükselmiyorsa ya süre yanlıştır ya da ödeme akışında müşteriyi kaybettiğin bir adım vardır.

Kendi sistemini test et: yedi maddede zaman aşımı denetimi

Aşağıdaki listeyi gerçek siparişlerle dene. Test ortamında değil, canlıda küçük tutarlarla; çünkü zaman aşımı hataları neredeyse her zaman gerçek koşullarda ortaya çıkar.

Zaman aşımı yönetimi, dışarıdan bakınca küçük bir ayar gibi durur ama stok doluluğundan müşteri memnuniyetine kadar her şeyi belirler. Bu ayarların panelde nasıl göründüğünü, rezervasyonun ve otomatik iptalin gerçek verilerle nasıl çalıştığını görmek için canlı demo üzerinden bir sipariş açıp süreyi kendin doldurabilir, sonra fiyat bölümünden işine uygun paketi belirleyebilirsin.