Çoğu satıcı ön sipariş kodunu sıradan bir e-pin gibi görür. Stok açar, fiyat yazar, satışa koyar ve "kod elimde, sorun yok" der. Oysa ön sipariş kodunun asıl ürünü kodun kendisi değildir; kodun teslim edildiği andır. Müşteri parayı oyunun çıkış gecesinde elinde bir şey olsun diye öder. Sen kodu iki saat geç gönderdiğinde satmadığın şey koddur, güvendir.
İşin sessiz tarafı şu: ön siparişte iade oranları normal satışların kat kat üstünde çıkar ve sebebi neredeyse hiç "kod çalışmadı" değildir. Sebep "ne zaman geleceğini bilmiyordum" cümlesidir. Bu yüzden ön sipariş satışı bir stok meselesi değil, bir zamanlama mimarisi meselesidir. Doğru kurulmuş bir e-pin satış scripti bu mimariyi senin yerine kurar; kurmayan bir panel ise sana her çıkış haftasında fatura yazar.
Ön sipariş kodu gerçekten "stokta" mı, yoksa sen öyle mi sanıyorsun?
Ön siparişte üç farklı stok durumu vardır ve çoğu satıcı bunları tek kutuya atar. Birincisi elinde fiziken duran, hemen gönderilebilir kod. İkincisi tedarikçinin sana taahhüt ettiği ama henüz üretilmemiş kod. Üçüncüsü ise elinde duran ama sözleşme gereği belirli bir tarihten önce paylaşamayacağın embargolu kod. Üçü de panelde "1 adet stok" olarak görünürse, sattığın anda hangi taahhüdü verdiğini sen de bilmiyorsun demektir.
Bu ayrımı yapmayan bir dijital ürün satış yazılımı seni kaçınılmaz olarak yanlış vaade sürükler. Ürün kartında "anında teslim" ibaresi duruyorsa ve arkada embargolu bir kod varsa, müşteri ödeme yaptığı saniyede haklı bir talep doğar. Panelin ürün seviyesinde teslim tipi ayırmalı: anında, zamanlanmış, manuel onaylı. Pinova'da bu üç mod aynı katalogda yan yana yaşayabilir; her ürün kendi teslim kuralını taşır ve sayfa metni o kurala göre otomatik değişir.
Pratikte yapılacak ilk iş şudur: elindeki her ön sipariş SKU'suna bir serbest bırakma damgası yaz. O damga yoksa ürünü yayına alma. Bu tek disiplin, çıkış haftasındaki destek yükünün yarısını siler.
| Teslim modu | Ne zaman kullanılır | Müşteriye gösterilen mesaj | Tipik iade oranı |
|---|---|---|---|
| Anında havuzdan | Kod elde, embargo yok | Ödeme sonrası saniyeler içinde | %1–2 |
| Zamanlanmış (embargo) | Kod elde, tarih kilidi var | 12 Eylül 02:00'de e-postana düşer | %3–5 |
| Tedarik bekleyen | Kod tedarikçide, taahhüt var | Çıkıştan en geç 24 saat önce | %7–11 |
| Manuel onaylı | Yüksek tutar, risk kontrolü | Doğrulama sonrası, 1 saat içinde | %4–6 |
| Tanımsız (kötü senaryo) | Hiç | "Yakında" | %18+ |
Neden çıkış gecesi elle kod göndermek matematiksel olarak imkânsız?
Bir oyunun ön sipariş penceresi haftalarca sürer, ama teslim talebi tek bir gece içinde patlar. 300 siparişin varsa ve her birini elle işlemek ortalama 90 saniye sürüyorsa, kesintisiz çalışsan bile 7,5 saatlik bir iş yükünden bahsediyorsun. O saatlerde aynı zamanda destek kutun doluyor, WhatsApp titriyor ve bir kısım müşteri iade talebi açıyor. Sonuç: elle teslim modeli tam ihtiyaç duyduğun anda çöker.
Çözüm karmaşık değil, sadece önceden kurulmalı. Kodlar sisteme çıkıştan günler önce yüklenir, her ürüne serbest bırakma zamanı işlenir ve zamanlayıcı saat geldiğinde tüm kuyruğu tek seferde boşaltır. Böylece çıkış gecesi senin rolün kod göndermek değil, kuyruğun boşaldığını izlemek olur. İyi bir e-pin scripti bu farkı sağlar: iş yükünü olayın olduğu gecenin dışına taşır.
Bir de şu var: otomatik teslim sadece hız değil, kanıt demektir. Hangi kod, hangi siparişe, hangi saniyede, hangi IP'ye gitti sorusunun cevabı kayıt altındadır. Bu kayıt, ödeme sağlayıcın bir itiraz dosyası açtığında senin tek savunma belgendir.
Ön sipariş destek taleplerinin dağılımı
- "Kod ne zaman gelecek?" 45%
- Bölge/platform uyumu 25%
- E-posta ulaşmadı 20%
- Gerçek kod arızası 10%
Geri sayım sayacı süs müdür, satış aracı mıdır?
Ürün sayfasındaki geri sayım çoğu satıcıda dekoratif bir öğedir; oysa doğru bağlandığında iki işi birden yapar. Birincisi psikolojik: müşteri kaç saat sonra ne olacağını görürse belirsizlik kaybolur ve sepeti tamamlar. İkincisi operasyonel: sayaç teslim zamanlayıcısıyla aynı veriden beslenirse, sayfada yazan saat ile sistemin göndereceği saat asla ayrışmaz.
Tehlikeli olan üçüncü senaryo, sayacın elle girilmiş bir metin olmasıdır. Sayfada "2 gün 4 saat" yazarken arka planda hiçbir iş planlanmamışsa, müşteriye yayınlanmış bir taahhüt vermiş olursun ve o taahhüdü tutacak bir mekanizman yoktur. Bu tam olarak itiraz kaybettiren durumdur. Özellikler bölümünde göreceğin gibi sayaç, sipariş durumu ve teslim kuyruğu tek bir zaman kaynağına bağlıysa sayfa yalan söyleyemez.
Bir ayrıntı daha: sayaç bittiğinde sayfa kendini yenileyip "teslim edildi" durumuna geçmeli. Aksi halde müşteri sıfırlanmış bir sayaca bakıp "sistem bozuldu" düşünür ve sana yazar. Ön siparişte her yazılan mesaj, önlenebilmiş bir mesajdır.
Aynı kodu iki kişiye satmanın gizli yolu: yarış koşulu
Ön siparişte en pahalı teknik hata çift teslimdir. Çıkış saatinde onlarca sipariş aynı saniyede işlenir; eğer kod havuzundan seçim işlemi kilitlenmemişse iki farklı sipariş aynı kaydı okuyup aynı kodu alabilir. Bunun sonucu iki müşteri, bir kod ve kesin bir itirazdır. Üstelik bu hata düşük trafikte hiç görünmez, sadece en kritik gecede ortaya çıkar.
Doğru kurgu, kodun sipariş kaydına atomik biçimde rezerve edilmesidir: kod seçilir, anında kilitlenir, sipariş numarası yazılır, ancak ondan sonra gönderim tetiklenir. Kurumsal düzeyde bir e-pin satış yazılımı bunu veritabanı seviyesinde çözer, uygulama katmanında "umarım çakışmaz" mantığına bırakmaz. Pinova'nın teslim motoru her kodu tek sahipli bir varlık gibi ele alır; rezerve edilmiş bir kod ikinci bir kuyruğa asla düşmez.
Kendine bir test siparişi aç ve serbest bırakma saatini 5 dakika sonrasına kur. Mail, panel ve sayaç aynı anda doğru davranıyorsa gece rahat geçer. Provasız çıkış gecesi, canlı ortamda hata ayıklamaktır.
E-posta gitti ama ulaşmadı: teslimin en kırılgan halkası
Sistem kodu tam saatinde gönderse bile müşteri görmüyorsa teslim gerçekleşmemiş sayılır. Ön sipariş gecelerinde tek kalemde yüzlerce mail çıkar; bu ani hacim itibar puanını düşürür ve mesajlar spam klasörüne gider. Bu yüzden e-posta teslimi tek kanal olarak asla yeterli değildir.
Sağlam kurulum üç katmanlıdır: kod her zaman müşterinin hesap panelinde görünür olur, e-posta bir bildirim aracı olarak gider, kritik ürünlerde ek olarak SMS veya anlık bildirim devreye girer. Ayrıca gönderimler kısa aralıklara bölünerek dağıtılır, hepsi aynı saniyede fırlatılmaz. Panel tek gerçek kaynak, mail sadece hatırlatıcı ilkesini benimsersen "mail gelmedi" talebi destek sorunundan bilgilendirme sorununa iner.
| Kontrol | Neden kritik | Ne zaman yapılır | Durum |
|---|---|---|---|
| Her SKU'ya serbest bırakma damgası | Yanlış vaadi engeller | Ürün yayına alınmadan | Zorunlu |
| Kod havuzu atomik rezerve | Çift teslimi keser | Kurulumda bir kez | Zorunlu |
| Sayaç–zamanlayıcı aynı kaynak | Sayfa ile sistem ayrışmaz | Sayfa tasarımında | Zorunlu |
| Panelde kod görünürlüğü | Mail bağımlılığını kırar | Kurulumda | Zorunlu |
| Gönderim dalgalara bölünmüş | Spam riskini düşürür | Çıkıştan 1 gün önce | Önerilir |
| Test siparişiyle prova | Gece sürprizini bitirir | Çıkıştan 24 saat önce | Zorunlu |
| Teslim log'u dışa aktarılabilir | İtiraz dosyasında kanıt | Sürekli | Önerilir |
Gecikme olursa ne yapacağını önceden yazmadıysan kaybettin
Tedarikçi kodu geciktirebilir, platform tarafında bir aksaklık çıkabilir. Bunlar olacak; asıl soru sen hazırlıklı mısın. Profesyonel satıcı ile amatör satıcı arasındaki fark, gecikme anında kurulan iletişimin önceden yazılmış olmasıdır. Müşteriyi sen haberdar edersen kriz yönetimi, o sana yazarsa şikâyet yönetimi yaparsın.
Bunun için üç hazır senaryo tut: kısa gecikme (yeni saat bildirimi), uzun gecikme (telafi kuponu ile birlikte bildirim), tedarik iptali (koşulsuz iade ve özür). Panelden ilgili siparişleri filtreleyip tek hamlede toplu bildirim gönderebiliyorsan bu senaryolar dakikalar içinde uygulanır. Fiyat planlarını incelerken bu toplu bildirim ve teslim raporlama yeteneğine özellikle bak; çıkış gecesinde işine yarayacak olan özellik listesindeki en sıkıcı satırdır.
Çıkış gecesini destek nöbetine çevirmeyi bırak
Zamanlanmış teslim, atomik kod rezervesi ve toplu bildirim tek panelde. Pinova ile ön sipariş penceresini elle değil kurulumla yönet.
Ön sipariş kodunu erken teslim etmem sorun olur mu?
Tedarikçi sözleşmesinde embargo varsa evet, ciddi sorun olur. Erken sızan kodlar hesabının kapatılmasına kadar gidebilir. Bu yüzden kodu elinde tutup sistemde serbest bırakma saatiyle kilitlemek en güvenli yoldur.
Teslim saatini müşteriye tam dakika olarak yazmalı mıyım?
Yazabileceğin en net şeyi yaz ama tutamayacağın bir kesinlik verme. Tedarikçi taahhüdün saat bazındaysa saat yaz, gün bazındaysa "çıkıştan en geç 24 saat önce" gibi bir pencere ver ve o pencereye uy.
Çift kod teslim ettiğimi nasıl anlarım?
Teslim kayıtlarında aynı kodun iki farklı sipariş numarasıyla eşleşip eşleşmediğini sorgula. Bu kontrolü otomatik uyarıya bağlamak en iyisidir; elle bakılan bir rapor tam yoğun gecede açılmaz.
Küçük ölçekli satıcıysam bu kadar yapıya gerek var mı?
Ölçek küçükken bile ön siparişin yoğunluk eğrisi aynıdır: aylık satışının önemli kısmı tek geceye sıkışır. Yapıyı önceden kurmak, 50 siparişte de 500 siparişte de aynı rahatlığı verir.
Ön sipariş satışında kazanan, en ucuz kodu bulan değil, teslim saatini yönetebilen satıcıdır. Elinde zamanlanmış teslim, kilitli kod havuzu ve dürüst bir sayaç varsa çıkış gecesi senin için sıradan bir geceye dönüşür. Bu akışın panelde nasıl göründüğünü kendi gözünle görmek istersen canlı demo üzerinden bir ön sipariş ürünü oluşturup serbest bırakma saatini beş dakika sonrasına kur; sistemin sen hiçbir şey yapmadan kodu teslim ettiğini izlemek, bu yazının anlattığı her şeyi tek seferde anlatır.