Dijital satışa başlayan hemen herkes aynı yerden giriyor: ürün ekle, koduyu yapıştır, sat. İlk yüz siparişte bu yaklaşım kusursuz çalışır. Sonra kataloğa hesap satışı girer, ardından tedarikçiden anlık çekilen bir bakiye ürünü eklenir, derken bir dijital dosya, bir de manuel onay isteyen özel sipariş. O noktada tek tip teslimat mantığıyla yazılmış panel çatırdamaya başlar, çünkü her ürün artık farklı bir fiziğe sahiptir ama sistem hepsine aynı muameleyi yapmaktadır.
Burada kritik bir yanılgı var: insanlar teslimat tipini bir "ayar" sanıyor. Değil. Teslimat tipi, o ürünün stok kaynağını, sipariş statü akışını, iade kurallarını, destek yükünü ve hatta ödeme riskini belirleyen yapısal bir karardır. Doğru kurulmuş bir dijital ürün satış scripti teslimat tipini ürün kaydında birinci sınıf bir alan olarak tutar ve sistemin geri kalanı bu alana göre davranır. Bu yazıda hangi teslimat tiplerinin var olduğunu, hangi ürüne hangisinin uyduğunu ve seçimi yanlış yaptığında bunun faturasını nerede ödeyeceğini anlatıyorum.
Kaç farklı teslimat tipi var ve hangisi neye benziyor?
Pratikte beş temel tip vardır. Birincisi havuzdan anında teslimat: önceden yüklenmiş kod satırlarından biri sipariş anında çekilir ve müşteriye gösterilir. İkincisi manuel teslimat: sipariş açılır, bir yetkili kodu veya bilgiyi elle girer, sistem müşteriye iletir. Üçüncüsü API ile anlık çekim: sipariş anında tedarikçi servisine istek atılır ve dönen değer teslim edilir. Dördüncüsü dosya teslimatı: müşteri hesabında süreli ve indirme sayısı sınırlı bir bağlantı oluşur. Beşincisi hesap veya oturum aktarımı: kullanıcı adı, parola ve varsa doğrulama anahtarı birlikte iletilir.
Bu beş tipin ortak yanı yoktur denecek kadar azdır. Havuzdan teslimat stok tükenince satışı durdurmalıdır; API teslimatında stok kavramı yoktur, servis cevabı vardır. Dosya teslimatında sınırsız stok geçerlidir ama indirme hakkı sınırlıdır. Hesap aktarımında ise ürün tek seferliktir ve satıldıktan sonra asla tekrar satılamaz. Bir e-pin yazılımı bu beş davranışı tek bir kod bloğuyla yönetmeye çalışırsa, her yeni ürün tipi bir istisna yamasına dönüşür ve sistem zamanla bakımı imkânsız hale gelir.
| Teslimat tipi | Stok kaynağı | Ortalama teslim süresi | Başarısızlık riski | Uygun olduğu ürün |
|---|---|---|---|---|
| Havuzdan anında | Kod satırları | Saniyeler | Düşük | Oyun kodu, hediye kartı |
| Manuel onaylı | Operatör | 5 dk - 6 saat | Orta | Özel paket, toplu sipariş |
| API ile anlık çekim | Tedarikçi servisi | 2-15 saniye | Servise bağlı | Bakiye yükleme, sanal para |
| Dosya indirme | Sınırsız | Anında | Çok düşük | Lisans dosyası, dijital içerik |
| Hesap aktarımı | Tekil kayıt | Anında veya manuel | Yüksek | Hazır hesap, koleksiyon |
Teslimat tipi neden ürün bazında seçilmeli, kategori bazında değil?
Kategori bazlı ayar cazip görünür çünkü kurulumu kolaydır. Ama katalog büyüdükçe aynı kategorinin içinde farklı tedarik yöntemleri belirir. Aynı oyun kategorisinde bir ürün havuzdan çıkarken, yanındaki ürün tedarikçi servisinden anlık çekilir, üçüncüsü ise elde tutulan sınırlı bir stoktan manuel verilir. Kategoriye bağladığın an bu üç ürünü aynı kutuya sıkıştırmış olursun ve istisna yönetmek için kod yazmaya başlarsın.
Ürün bazlı seçim ayrıca operasyonel bir esneklik verir. Tedarikçi servisi arıza yaptığında o ürünü tek tıkla manuel teslimata çevirir, satışı durdurmak zorunda kalmazsın. Havuzun tükendiğinde ürünü kapatmak yerine ön sipariş moduna alırsın. Teslimat tipi değiştirilebilir bir alan olduğunda, kriz anlarında satışı kesmek yerine akışı değiştirirsin. Bu tek başına yıllık ciroda hissedilir bir fark yaratır. Sağlam bir e-pin satış scripti bu değişikliği ürün düzenleme ekranından, geliştirici gerektirmeden yapabilmeni sağlar.
Olgun bir katalogda teslimat tipi dağılımı
- Havuzdan anında 40%
- API ile anlık çekim 30%
- Manuel onaylı 20%
- Dosya ve hesap aktarımı 10%
Manuel teslimatı ne zaman seçmelisin, ne zaman seçmemelisin?
Manuel teslimat çoğu zaman tembellikten değil, çaresizlikten seçilir: tedarikçi API vermemiştir, ürün tekildir ya da her sipariş özel bilgi gerektirir. Bu durumlarda manuel meşrudur. Ancak manuelin görünmez maliyeti yüksektir. Her manuel sipariş bir insanın dikkatini ister ve o insan uyurken de sipariş gelir. Gece yarısı gelen manuel sipariş sabaha kadar bekler, müşteri sabaha kadar sinirlenir.
Manuel teslimatı seçiyorsan iki şeyi mutlaka kur: birincisi çalışma saati bildirimi, yani ürün kartında "bu ürün 09:00-23:00 arası elle teslim edilir" bilgisi. İkincisi operatör bildirimi, yani sipariş düştüğü anda telefona giden anlık uyarı. Bu ikisi yoksa manuel teslimat doğrudan itibar kaybı üretir. Ayrıca manuel siparişlerde ortalama teslim süresini ölçmeye başla; o sayı yükseliyorsa ürünü API'ye taşımanın veya havuz oluşturmanın zamanı gelmiştir. Panelde bu ölçümlerin nasıl raporlandığını özellikler bölümünden inceleyebilirsin.
API teslimatında servis yanıt vermezse sipariş hata verip düşmemeli, otomatik olarak manuel kuyruğa aktarılmalı. Yedek akışı olmayan otomasyon, arıza anında otomasyon olmaktan çıkar.
API ile anlık çekimde en çok nerede kanıyorsun?
API teslimatı en zarif çözümdür ama en kırılgan olanıdır çünkü kontrolün dışındaki bir sisteme bağlıdır. En sık yaşanan üç sorun şudur: zaman aşımı, çift çekim ve sessiz başarısızlık. Zaman aşımında istek yanıtsız kalır, sistem siparişi hatalı sayar ama tedarikçi tarafında işlem gerçekleşmiştir; sonuç, ödediğin ama teslim etmediğin bir koddur. Çift çekimde ise yeniden deneme mantığı yanlış kurulduğu için aynı sipariş iki kez işlenir ve maliyetin ikiye katlanır.
Bu üç sorunun ortak panzehiri idempotent istek yapısıdır: her sipariş için benzersiz bir işlem anahtarı üretilir ve aynı anahtarla ikinci kez istek gittiğinde tedarikçi yeni işlem açmaz. Buna ek olarak her çağrının isteği ve yanıtı ham haliyle loglanmalı, zaman aşımı halinde otomatik durum sorgusu çalıştırılmalıdır. API entegrasyonunun kalitesi başarı anında değil, arıza anında ölçülür. Bu koruma katmanlarının hazır geldiği bir e-pin satış yazılımı ile çalışmak, kendi entegrasyonunu sıfırdan sertleştirmekten çok daha hızlıdır.
Teslimat tipi müşteri deneyimini nasıl değiştirir?
Müşteri teslimat tipini bilmez ama sonucunu hisseder. Anında teslimatta ödeme sonrası ekranda kodu görür ve süreç biter. Manuelde bir bekleme ekranı görmeli, API teslimatında kısa bir işlem animasyonu ve başarısızlık halinde net bir mesaj almalıdır. Her tipin kendi ödeme sonrası ekranı olmalıdır; hepsine aynı "siparişiniz alındı" sayfasını gösteren siteler, en çok destek yükünü tam olarak bu yüzden taşır.
Ürün kartında da aynı şeffaflık gerekir. "Anında teslim" rozeti taşıyan ürün gerçekten anında teslim edilmeli, bu rozet teslimat tipi alanından otomatik üretilmelidir. Elle yazılan rozetler eninde sonunda gerçekle uyuşmaz. Otomatik rozet, hem yalan söylememeni garanti eder hem de kataloğunda hangi ürünün gerçekten hızlı olduğunu sana da gösterir. Hangi lisans seviyesinde bu otomasyonların açık geldiğini fiyat tablosundan karşılaştırabilir, ihtiyacına göre paket seçimini yapabilirsin.
| Kontrol | Neden önemli | Öncelik |
|---|---|---|
| Teslimat tipi ürün kaydında ayrı alan mı? | Kategori istisnalarını ortadan kaldırır | Kritik |
| Tip değişimi geliştirici gerektirmeden yapılabiliyor mu? | Arıza anında satışı sürdürür | Kritik |
| API çağrıları idempotent anahtarla mı gidiyor? | Çift çekim maliyetini engeller | Kritik |
| Zaman aşımında otomatik durum sorgusu var mı? | Ödenip teslim edilmeyen kodu kurtarır | Kritik |
| API hatasında manuel kuyruğa düşüyor mu? | Siparişin kaybolmasını önler | Yüksek |
| Manuel üründe operatör anlık bildirim alıyor mu? | Gece siparişlerinde gecikmeyi keser | Yüksek |
| Ödeme sonrası ekran tipe göre değişiyor mu? | Destek talebini azaltır | Yüksek |
| Anında teslim rozeti otomatik mi üretiliyor? | Vaat ile gerçeği hizalar | Orta |
| Dosya teslimatında indirme hakkı sınırlı mı? | Bağlantı paylaşımını engeller | Orta |
Her ürüne hak ettiği teslimatı ver
Beş teslimat tipi, yedek akışlar, idempotent API katmanı ve tipe göre değişen müşteri ekranları tek bir panelde hazır bekliyor.
Bir ürünün teslimat tipini sonradan değiştirebilir miyim?
Evet ve değiştirebilmen gerekir. Tedarikçi servisi arıza yaptığında ürünü manuel teslimata almak, havuz tükendiğinde ön sipariş moduna geçmek satışı durdurmadan krizi yönetmenin en pratik yoludur.
Manuel teslimat itibar kaybettirir mi?
Süre şeffaf biçimde yazıldığında ve operatöre anlık bildirim gittiğinde kaybettirmez. Sorun manuelin kendisinde değil, müşterinin ne kadar bekleyeceğini bilmemesinde ve siparişin gece boyunca fark edilmemesindedir.
API teslimatında çift çekim nasıl engellenir?
Her sipariş için benzersiz bir işlem anahtarı üretip tedarikçiye bu anahtarla istek göndererek. Aynı anahtarla gelen ikinci istek yeni işlem açmaz; ayrıca zaman aşımında yeniden denemeden önce durum sorgusu çalıştırılmalıdır.
Hesap aktarımı gibi tekil ürünlerde stok nasıl yönetilir?
Tekil kayıt olarak tutulur ve satıldığı anda kalıcı biçimde kapanır. Bu ürünler adet mantığıyla yönetilmemeli, her biri kendi kaydı olan tekil varlık olarak tanımlanmalı ve satış sonrası tekrar listelenmemelidir.
Teslimat tipi seçimi, kataloğun büyüdükçe geri dönüp düzeltmesi en pahalı kararlardan biri olur; çünkü yanlış kurulmuş bir akış sadece bir ürünü değil, o ürüne dokunan her raporu, her iade talebini ve her destek mesajını etkiler. Baştan doğru kurgulandığında ise yeni bir tedarikçi eklemek on dakikalık bir işe dönüşür. Beş teslimat tipinin panelde nasıl ayrıştığını, API hatası anında siparişin manuel kuyruğa nasıl düştüğünü ve müşterinin her senaryoda hangi ekranı gördüğünü test etmek için canlı demo üzerinden farklı tiplerde birer ürün tanımlayıp sipariş akışını uçtan uca deneyebilirsin.