Çoğu satıcı bu sorunu "müşteri bakamıyor, yönlendirme yapayım" diye kapatır. Oysa "sipariş onaylandı ama kod görünmüyor" tablosu neredeyse hiç kullanıcı hatası değildir. Ödeme tamamlanmış, sipariş kaydı oluşmuş, stok düşülmüş, hatta bazen e-posta bile gitmiştir; ama panelde kodun görüntülendiği o tek alan boş döner. Müşteri açısından bu, parasını verip hiçbir şey almamaktır ve destek kutusuna düşen mesajın tonu da buna göre olur.
Teknik tarafta durum daha can sıkıcıdır: sipariş "başarılı" göründüğü için hangi halkanın koptuğunu bilmezsin. Teslimat zinciri en az altı adımdan oluşur ve her adımın kendi hata modu vardır. Sağlam bir e-pin satış scripti bu adımların her birini ayrı ayrı damgalar; zayıf bir epin yazılım kurulumu ise yalnızca "sipariş durumu: tamamlandı" yazar ve gerisini sana bırakır. Aşağıda zinciri halka halka açıyorum, her halka için tek satırlık tanı yöntemi veriyorum.
Sipariş "tamamlandı" yazıyorsa teslimat gerçekten olmuş mudur?
Hayır, ve bu ikisini aynı şey saymak en yaygın tasarım hatası. Birçok kurulumda sipariş durumu ödeme sağlayıcısının geri dönüşüne göre yazılır. Ödeme başarılıysa durum "tamamlandı" olur. Ama kodun stoktan alınıp siparişe bağlanması, ödeme onayından sonra çalışan ayrı bir işlemdir. O işlem hata verirse sipariş yine "tamamlandı" kalır, çünkü durumu yazan kod zaten geçmiştir.
Doğru model iki ayrı durum alanı tutar: ödeme durumu ve teslimat durumu. Müşteriye gösterilen mesaj teslimat durumundan beslenir. Teslimat "bekliyor" ise müşteri "kodun hazırlanıyor" görür, "hata" ise otomatik olarak destek kaydı açılır ve sen bunu müşteriden önce öğrenirsin. Bu tek ayrım, gelen bilet sayısını gözle görülür biçimde düşürür. Pinova'da teslimat durumu bağımsız bir yaşam döngüsüne sahiptir; özellikler sayfasında teslimat zincirinin şemasını bulabilirsin.
Stok kilitlenmesi neden en sık kırılan halka?
İki müşteri aynı saniyede son iki kodu satın aldığında ne olacağını düşün. Eğer kod ayırma işlemi kilit kullanmıyorsa, iki sipariş aynı kodu alır ya da ikisi de boş döner. Yüksek trafikli kampanya saatlerinde bu senaryo istisna değil, kuraldır. Belirtisi çok tanıdıktır: gün içinde tek tük, kampanya saatinde onlarca "kod gelmedi" bileti.
Çözüm, kod ayırmayı veritabanı düzeyinde tek işlem haline getirmektir: kodu seç, aynı sorguda "satıldı" işaretle, sipariş numarasını yaz. Üç adım ayrı ayrı çalışırsa arada boşluk kalır ve o boşluğa başka bir istek girer. Ayrıca stok tükendiğinde sipariş hiç oluşmamalı; ödeme alıp "stok yok" demek, iade süreci ve itibar kaybı demektir. İyi bir dijital ürün satış yazılımı ödeme başlatmadan önce kodu rezerve eder ve rezervasyona süre koyar.
| Halka | Tipik hata | Müşterinin gördüğü | Tanı yöntemi |
|---|---|---|---|
| Ödeme geri dönüşü | Bildirim gecikmesi | Sipariş bekliyor | Sağlayıcı bildirim logu |
| Stok rezervasyonu | Kilit yok, yarış durumu | Kod alanı boş | Aynı koda iki sipariş sorgusu |
| Teslimat kaydı | Kayıt hiç oluşmamış | Tamamlandı ama boş | Teslimat tablosunda sipariş arama |
| Şifreleme katmanı | Anahtar değişmiş | Bozuk karakterler | Çözme denemesi hata logu |
| Görüntüleme yetkisi | Oturum eşleşmemesi | Yetkisiz erişim uyarısı | Sipariş sahibi kimlik karşılaştırması |
| E-posta bildirimi | Gönderim reddi | Hiçbir bildirim yok | Posta kuyruğu ve SPF kaydı |
Şifreleme anahtarını değiştirdiğinde eski kodlar ne olur?
Bu, taşınma sonrası en çok gelen sorunun kaynağıdır. Kodlar veritabanında şifreli tutulur ve şifreleme anahtarı yapılandırma dosyasında durur. Sunucu değiştirdiğinde, yapılandırmayı sıfırdan oluşturduğunda ya da birisi "güvenlik için" anahtarı yenilediğinde eski kayıtlar çözülemez hale gelir. Panelde kod alanı boş kalır veya anlamsız karakterler görünür. Sistem hata vermez, çünkü çözme işlemi sessizce başarısız olur.
Korunma yolu üç maddeli: anahtarı asla kod deposuna koymamak, anahtar değişimini çift anahtar dönemi ile yapmak (yeni kayıtlar yeni anahtarla yazılır, eski kayıtlar eski anahtarla çözülür), ve çözme hatasını sessiz geçmeyip loga yazmak. Üçüncü madde olmadan ilk ikisinin işe yarayıp yaramadığını asla anlayamazsın. Yedekten dönerken de yalnızca veritabanını değil, anahtar dosyasını da aynı tarihten almalısın.
"Kod göremiyorum" biletlerinin gerçek nedenleri
- Teslimat kaydı oluşmamış 40%
- Stok ve yarış durumu 30%
- Şifreleme ve anahtar 20%
- Oturum ve yetki 10%
Müşteri doğru siparişe bakıyor ama neden yetkisi yok?
Bu senaryo özellikle misafir alışverişi açık olan sitelerde görülür. Müşteri üye olmadan satın alır, sipariş kaydı bir e-posta adresine bağlanır. Sonra üye olur, ama sipariş eski misafir kaydında kaldığı için panelinde görünmez. Ya da tam tersi: farklı bir e-posta ile üye olduğu için sistem iki ayrı kişi olduğunu düşünür.
İkinci yaygın neden oturum çerezinin alan adı kapsamıdır. Ödeme sağlayıcısından dönüşte müşteri www'lu adrese, satın alırken www'suz adrese gelmişse oturum kaybolur ve sistem onu misafir sanar. Çözüm hem tek kanonik alan adına yönlendirme yapmak hem de siparişi e-posta üzerinden otomatik eşleştirmek: aynı e-postaya ait misafir siparişleri, kullanıcı üye olduğunda hesabına bağlanır. Bir de "sipariş numarası + e-posta" ile giriş gerektirmeyen sorgulama ekranı koy; biletlerin önemli kısmı oraya düşer ve kendiliğinden çözülür.
Şikâyet gelen sipariş numarasını al ve teslimat tablosunda ara. Kayıt yoksa sorun stok/teslimat halkasında, kayıt varsa ama içerik bozuksa şifreleme anahtarında, kayıt sağlamsa sorun görüntüleme yetkisindedir. Üç dalın üçü farklı çözüm ister; bu sorguyu atlayıp tahmin yürütmek saat kaybettirir.
Bu sorunu bir daha yaşamamak için hangi izleri tutmalısın?
Tanı süresini dakikalara indiren şey zekâ değil, kayıt disiplinidir. Her teslimat denemesi için şu alanları yazan bir izleme tablosu tut: sipariş numarası, ürün, denenen kod kimliği, sonuç, hata mesajı, zaman damgası, işlemi yapan kaynak (web, API, personel). Bu tablo varsa müşteri şikâyet ettiğinde cevabın hazır olur; yoksa her olayı yeniden araştırırsın.
İkinci disiplin proaktif alarm. Teslimat durumu "hata" olan bir kayıt oluştuğunda sana anında bildirim gitsin. Müşteriden önce haber almak, o siparişi beş dakikada düzeltip "fark ettik, düzelttik" mesajı atmanı sağlar ve bu mesaj çoğu zaman olumsuz yorumu olumluya çevirir. Aşağıdaki kontrol listesi, yeni bir kurulumu canlıya almadan önce doğrulaman gerekenleri içeriyor.
| Kontrol | Beklenen sonuç | Ne zaman | Öncelik |
|---|---|---|---|
| Ödeme ve teslimat durumu ayrı mı | İki bağımsız alan | Kurulumda | Kritik |
| Kod ayırma tek işlem mi | Aynı kod iki siparişe düşmüyor | Kurulumda | Kritik |
| Stok yokken ödeme engelli mi | Sepette uyarı, ödeme başlamıyor | Kurulumda | Kritik |
| Şifreleme anahtarı yedekli mi | Ayrı ve tarihli yedek mevcut | Haftalık | Kritik |
| Çözme hatası loglanıyor mu | Sessiz hata yok | Kurulumda | Yüksek |
| Misafir siparişi eşleşiyor mu | Üyelikte otomatik bağlanıyor | Kurulumda | Yüksek |
| Kanonik alan adı zorlanıyor mu | Tek adrese yönlendirme | Kurulumda | Yüksek |
| Teslimat hatası alarmı var mı | Anında bildirim gidiyor | Aylık test | Yüksek |
| Numara+e-posta sorgu ekranı | Girişsiz erişilebilir | Kurulumda | Orta |
Teslimat zincirini şeffaf hale getir
Pinova'da her teslimat denemesi ayrı kayıt olur, hata durumunda sipariş otomatik işaretlenir ve sana bildirim gider. Müşteri "kod gelmedi" yazmadan önce sen düzeltmiş olursun.
Sipariş tamamlandı görünüyor ama kod yok, parayı iade mi etmeliyim?
Önce teslimat tablosunu kontrol et. Stok varsa kodu elle atayıp müşteriye bildir; bu, iadeden hem hızlı hem itibar açısından iyidir. Stok gerçekten yoksa iade doğru karardır ve gecikmeden yapılmalı.
Şifreleme anahtarını kaybettim, kodlar kurtarılabilir mi?
Anahtar olmadan şifreli veriyi çözmek mümkün değildir. Tek yol tedarikçiden kod listesini yeniden istemek. Bu yüzden anahtar yedeği veritabanı yedeğinden ayrı ve en az iki yerde tutulmalı.
Misafir alışverişini tamamen kapatsam sorun biter mi?
Yetki kaynaklı biletler azalır ama dönüşüm oranı da düşer. Daha iyi yol, misafir alışverişini açık tutup siparişi e-posta üzerinden otomatik eşleştirmek ve numara ile sorgulama ekranı sunmak.
Kampanya saatlerinde artan hataları nasıl önlerim?
Kod ayırmayı tek veritabanı işlemine indir, stok eşiği dolduğunda ürünü otomatik pasife al ve ödeme öncesi rezervasyon uygula. Bu üçü yarış durumu kaynaklı hataların neredeyse tamamını kapatır.
Teslimat, e-pin işinde müşterinin senden aldığı tek somut şeydir; o halka koptuğunda geri kalan her şey anlamsızlaşır. Bugün son 30 günün siparişlerinde teslimat kaydı olmayan satırları listele, çıkan sayı sandığından yüksek olacak. Teslimat durumu, deneme kaydı ve hata alarmının nasıl birlikte çalıştığını görmek için canlı demo üzerinden bir test siparişi oluştur, kodu bilerek stoktan düşür ve sistemin sana ne söylediğine bak; iyi bir panelin farkı tam olarak orada başlıyor. Ölçekleme planların için fiyat sayfasına da göz atabilirsin.