Sektörde yaygın bir kanaat var: "kod koddur, bozulmaz." Yani bir kez satın alınan e-pin ya da ürün kodu rafta durur, ne zaman satılsa çalışır. Bu, kısmen doğru olduğu için tehlikeli bir cümle. Cüzdan yükleme kodlarının büyük kısmı gerçekten uzun ömürlüdür. Ama satışların önemli bir bölümü cüzdan kodu değildir: sezon paketi, kostüm bohçası, sınırlı süreli etkinlik ürünü, bölgeye bağlı içerik, kampanya kodu. Bu grubun ömrünü belirleyen şey senin rafın değil, oyunun sürüm takvimidir.
Bir güncelleme yayına girdiğinde arkada çoğu satıcının görmediği şeyler olur: mağaza kalem kimlikleri değişir, eski sezon ürünü kataloğdan düşer, bölge kilitleri sıkılaşır, kampanya kodları için tanımlı geçerlilik tarihi sessizce dolar. Kod hâlâ elinde, formatı hâlâ doğru görünüyor, ancak kullanıldığında "geçersiz" diyor. Bu yazıda bu sessiz aşınmanın mekanizmasını ve bir e-pin satış scripti tarafında kurabileceğin otomatik savunma düzenini anlatıyoruz.
Bir kodu "geçersiz" yapan gerçekte hangi katman?
Kod geçersizliğini tek bir sebebe bağlamak yanlış yönlendiriyor, çünkü arka planda birbirinden bağımsız üç katman var. Birinci katman kodun kendisi: üretilmiş, benzersiz, çoğu zaman süresiz bir dizgi. Bu katman güncellemeden etkilenmez. İkinci katman kodun bağlı olduğu ürün tanımı: kod aslında "şu kalem kimliğine sahip içeriği hesaba ekle" talimatıdır. Güncelleme o kalemi kataloğdan kaldırırsa talimat karşılıksız kalır.
Üçüncü katman kullanım koşulları: bölge, platform, hesap seviyesi, kampanya penceresi. Güncellemeler en sık bu katmanı değiştirir; çünkü yayıncı için bir kostüm paketini sezon sonunda kapatmak, kodu iptal etmekten daha kolaydır. Sonuç pratikte aynıdır: müşteri kodu girer, hata alır, sana yazar.
Bu ayrımı bilmenin işletme faydası şudur: gelen şikayetin hangi katmandan geldiğini sorabilir hale gelirsin. Müşteri "kod yanlış" diyorsa kodun kendisiyle, "kod kabul edildi ama içerik gelmedi" diyorsa ürün tanımıyla, "bölgenizde geçerli değil" diyorsa koşullarla ilgilenirsin. Üçü farklı çözüm gerektirir ve üçünü aynı destek şablonuyla yanıtlamak, çözüm süresini gereksiz yere uzatır.
Hangi kod tipleri sürüm riskine açık, hangileri değil?
Tüm stoğu aynı riskle yönetmek, hem gereksiz panik hem de yanlış yerde rehavet üretir. Risk dağılımını kaba hatlarla şöyle çizebilirsin: cüzdan yükleme kodları en güvenli grupta durur, çünkü bunlar içeriğe değil bakiyeye bağlanır ve bakiye güncellemeden bağımsız yaşar. Buna karşılık etkinliğe bağlı ürünler, güncellemeyle birlikte biten bir pencerenin içinde yaşar.
Arada kalan grup ise bölge kilitli kodlar. Bunlar bugün çalışır, yarın yayıncı bölge politikasını sıkılaştırdığında çalışmaz; ayrıca çalıştığında bile hesabın bölgesiyle uyuşmazsa kullanıcıya geçersiz görünür. Bu yüzden bölge kilitli stoğu ürün sayfasında açık açık etiketlemek, sonradan gelecek iade talebinin en ucuz sigortasıdır. Aşağıdaki tablo, stok planlamasını risk grubuna göre nasıl kurman gerektiğini özetliyor.
| Kod tipi | Sürüm riski | Önerilen stok süresi | Zorunlu etiket |
|---|---|---|---|
| Cüzdan / bakiye yükleme | Çok düşük | Serbest | Yok |
| Kalıcı içerik (kostüm, karakter) | Düşük | 60-90 gün | Platform |
| Sezon geçişi / battle pass | Yüksek | Sezon bitişine 10 gün | Sezon numarası |
| Etkinliğe bağlı paket | Çok yüksek | Etkinlik bitişine 5 gün | Geçerlilik tarihi |
| Bölge kilitli kod | Orta-yüksek | 30-45 gün | Bölge |
| Kampanya / promosyon kodu | Yüksek | Tarihine 7 gün | Son kullanma |
Güncelleme günü ilk 72 saatte ne yapmalısın?
Sürüm riskinin işletmeye zarar verdiği yer stok değil, destek yükü. Güncelleme yayına girdikten sonraki üç gün, gelen şikayetlerin yoğunlaştığı penceredir ve bu pencerede yapılacak iş sırası bellidir. İlk hamle satışı durdurmak değil, doğrulamaktır: risk grubundaki her üründen tek bir kodu kendi test hesabında dene. Beş dakikalık bu iş, on kişiye yanlış cevap vermeni engeller.
İkinci hamle, doğrulama sonucuna göre ürünü tamamen kapatmak yerine kısmi kapatmak. Yani etkilenen varyantı satıştan çekip diğerlerini açık tutmak. Bütün kategoriyi kapatan satıcı, riski sıfırlarken cirosunu da sıfırlar. Üçüncü hamle, aynı ürünü daha önce satın almış müşterilere proaktif bilgi göndermek: "bu güncellemeyle şu paket kullanımdan kalktı, elinde kullanılmamış kod varsa bize yaz." Bu mesajı sen göndermezsen aynı bilgi sana şikayet olarak geri gelir.
Dördüncü hamle ise tedarikçi tarafı. Sürüm kaynaklı geçersizlikte iade hakkının ne olduğu, tedarik sözleşmesinin en az bakılan ama en pahalı maddesidir. Yazılı bir iade penceresi yoksa, risk tamamen sende kalır.
Güncelleme sonrası gelen "kod çalışmıyor" şikayetlerinin gerçek nedenleri
- Kullanıcı hatası (yanlış hesap, yanlış alan, boşluk) 45%
- Bölge veya platform uyuşmazlığı 25%
- Ürünün sürümle kataloğdan düşmesi 20%
- Gerçekten bozuk veya kullanılmış stok 10%
Bu riski elle takip etmek neden matematiksel olarak imkansız?
Yirmi ürünle çalışıyorsan takvimi kafanda tutabilirsin. İki yüz ürün, altı yayıncı ve her yayıncının ayrı sürüm takvimi devreye girdiğinde bu iş insan hafızasının kapasitesini aşar. Çünkü takip etmen gereken şey ürün sayısı değil, ürün ile tarih çarpımıdır. Bu yüzden sürüm riski, disiplin meselesi değil otomasyon meselesidir.
Otomasyonun çekirdeği tek bir veri alanı: stok kaydına yazılan geçerlilik tarihi. Bu alan varsa gerisi kendiliğinden gelir. Tarihe on gün kalan stok için uyarı üretirsin, tarihi geçen stok otomatik satıştan düşer, tarihi yaklaşan stok öncelikli olarak teslim kuyruğunun başına alınır. Yani ilk giren ilk çıkar yerine ilk bozulan ilk çıkar kuralına geçersin; gıda perakendesinin yüz yıldır yaptığı şeyi dijital stoğa uygularsın.
İkinci katman, kod tipine göre otomatik davranış. Etkinlik kodu satıldığında müşteriye "bu kodu 48 saat içinde kullan" uyarısı gönderilmesi, bölge kilitli kod satıldığında bölge bilgisinin teslim ekranında tekrar gösterilmesi gibi kurallar, şikayet hacmini doğrudan düşürür. Kullandığın dijital ürün satış yazılımı stok kaydında tip ve tarih taşımıyorsa bu kuralları yazacak zemin yok demektir; altyapı özelliklerini değerlendirirken önce bu iki alana bak.
Riskli gruptaki ürünlerde teslim ekranına tek satırlık bir not düşmek çok işe yarar: "Bu kod mevcut sezon içinde kullanılmalıdır." Bu cümle, sonradan açılacak ihtilafta senin lehine kanıt olur ve destek yazışmasını kısaltır.
Sürüm riskini yönetenle yönetmeyen arasındaki fark nerede görünür?
Fark ciroda değil, iade oranında ve destek süresinde görünür. Sürüm takvimini takip eden satıcı riskli stoğu erken eritir, geçersiz kod satmadığı için iade açmaz, şikayet geldiğinde neden olduğunu bir bakışta görür. Takip etmeyen satıcı ise ay sonunda "neden marjım eridi" sorusuna cevap bulamaz; çünkü kayıp tek kalemde değil, iade, destek saati ve itibar olarak üçe bölünmüştür.
Aşağıdaki kontrol listesi, sürüm riskine karşı kurman gereken asgari düzeni gösteriyor. Bunların çoğu tek seferlik kurulum işidir; bir kere ayarlandığında her güncellemede yeniden uğraşmazsın.
| Kontrol maddesi | Sıklık | Kim yapar |
|---|---|---|
| Stok kaydında geçerlilik tarihi alanı | Tek seferlik kurulum | Yönetici |
| Kod tipi etiketleme (cüzdan / etkinlik / bölge) | Ürün eklerken | Operasyon |
| Tarihi yaklaşan stok uyarısı | Otomatik, günlük | Sistem |
| Yayıncı sürüm takvimi takibi | Haftalık | Satın alma |
| Riskli üründen test kodu doğrulama | Her güncelleme günü | Operasyon |
| Etkilenen varyantı kısmi kapatma | Gerektiğinde | Operasyon |
| Geçmiş alıcılara proaktif bildirim | Gerektiğinde | Destek |
| Tedarikçi iade penceresi maddesi | Sözleşme yenilemede | Yönetici |
Stoğun ömrünü yazılım takip etsin, sen değil
Geçerlilik tarihi, kod tipi etiketleri, tarihi yaklaşan stok uyarıları ve kısmi varyant kapatma Pinova'da standart gelir. Riskli stoğu unuttuğun için değil, planladığın için eritirsin. Paketleri karşılaştır.
Cüzdan yükleme kodları güncellemeyle bozulur mu?
Pratikte çok nadir. Bu kodlar içeriğe değil bakiyeye bağlandığı için oyunun sürüm değişikliklerinden etkilenmez. Bozulma riski daha çok yayıncının bölge politikası değiştiğinde ya da kod serisi için tanımlı bir son kullanma tarihi olduğunda ortaya çıkar. Bu yüzden cüzdan kodlarında bile seri bazlı tarih bilgisini tedarikçinden istemek doğru olur.
Geçersiz çıkan kodda müşteriye iade zorunlu mu?
Ürün taahhüt edilen işlevi yerine getirmiyorsa ayıplı ifa söz konusudur ve iade ya da değişim beklenir. Bu yüzden çözüm sırası önemlidir: önce kullanım hatası mı diye doğrula, değilse aynı değerde ikame kod ver, ikame yoksa iade et. İkame önerisi, iade oranını belirgin biçimde düşürür.
Sürüm takvimini nereden takip edebilirim?
Yayıncıların resmi duyuru kanalları, sezon bitiş sayaçları ve bayi panellerindeki katalog güncelleme bildirimleri ilk kaynaktır. Bunları takvime işleyip stok kaydındaki geçerlilik tarihiyle eşlemek, takibi haftalık on beş dakikalık bir işe indirir.
Riskli stoğu erken eritmek için indirim şart mı?
Şart değil. Çoğu zaman ürünü vitrinde öne almak, paket içine eklemek ya da teslim kuyruğunda önceliklendirmek yeterli olur. İndirim son adımdır; marj kaybı, geçersiz kalan stoğun tam kaybından hâlâ iyidir ama ilk seçenek olmamalıdır.
Oyun güncellemesi senin kontrol edemediğin bir dış olaydır; elindeki stoğun o olaya nasıl tepki verdiği ise tamamen senin kurduğun düzenin sonucudur. Geçerlilik tarihi taşıyan bir stok kaydı, kod tipine göre davranan bir teslim akışı ve varyant bazlı kapatma yeteneği, sürüm riskini krizden rutine indirir. Bu üç mekanizmanın gerçek bir panelde nasıl göründüğünü denemek istersen canlı demo içinde tarihli bir stok kalemi oluşturup uyarının nasıl tetiklendiğini kendin görebilirsin.