Çoğu kişi ikisini tek kelimeyle özetler: "dijital ürün satıyorum, ne fark eder?" Ürün listesi var, sepet var, ödeme var, teslimat var. Dışarıdan bakınca gerçekten aynı görünüyorlar. Ama işin içine girdiğin ilk ayda fark kendini acı bir şekilde gösteriyor: oyun satışı için tasarlanmış bir panelle e-pin satmaya çalıştığında stok mantığı çöküyor, e-pin için tasarlanmış bir yapıyla hesap ya da oyun içi hizmet satmaya çalıştığında teslimat akışı tıkanıyor.
Bu iki ürün ailesi aynı vitrini paylaşabilir ama arka mutfakları taban tabana zıttır. Birinde ürün sayılabilir, tekildir ve bir kez tükenir; diğerinde ürün genellikle bir hizmet, bir hesap veya elle yapılan bir işlemdir. Bu yazıda ayrımı teknik seviyede açacağım: stok modeli, teslimat tetikleyicisi, iade riski, fiyatlandırma, destek yükü. Sonunda hangi e-pin scripti ya da hangi hibrit yapının senin katalogunla uyuştuğunu net göreceksin.
İkisini aynı sanmak neden bu kadar yaygın bir hata?
Sebebi basit: pazarda iki ürün de aynı raftan satılıyor. Bir oyuncu aynı siteden hem oyun anahtarı hem elmas paketi hem de hesap yükseltme hizmeti alabiliyor. Satıcı da doğal olarak "tek panel hepsini yönetir" diye düşünüyor. Düşünce yanlış değil, eksik. Tek panel hepsini yönetebilir ama panelin içinde iki ayrı ürün tipi motoru olması şartıyla.
Sorun, motor tek olduğunda çıkıyor. Yalnızca kod havuzu mantığıyla yazılmış bir e-pin satış scripti ile hesap satmaya kalkarsan, her hesap için tek satırlık bir "kod" uydurmak zorunda kalırsın; iade, teslim sonrası şifre değişimi, garanti süresi gibi alanlar hiçbir yere sığmaz. Tersine, sipariş bazlı manuel teslimat için yazılmış bir panelde e-pin satarsan, gece 3'te gelen siparişi elle karşılamak için uyanmak zorunda kalırsın. İkisi de çalışır görünür, ikisi de seni yavaşça yorar.
Stok modeli tam olarak nerede ayrışıyor?
E-pin tarafında stok tekil ve tükenir. Havuzda 200 kod varsa, satılan her kod havuzdan çıkar, bir daha satılamaz. Sistem bu yüzden kilitleme, çift satış engeli ve parti takibi üzerine kurulur. Kritik risk aynı kodun iki müşteriye gitmesidir; mimarinin tamamı bunu önlemek için tasarlanır.
Oyun ve hizmet tarafında stok genellikle kapasitedir. "Günde 10 boost siparişi alabilirim" ya da "3 tedarikçim var, her biri 5 iş yapabilir" gibi. Burada tekil bir nesne yok; sayılan şey iş gücü ve zaman. Kritik risk çift satış değil, taahhüt edilen sürede teslim edememektir. Bu yüzden kuyruk, atama, ilerleme durumu ve tahmini teslim saati alanları zorunlu hale gelir. Gördüğün gibi iki mimarinin koruduğu şey bile farklı.
| Kriter | E-Pin / Kod Satışı | Oyun Hesabı & Hizmet Satışı | Ortak Kullanım |
|---|---|---|---|
| Stok birimi | Tekil kod, tükenir | Kapasite veya tek nüsha hesap | Ürün kartı ve kategori |
| Teslim tetikleyici | Ödeme onayı, anında | Operatör onayı, kuyruk | Ödeme doğrulama |
| En büyük risk | Aynı kodun iki kez satılması | Süre aşımı ve teslim sonrası erişim kaybı | Sahte ödeme |
| İade zorluğu | Kod görüldükten sonra geri alınamaz | Hizmet kısmen yapılmış olabilir | Kanıt gereksinimi |
| Gerekli günlük | Kod maskesi ve görüntüleme kaydı | Atama, durum değişimi, ekran kanıtı | IP ve ödeme izi |
| Destek yükü | Düşük, ani yoğunluk | Yüksek, sürekli iletişim | Canlı destek |
| Fiyat davranışı | Kur ve tedarikçi maliyetine bağlı | Emek ve süreye bağlı | Kampanya motoru |
Teslimat akışı hangi noktada birbirine benzemeyi bırakıyor?
E-pin teslimatı bir fonksiyondur: ödeme onaylandı, havuzdan kod ayır, siparişe yaz, müşteriye göster, arşive kaydet. İnsan yok, gecikme yok, pazarlık yok. Bu akışın tek kalite ölçüsü hatasız çalışmasıdır. Bu yüzden sağlam bir dijital ürün satış scripti burada tek işlem bloğu, kilit ve yeniden denenebilir kuyruk kullanır.
Hesap veya hizmet teslimatı ise bir süreçtir: sipariş düşer, operatöre atanır, operatör işi başlatır, ara durum bildirir, tamamlar, kanıt yükler, müşteri onaylar. Buradaki kalite ölçüsü hatasızlık değil, görünürlüktür. Müşteri işin nerede olduğunu görmüyorsa, işi zamanında bitirsen de destek kutusu dolar. İki akışı aynı ekranda yönetmeye çalışan yazılımlar, genelde birini iyi diğerini yarım yapar.
Yanlış yazılım seçiminin satıcıya çıkardığı maliyet dağılımı
- Elle yapılan işlerin zaman kaybı 40%
- Teslim gecikmesinden doğan iade 30%
- Stok hatası ve çift satış 18%
- Göç ve yeniden kurulum 12%
Hangi katalog hangi yazılımı zorunlu kılıyor?
Kararı kolaylaştıran tek soru şu: katalogunun ciro olarak kaçta kaçı anında teslim edilebilir kodlardan geliyor? Cevap yüzde 70'in üstündeyse, ana motorun kod havuzu mimarisi olmalı; hizmet ürünlerini yan modül olarak eklersin. Cevap yüzde 40'ın altındaysa, önce kuyruk ve atama tarafı güçlü olan bir yapı kurar, e-pini oraya eklersin.
Arada kalanlar için doğru cevap hibrit. Yani ürün tipi başına farklı teslimat davranışı tanımlanabilen bir e-pin satış yazılımı. Pinova bu ayrımı ürün seviyesinde yapıyor: aynı katalogda bir ürün "anında kod" davranışıyla, diğeri "manuel onaylı teslim" davranışıyla çalışabiliyor. İki ayrı panel, iki ayrı muhasebe, iki ayrı destek kutusu gerekmiyor. Hangi ürün tipinin hangi alanları taşıdığını özellikler bölümünde karşılaştırabilirsin.
Aday yazılımda aynı sepette hem anında teslim bir kod hem manuel onaylı bir hizmet dene. Sepet ikisini tek ödemede yönetebiliyor, kodu hemen verip diğerini kuyruğa alıyorsa hibrit gerçekten çalışıyor demektir.
Peki bu iki dünyayı tek sitede birleştirmenin bedeli ne?
Bedeli var, saklamayacağım. Hibrit yapı, muhasebe ve raporlamayı karmaşıklaştırır. Anında teslim ürünlerde ciro ödeme anında kesinleşirken, hizmet ürünlerinde iş tamamlanana kadar askıdadır. Bu ikisini aynı ciro grafiğine koyarsan yanlış karar verirsin. Bu yüzden doğru kurulumda raporlar ürün tipine göre ayrışır: kod satışında net kâr tedarikçi maliyetinden, hizmet satışında operatör payından sonra hesaplanır.
İkinci bedel destek disiplini. Anında teslim ürün alan müşteri hiç yazmaz, hizmet alan müşteri günde üç kez yazar. Aynı destek kuyruğunu paylaştırırsan, kod müşterisinin acil "kod gelmedi" mesajı hizmet sohbetlerinin altında kaybolur. Ayrı öncelik kuralları şart. Kısaca hibrit güçlüdür ama kurallı olmak zorundadır; kuralsız hibrit, iki işi de yarım yapan bir panele dönüşür. Paketlerin hangisinde bu ayrımların hazır geldiğini fiyat tablosundan görebilirsin.
| Kontrol Sorusu | Neden Önemli | Beklenen Cevap | Öncelik |
|---|---|---|---|
| Ürün tipi başına teslimat davranışı var mı | Hibrit katalogun temeli | Evet, ürün seviyesinde | Kritik |
| Kuyruk ve operatör ataması var mı | Hizmet siparişleri için zorunlu | Atama + durum takibi | Kritik |
| Kod havuzunda kilit mekanizması | Çift satışı engeller | İşlem bazlı kilit | Kritik |
| Rapor ürün tipine göre ayrılıyor mu | Kâr hesabı bozulmasın | Ayrı ayrı kâr marjı | Yüksek |
| Destek önceliklendirme | Acil kod talebi kaybolmasın | Tip bazlı öncelik | Yüksek |
| Tedarikçi maliyet alanı | Gerçek marjı görmek için | Ürün ve parti bazlı | Orta |
| Garanti / telafi alanı | Hesap ürünlerinde şart | Süre ve koşul tanımı | Orta |
Katalogun iki dünyaya da uzanıyorsa, tek motor yetmez
Ürün tipi başına teslimat davranışı tanımlayabilen bir yapı, altı ay sonra göç etmek zorunda kalmanı önler.
Sadece e-pin satıyorum, hizmet modülüne ihtiyacım var mı?
Bugün yoksa zorunlu değil. Ancak katalog büyüdükçe hesap, boost veya abonelik türü ürünler neredeyse her satıcının gündemine giriyor. Altyapının buna hazır olması sonradan göç maliyetinden kurtarır.
Oyun hesabı satışını kod mantığıyla yönetebilir miyim?
Teknik olarak zorlayabilirsin ama garanti süresi, teslim sonrası şifre değişimi ve telafi kaydı için yer bulamazsın. Bu alanlar olmadan itirazları yönetmek çok zor.
Hibrit yapı siteyi yavaşlatır mı?
Doğru kurulduğunda hayır. Yavaşlatan şey hibritlik değil, her sipariş tipini aynı ağır sorgudan geçirmek. Teslimat mantıkları ayrıştığında performans etkilenmez.
Hangisiyle başlamak daha mantıklı?
Cironun çoğunluğu hangi tipteyse onun motorunu ana eksen yap. Ancak baştan hibrit destekleyen bir altyapı seçmek, ikinci tipi eklemeyi haftalardan saatlere indirir.
Sonuç net: oyun satış scripti ile e-pin scripti aynı şey değil, ama doğru tasarlanmış bir altyapıda aynı çatı altında yaşayabilirler. Önemli olan hangi ürünün hangi motorla çalıştığını senin belirleyebilmen. İki teslimat davranışının aynı sepette nasıl birlikte çalıştığını görmek için canlı demo içinde biri kodlu biri manuel iki ürünü aynı siparişe ekleyip sonucu kendi gözünle test et.