"Kod kayboldu" cümlesi teknik olarak neredeyse hiç doğru olmaz. Bir e-pin scripti içinde kod, veritabanında bir satırdır; satır kendi kendine buharlaşmaz. Müşteri kodu göremiyorsa iki şeyden biri olmuştur: kod hiç üretilmemiştir ya da üretilmiş olan kod sipariş sahibine devredilmemiştir. İkisi arasındaki fark, senin bir saatini mi yoksa bir gününü mü harcayacağını belirler.
Çoğu satıcı bu noktada paniğe kapılıp stok tablosuna elle müdahale eder, aynı kodu kopyalayıp WhatsApp'tan gönderir, sonra kayıtlar birbirine karışır. Oysa teslimat bir mesaj gönderme işi değil, bir devir işlemidir: kod havuzdan çıkar, bir siparişe bağlanır, bir zaman damgası alır ve artık başka hiçbir siparişe verilemez hale gelir. Bu zincirin hangi halkasının koptuğunu bulmak için sırayla bakmak gerekir. Aşağıda o sırayı, gerçek satıcı panellerinde en sık gördüğüm hata sıklığına göre dizdim.
Teslim Edilmeyen Kod Gerçekten "Kaybolmuş" mudur?
Bir siparişin teslimat aşaması üç ayrı kayıt üretmelidir: hangi stok satırının seçildiği, o satırın hangi siparişe bağlandığı ve müşteriye hangi kanaldan hangi saniyede gösterildiği. Bu üç kaydı ayrı ayrı tutmayan bir epin yazılım kurulumunda "teslim edilmedi" iddiasını çürütecek hiçbir kanıtın olmaz. Sen de müşterinin ekran görüntüsüne karşı savunmasız kalırsın.
Teşhise her zaman şu soruyla başla: sipariş kaydında bir stok satırı numarası var mı? Varsa kod üretilmiş ve bağlanmış demektir; sorun gösterim veya bildirim katmanındadır. Yoksa devir hiç gerçekleşmemiştir ve sorun daha yukarıda, stok ya da tedarikçi tarafındadır. Bu ayrımı tek bakışta yapabildiğin gün, teslimat şikayetlerinin yarısı zaten çözülmüş olur. Yapamadığın sürece her şikayet baştan araştırma gerektirir.
Stok Havuzu Boşsa Script Sana Neden Söylemez?
Panelde ürünün yanında bir sayı görürsün ve içiniz rahat eder. Ama o sayının neyi saydığı kritiktir. Bazı kurulumlar havuzdaki tüm satırları sayar: satılmışları, rezerve edilmişleri, süresi geçmişleri. Gerçekte teslim edilebilir satır sıfır olsa bile ekranda "48 adet" yazabilir. Sipariş geldiğinde sistem uygun satır bulamaz, teslimatı atlar, siparişi ödendi durumunda bırakır.
Doğru davranış şudur: stok sayacı yalnızca serbest ve geçerli satırları saymalı, kritik eşiğin altına düştüğünde sana haber vermeli, sıfıra indiğinde ürünü satışa kapatmalı. Bu üç davranışı yapan bir dijital ürün satış scripti teslim edilemeyen sipariş üretmez; çünkü teslim edemeyeceği ürünü hiç satmaz. Satıcıların büyük kısmı bu ayarı "satış kaçmasın" diye kapatır ve sonra teslim edemediği siparişlerin iadesiyle uğraşır. Kaçırılan satış, kırılan güvenden her zaman ucuzdur.
| Zincirin Halkası | Koptuğunda Görünen | Kanıt Kaydı | Müdahale |
|---|---|---|---|
| Stok havuzu | Ödendi ama teslimat satırı yok | Serbest satır sayacı | Yükleme + satışa kapatma |
| Tedarikçi çağrısı | Yanıt başarılı, kod alanı boş | Ham istek/yanıt logu | Gövde doğrulaması ekle |
| Devir işlemi | Kod var, siparişe bağlı değil | Sipariş-stok eşleşmesi | İşlemi tek blokta çalıştır |
| Gösterim katmanı | Bağlandı ama ekranda yok | Sipariş detay erişim logu | Şablon/yetki düzeltmesi |
| Bildirim kanalı | Ekranda var, e-posta gelmedi | Giden posta kuyruğu | SMTP + alternatif kanal |
Teslimat Bir E-posta İşi Değil, Bir Devir İşlemidir
Satıcıların en yaygın yanlış varsayımı, teslimatı e-posta göndermekle eşitlemektir. E-posta bir bildirim kanalıdır ve en kırılgan olanıdır: spam klasörüne düşer, sunucun karalisteye girer, müşteri adresini yanlış yazar. Teslimatı e-postaya bağlayan kurulumda posta gitmediğinde sipariş teslim edilmemiş sayılır ve kod havuza geri dönmez. Sonuç: hem müşteri kodsuz kalır hem stok eksilir.
Doğru mimaride asıl teslimat noktası müşterinin sipariş detay sayfasıdır. Kod orada, hesabına bağlı olarak, her zaman erişilebilir durur. E-posta, SMS veya anlık bildirim ise bunun üstüne eklenen kolaylık kanallarıdır. Bu ayrımı yapan bir e-pin satış yazılımı, posta sunucusu çöktüğünde bile teslimatı sürdürür. Ayrıca müşteri "gelmedi" dediğinde ona silinmiş bir postayı değil, kalıcı bir bağlantıyı gösterirsin. Bu tek tasarım kararı, destek yükünü tek başına belirgin biçimde düşürür.
Teslim Edilmeyen Siparişlerin Dağılımı
- Boş veya yanlış sayılan stok 40%
- Tedarikçi yanıtı eksik/boş 30%
- Devir işlemi yarım kaldı 20%
- Bildirim kanalı arızası 10%
Tedarikçi API'si 200 Döndürüp Boş Gövde Gönderdiğinde
Otomatik tedarik kullanıyorsan bu, en sinsi arıza biçimidir. HTTP durum kodu 200 gelir, senin kodun "başarılı" der, ama yanıt gövdesindeki kod alanı boştur veya bir hata metni taşır. Durum koduna bakıp gövdeyi doğrulamayan her kurulum, bu senaryoda siparişi teslim edilmiş sayar ve müşteriye boş bir alan gösterir. Daha kötüsü, stok satırını da tüketilmiş işaretler.
Kural net olmalı: bir tedarik yanıtı, kod alanı beklenen desene uyuyorsa başarılı sayılır. Uzunluk, karakter kümesi, ön ek kontrolü gibi basit doğrulamalar bu hatanın neredeyse tamamını yakalar. Doğrulama başarısızsa sipariş teslim edilmiş sayılmamalı, satır tüketilmemeli ve olay ham istek-yanıt çiftiyle birlikte kaydedilmelidir. Böylece tedarikçiyle konuşurken elinde tahmin değil kanıt olur. Otomatik tedariki ham log tutmadan kullanmak, gözü kapalı ticaret yapmaktır.
Tedarikçi entegrasyonunda başarı ölçütünü HTTP 200 yapmayı bırak. Kod alanının beklenen uzunluk ve karakter desenine uyup uymadığını kontrol et; uymuyorsa siparişi teslim etmiş sayma ve stok satırını serbest bırak.
Müşteri "Gelmedi" Diyor: Kim Haklı, Log mu Ekran Görüntüsü mü?
Dijital ürün satışında ihtilafın tamamı kanıt üzerinden çözülür. Müşterinin elinde boş bir ekran görüntüsü vardır; senin elinde ne var? Eğer cevabın "panelde satılmış görünüyor" ise elinde hiçbir şey yok demektir. Çünkü "satılmış" ifadesi kodun kime, ne zaman, hangi oturumdan gösterildiğini söylemez.
Sağlam bir kurulum şu üç kaydı tutar: kodun siparişe bağlandığı an, müşterinin sipariş detayını ilk açtığı an ve kodu kopyaladığı ya da görüntülediği an. Bu üç zaman damgası varsa tartışma otuz saniyede biter. Yoksa hem parayı hem kodu hem itibarı kaybetme riskin var. Üstelik bu kayıtların ağır bir altyapı gerektirdiği doğru değil; sıradan bir dijital ürün satış yazılımı için birkaç ek satır yeter. Mesele kapasite değil, en başta bunu düşünmüş olmaktır.
| Kontrol | Doğru Ayar | Yanlış Yapılınca | Öncelik |
|---|---|---|---|
| Stok sayacı tanımı | Yalnızca serbest ve geçerli satır | Satılamayacak ürün satışta kalır | Yüksek |
| Sıfır stokta davranış | Ürünü otomatik satışa kapat | Teslim edilemeyen sipariş | Yüksek |
| Tedarik yanıt doğrulaması | Gövde deseni kontrolü | Boş kod teslim edilmiş sayılır | Yüksek |
| Devir işlemi bütünlüğü | Tek blokta, yarım kalmaz | Kod bağlanmadan tüketilir | Yüksek |
| Kalıcı teslim noktası | Sipariş detay sayfası | Posta gitmezse teslimat yok | Orta |
| Görüntüleme kaydı | Zaman damgalı erişim logu | İhtilafta kanıtsız kalırsın | Orta |
Pinova'da Teslimat Zincirini Nasıl Kırılmaz Yaparsın?
Pinova e-pin satan bir dükkan değil; e-pin satan işletmelerin kurduğu satış yönetim yazılımıdır. Bu yüzden teslimat tarafında tek bir ilke üzerine kurulmuştur: bir kod ancak bir siparişe bağlandığı anda tüketilmiş sayılır, ve bu bağ her zaman geriye dönük okunabilir. Yarım kalan bir devir işlemi stok satırını yakmaz; doğrulanamayan bir tedarik yanıtı siparişi teslim edilmiş göstermez.
Panel tarafında bunun karşılığı, her sipariş için tek ekranda görünen bir teslimat geçmişidir: hangi satır seçildi, hangi saniyede bağlandı, müşteri hangi kanaldan ne zaman erişti. Stok kritik eşiğe düştüğünde ürün kendini satışa kapatır, sen haber alırsın. "Kod teslim edilmiyor" şikayeti böylece bir araştırma konusu olmaktan çıkıp tek bakışta yanıtlanan bir soruya dönüşür. Akışın ayrıntılarını özellikler bölümünde, paket kapsamlarını fiyat bölümünde görebilirsin.
Teslimat şikayetini araştırma değil, tek bakışta cevap yap
Pinova her kodu siparişe bağlar, her erişimi zaman damgasıyla kaydeder. Kanıtı olan satıcı tartışmaz.
Kod teslim edilmedi diyen müşteriye elle kod göndersem olur mu?
Olur ama mutlaka panel üzerinden yap ki devir kaydı oluşsun. WhatsApp'tan kopyalayıp göndermek stok bütünlüğünü bozar ve aynı kodun ikinci kez satılmasına zemin hazırlar.
Stokta ürün göründüğü halde teslimat neden olmuyor?
Çünkü sayaç büyük olasılıkla rezerve, satılmış veya süresi geçmiş satırları da sayıyor. Sayacı yalnızca serbest ve geçerli satırları sayacak şekilde düzeltmek gerekir.
Otomatik tedarikte hangi durumda siparişi başarısız saymalıyım?
Yanıt gövdesindeki kod alanı beklenen desene uymuyorsa. HTTP 200 tek başına yeterli kanıt değildir; boş gövde de 200 ile gelebilir.
E-posta yerine hangi teslim kanalı daha güvenli?
Müşterinin hesabına bağlı kalıcı sipariş detay sayfası. E-posta, SMS ve anlık bildirim bunun üstüne eklenen ikincil kanallar olmalı, asıl teslimat noktası olmamalı.
Teslimat, dijital ürün satışında müşterinin sana verdiği güvenin tek somut karşılığıdır; o an eksik kalırsa geri kalan her şey anlamsızlaşır. Zinciri sağlamlaştırmak için gereken ne pahalı bir sunucu ne de büyük bir ekip; sadece her adımı kaydeden, doğrulamayı gövde üzerinden yapan ve kodu ancak gerçekten bağladığında tüketen bir altyapı. Pinova'nın teslimat geçmişini, stok kilidi davranışını ve tedarik doğrulamasını test siparişleriyle denemek için canlı demo ortamına girip aynı senaryoları kendi elinle kurgulayabilir, sonucu görünce kurulum sayfasına geçebilirsin.