Rocket League kredi satan çoğu işletme sahibi ilk iadeyi yedikten sonra aynı cümleyi kurar: "Ürün doğruydu, kullanıcı yanlış yerde kullandı." Bu cümle teknik olarak doğru olabilir ama ticari olarak seni kurtarmaz. Dijital ürün satışında sorumluluk sınırı, kullanıcının hangi platformda oynadığını sipariş anında sorup sormadığında belirlenir. Sormadıysan, teslim edilemeyen her sipariş senin masrafındır; hem iade hem itibar hem destek zamanı.
Bu ürün grubunda kafa karışıklığının sebebi şu: oyun aynı, hesap aynı görünüyor, ama bakiye ve satın alma kanalı platforma bağlı. Kullanıcı "ben zaten aynı hesapla oynuyorum" der ve haklı olduğunu düşünür; senin sistemin ise platform ayrımı yapmadığı için ona uyumsuz bir ürünü satar. Bu yazıda platform kısıtlarının satış akışında tam olarak nereyi kırdığını, hangi noktada hangi soruyu sorman gerektiğini ve bir e-pin scripti üzerinde bu duvarı nasıl önceden öreceğini anlatacağım.
Platform kısıtı tam olarak neyi kısıtlıyor?
Kısıt üç ayrı katmanda çalışır ve bunları birbirine karıştırmak hataların ana kaynağıdır. Birinci katman satın alma kanalıdır: bakiye hangi mağaza ekosisteminden yüklendiyse o ekosistemin kuralları geçerlidir. İkinci katman kullanım katmanıdır; yüklenen bakiyenin hangi hesap ve hangi ortamda harcanabildiği. Üçüncü katman ise takas ve transfer katmanıdır; oyun içi eşyaların platformlar arasında taşınıp taşınamaması.
Bayi olarak seni doğrudan ilgilendiren birinci ve ikinci katmandır. Kullanıcıya sattığın şey belirli bir ekosisteme bağlı bir ürünse, o kullanıcının hangi ortamda oynadığını bilmeden satış tamamlanmamalıdır. Üçüncü katman ise destek yazışmalarını şişiren yerdir; kullanıcı satın aldığı şeyin her yerde geçerli olacağını varsayar ve olmadığında iade ister. Bu yüzden ürün sayfasında yalnızca fiyat değil, uyumluluk bilgisi de bulunmalıdır. İyi kurulmuş bir dijital ürün satış scripti bu bilgiyi ürün özelliği olarak tutar ve sepette kontrol eder.
Sipariş formunda hangi soruyu sormazsan iade yersin?
Tek bir zorunlu alan, bu kategorideki iadelerin çoğunu bitirir: platform seçimi. Ama seçim listesi olması yetmez; seçimin satışı gerçekten engellemesi gerekir. Kullanıcı uyumsuz bir kombinasyon seçtiğinde sistem "bu ürün seçtiğin ortamda kullanılamaz" diyerek ödemeyi başlatmamalıdır. Uyarıyı küçük yazıyla ürün açıklamasının altına koymak hukuken bir şey ifade etse de pratikte hiçbir şeyi önlemez; kimse okumaz.
İkinci önemli alan hesap bilgisinin doğru biçimde alınmasıdır. Kullanıcı adı, etiket, bölge gibi alanlar serbest metin olarak alındığında yazım hataları teslimat hatasına dönüşür. Biçim doğrulaması, örnek gösterimi ve girişten sonra özet ekranında tekrar onay istemek maliyetsiz önlemlerdir. Üçüncüsü ise sipariş sonrası teslim talimatıdır: kullanıcı kodu nereye gireceğini bilmiyorsa "çalışmıyor" diye yazar. Platforma göre farklı talimat metni göstermek bu yazışmaları kökten keser. Bunların hepsi ürün bazlı alan tanımı destekleyen bir e-pin satış yazılımı ile kurulabilir; özellik sayfasında "özel sipariş alanı" ve "ürün bazlı teslim talimatı" kalemlerine bak.
| Ortam | Tipik kısıt kaynağı | Satış öncesi sorulması gereken | Sık görülen hata | Önleme yolu |
|---|---|---|---|---|
| PC (mağaza tabanlı) | Mağaza hesabı ve bölge eşleşmesi | Hangi mağaza kütüphanesi kullanılıyor | Bölge uyumsuz ürün gönderimi | Ürüne bölge etiketi ve sepet kontrolü |
| PlayStation | Konsol hesabı ekosistemi | Hesap bölgesi ve profil | Farklı bölgeye ait kod | Bölge bazlı stok ayrımı |
| Xbox | Hesap ve bölge eşleşmesi | Hesap bölgesi | Yanlış ortam için sipariş | Zorunlu platform seçimi |
| Nintendo Switch | Mağaza bölgesi | Bölge ve hesap tipi | Talimatsız teslimat | Platforma özel teslim metni |
| Çapraz ilerleme kullananlar | Bakiyenin kanala bağlı olması | Yükleme yapılacak ortam | "Her yerde geçer" varsayımı | Ürün sayfasında net uyumluluk notu |
Manuel kontrol neden ölçeklenmez?
Günde on sipariş alırken her siparişi elle okuyup platform uyumunu kontrol edebilirsin. Yüz siparişte bu iş yavaşlar, iki yüzde ise sistem çöker. Daha kötüsü, elle kontrol hatası rastgele değildir: en yoğun olduğun saatte, yani en çok satış yaptığın anda hata yapma olasılığı en yüksektir. Bu da kaybı tam olarak en pahalı yerde toplar.
Manuel kontrolün ikinci maliyeti hızdır. Kullanıcı ödemeyi yaptıktan sonra beklerse endişelenir, endişelenince yazar, yazınca senin destek yükün artar. Oysa uyumluluk kuralı sipariş öncesine taşındığında teslimat anlık olur ve destek talebi hiç doğmaz. Kural şu: doğrulama ödemeden önce, teslimat ödemeden hemen sonra. Bu sıralamayı kuran işletme, aynı personel ile birkaç kat fazla sipariş yönetir. Plan seçiminde otomatik teslimat ve sipariş öncesi doğrulama birlikte gelmiyorsa, o paket seni yoğun günde yalnız bırakır.
Uyumsuzluk kaynaklı destek taleplerinin dağılımı
- Yanlış platform seçimi 45%
- Bölge uyumsuzluğu 25%
- Hesap bilgisi hatası 20%
- Talimat eksikliği 10%
İade politikasını nasıl yazarsan hem adil hem korunaklı olur?
Dijital üründe iade politikası bir formalite değil, operasyonel bir araçtır. İyi yazılmış politika iki şeyi net ayırır: senin hatan ve kullanıcının hatası. Kodun teslim edilmemesi, geçersiz olması veya çift kullanılmış olması senin sorumluluğundadır ve burada tartışmasız çözüm üretmelisin. Kullanıcının kendi belirttiği platformu yanlış seçmesi ise farklı bir kategoridir ve politikada bu ayrımın açıkça yazılı olması gerekir.
Ancak politikanın gerçekten işe yaraması için kanıt üretebilmen şart. Kullanıcının sipariş anında hangi platformu seçtiği, hangi bilgiyi girdiği ve kodun hangi saniyede teslim edildiği kayıtlı olmalıdır. Bu kayıt varsa tartışma iki mesajda kapanır; yoksa politikanın ne yazdığı önemsizdir çünkü ispat edemezsin. Sipariş günlüğü, teslim zaman damgası ve kullanıcı girdilerinin saklanması bu yüzden lüks değil, işletme sigortasıdır. Bu altyapıyı kurmak için panel üzerinden ilerleyebilirsin.
Uyumsuz kombinasyonda kullanıcıyı bilgilendirmekle yetinme; ödeme adımını doğrudan kapat. Kullanıcı okumadığı bir uyarıyı hatırlamaz ama tıklayamadığı bir butonu mutlaka fark eder.
Bu duvarı panelde nasıl örersin?
Somut kurulum sırası şöyledir. Önce ürünlerini platform ve bölge etiketiyle ayırırsın; aynı ürünü tek kalemde tutup "kullanıcı halleder" demek en pahalı kısayoldur. Sonra her ürüne zorunlu sipariş alanları tanımlarsın: platform seçimi, bölge, hesap bilgisi. Ardından uyumsuz kombinasyonlar için sepet kuralı kurarsın; bu kural ödemeyi başlatmaz. Dördüncü adım platforma özel teslim talimatının otomatik gönderilmesidir. Beşinci ve son adım, tüm bu girdilerin sipariş kaydında saklanmasıdır.
Pinova bu beş adımın hepsini tek yerde kurmak için tasarlanmış bir yazılımdır; kendisi kredi veya bakiye satmaz, bunları satan işletmenin teslimat ve uyumluluk kurallarını yürütür. Ürün bazlı özel alanlar, otomatik teslimat, stok eşiği, sipariş günlüğü ve rapor katmanı birlikte çalıştığında platform kısıtları bir risk kalemi olmaktan çıkıp sıradan bir kurala dönüşür. Bir epin yazılım seçerken kataloğun büyüklüğünden çok, uyumsuz siparişi ödeme öncesinde durdurup durdurabildiğine bak; bu kategoride kârı koruyan asıl özellik budur.
| Kontrol | Hangi riski kapatır | Durum |
|---|---|---|
| Ürünler platform ve bölge etiketiyle ayrılmış | Yanlış ürünün satılmasını engeller | Evet / Hayır |
| Platform seçimi zorunlu sipariş alanı | Uyumsuzluk iadelerinin ana kaynağını keser | Evet / Hayır |
| Uyumsuz kombinasyonda ödeme başlamıyor | Okunmayan uyarı problemini çözer | Evet / Hayır |
| Hesap bilgisi alanında biçim doğrulaması var | Yazım hatası kaynaklı teslim hatasını azaltır | Evet / Hayır |
| Platforma özel teslim talimatı otomatik gidiyor | "Çalışmıyor" mesajlarını bitirir | Evet / Hayır |
| Sipariş girdileri ve teslim zamanı kayıtlı | İade tartışmasında ispat sağlar | Evet / Hayır |
| Bölge bazlı stok ayrı takip ediliyor | Yanlış bölge kodunun gönderilmesini önler | Evet / Hayır |
Teslim edilemeyen siparişi baştan engelle
Pinova ile ürün bazlı zorunlu alanlar, uyumluluk kuralları, otomatik teslimat ve eksiksiz sipariş günlüğü tek panelde kurulur. İade ve destek yükü daha sipariş oluşmadan düşer.
Platform seçimini zorunlu yapmak dönüşümü düşürür mü?
Hissedilir bir düşüş yapmaz. Tek adımlık net bir seçim, kullanıcıya doğru ürünü aldığı güvenini verir. Dönüşümü asıl düşüren şey teslim sonrası yaşanan sorun ve iade sürecidir.
Aynı ürünü tek kalemde tutup açıklamada uyarmak yetmez mi?
Yetmez. Açıklamalar okunmaz ve ispat gücü zayıftır. Ürünü ayırmak hem doğru stok takibi hem de ödeme öncesi engelleme imkânı sağlar.
İade politikası tek başına beni korur mu?
Korumaz. Politikanın işlemesi için sipariş anındaki seçimlerin ve teslim zamanının kayıtlı olması gerekir. Kayıt yoksa politika sadece bir metindir.
Küçük hacimde bu kadar kurala gerek var mı?
Kuralları hacim küçükken kurmak en kolayıdır. Sipariş sayısı arttığında aynı yapıyı sıfırdan kurmak hem zaman hem müşteri kaybettirir.
Platform kısıtları sana engel gibi görünür ama doğru kurulduğunda rakiplerinin önüne geçtiğin yer olur: uyumsuz siparişi baştan durduran bir vitrin, kullanıcıya "burası işini biliyor" izlenimi verir ve o izlenim tekrar siparişe dönüşür. Zorunlu sipariş alanlarının, uyumluluk kurallarının ve otomatik teslim talimatlarının gerçek panelde nasıl kurulduğunu görmek için canlı demo üzerinden bir ürün oluşturup kendi akışını baştan sona deneyebilirsin.