Path of Exile para birimi satışına giren çoğu işletme bunu en kolay dijital ürün sanır: stok fiziksel değil, teslimat oyun içinde saniyeler sürüyor, marj yüksek görünüyor. Birkaç yüz sipariş sonra tablo değişir. Kur bir gecede düşer, tedarikçi teslim edemez, alıcı "eksik geldi" der, bir hesap askıya alınır ve tüm zincirin faturası sana çıkar. Sorun ürünün kendisi değil; ürünün hiçbir yerde tutulmayan kaydıdır.
Bu yazıda currency satışının gerçekte hangi noktalarda para kaybettirdiğine bakıyoruz: teslimatın neden ekran görüntüsüyle kanıtlanamadığı, lig başlangıcında kurun neden bu kadar hızlı eridiği, hesap askıya alınmasında sorumluluğun nasıl paylaştırılacağı ve stok-kur-tedarikçi üçlüsünü aynı ekranda görmezsen kârının neden sahte olduğu. Hepsini bir e-pin satış scripti disiplinine çevirerek anlatıyoruz, çünkü çözüm daha dikkatli olmak değil, akışı sisteme bağlamaktır.
Currency satışı gerçekten "ürün satışı" mı, yoksa buluşma hizmeti mi?
Teknik olarak sattığın şey bir stok kalemi gibi görünür: belirli miktar para birimi, belirli fiyat. Operasyonel olarak ise yaptığın iş bir randevu yönetimidir. Alıcının oyunda olması, aynı ligde ve doğru sunucuda bulunması, ticaret talebini kabul etmesi gerekir. Bu üç koşuldan biri sağlanmazsa sipariş "teslim edilmemiş" olarak kalır ama senin maliyetin çoktan oluşmuştur.
Bu ayrımı kabul etmeyen satıcılar iki şeyi yanlış kurar: teslim süresi taahhüdünü gerçekçi vermez ve alıcının sorumluluğunu tanımlamaz. Doğru kurulum şudur: ürün sayfasında teslim penceresi net yazılır, alıcıdan oyun içi karakter adı ve lig bilgisi sipariş anında zorunlu alan olarak toplanır, alıcı hazır olmadığında sipariş beklemede kalır ve bu durum kayda geçer.
Böylece "geç teslim" tartışması objektif bir zemine oturur. Kimin beklettiği görünür hale gelir; bu da hem iade taleplerini hem yorum puanını doğrudan etkiler.
Ticaret anı: teslimatın kanıtı ekran görüntüsü değildir
Sektörde en yaygın alışkanlık, ticaret ekranının fotoğrafını çekip klasöre atmaktır. Bu, kendini iyi hissettiren ama işe yaramayan bir kanıttır; çünkü taraflı, doğrulanamaz ve sipariş kaydıyla bağı yoktur. Ödeme itirazında sana sorulan soru "fotoğrafın var mı" değil, "bu siparişin teslim edildiğini sistem kaydıyla gösterebiliyor musun" olur.
İşe yarayan yapı şudur: siparişe bağlı bir teslim onayı adımı, zaman damgası, teslimatı yapan operatörün kimliği, teslim edilen miktar ve alıcının panelden verdiği onay. Bu beş veri bir arada olduğunda anlatı biter, dosya konuşur. Ek olarak operatör bazlı kayıt, iç kaynaklı kayıpları da ortaya çıkarır; birden fazla kişiyle çalışıyorsan bu tek başına yazılım maliyetini karşılar.
Bu yüzden currency satan bir işletmenin altyapısı, sıradan bir sepet yazılımı değil, teslimat ve kanıt üretmeye odaklı bir dijital ürün satış yazılımı olmalıdır.
| Risk | Tetikleyici | Görünen etki | Gerçek maliyet | Panelde karşılığı |
|---|---|---|---|---|
| Kur çöküşü | Lig ilk haftası | Fiyat yüksek kalır | Stok değer kaybı | Kur bazlı fiyat güncelleme |
| Teslim gecikmesi | Alıcı çevrimdışı | Kötü yorum | Yeniden pazarlama kaybı | Beklemede durumu ve kayıt |
| Miktar itirazı | Kayıt yokluğu | Kısmi iade | Marj erimesi | Teslim miktarı onayı |
| Hesap askıya alma | Şüpheli ticaret | Alıcı öfkesi | İtibar + iade | Yazılı sorumluluk onayı |
| Tedarikçi iflası | Tek kaynağa bağımlılık | Stok bitişi | Satış durması | Çoklu tedarikçi maliyet izi |
| Operatör kaynaklı kayıp | Denetimsiz teslim | Açıklanamayan fark | Doğrudan zarar | Operatör bazlı işlem logu |
Lig başlangıcı kuru neden 48 saatte çöküyor?
Yeni lig açıldığında talep patlar, arz henüz kısıtlıdır ve birim fiyat tepe yapar. İlk günlerde çiftçilik hızlanınca arz sel gibi gelir ve kur hızla düşer. Sabit fiyatla ilerlersen iki yönden de kaybedersin: tepe noktada olduğundan ucuza satarsın, düşüş başladığında pahalı kaldığın için hiç satamazsın.
Yapılacak iş fiyatı maliyet + hedef marj formülüne bağlamak ve maliyeti tedarik kaydından okumaktır. Manuel takipte bu, günde birkaç kez tablo güncellemek demek; sistemde ise bir kural. Ayrıca stoğu vade gibi düşünmek gerekir: elinde bekleyen currency her saat değer kaybediyorsa, stok tutma süresi bir maliyet kalemidir.
Burada çoğu satıcının atladığı ayrıntı şu: kâr hesabını ortalama maliyetle değil, parti bazlı maliyetle yapmak gerekir. Aksi halde yüksekten aldığın partiyi düşük fiyattan satıp kâr ettiğini sanırsın.
Currency satışında marj kaybının kaynakları
- Kur dalgalanması 50%
- İade ve itirazlar 25%
- Operasyon/teslimat süresi 15%
- Ödeme komisyonları 10%
Hesap askıya alınırsa suçlu kim olur?
Bu, currency işinin en hassas noktası. Alıcının hesabında bir kısıtlama olduğunda ilk bakılan yer son yapılan ticaretlerdir ve alıcı doğal olarak sorumluyu sende arar. Sen de teknik olarak sadece bir buluşma sağladın; oyun içindeki kararlar senin kontrolünde değil. Ama bu savunma, yazılı bir çerçeve yoksa hiçbir işe yaramaz.
Yapılması gereken üç şey var. Birincisi, ürün sayfasında değil ödeme onay adımında alıcının kabul ettiği açık bir sorumluluk metni bulundurmak. İkincisi, teslim sonrası uygulanması gereken davranış önerilerini aynı ekranda vermek. Üçüncüsü, askıya alma vakalarını ayrı bir başlıkta kaydedip tedarikçi ve operatör bazında oranını izlemek. Üçüncü madde en sıkıcı olanı ama en değerlisi: belirli bir kaynakta oran yükseldiğinde sorunun kaynağını bulmuş olursun.
Pinova tam bu noktada devreye giriyor: kendisi para birimi ya da e-pin satmaz; bunları satan işletmelerin kullandığı yazılımı sunar. Sipariş bazlı onay kayıtları, teslim onayı, tedarikçi maliyet izi ve ayrı iade kuyruğu hazır gelir. Modül listesini özellikler bölümünde görebilirsin.
Teslim edilen miktarı alıcıya panelden onaylattırmadan siparişi kapatma. Bu tek adım, miktar itirazlarının neredeyse tamamını ortadan kaldırır ve iade oranını gözle görülür biçimde düşürür.
Stok, kur ve tedarikçi: üçünü aynı panelde görmezsen kâr sahte
Currency işinde en tehlikeli durum, cironun artarken kasanın erimesidir. Bunun nedeni neredeyse her zaman aynıdır: satış bir yerde, tedarik maliyeti başka yerde, iade kaydı üçüncü bir yerde tutulur. Üç veri birleşmediği için birim başına gerçek kâr hiçbir zaman hesaplanmaz.
Birleşik görünüm sana şunları verir: ürün bazlı net marj, tedarikçi bazlı iade oranı, operatör bazlı teslim süresi ve dönem bazlı kur etkisi. Bu dört rakamı gördüğün gün alacağın kararlar değişir; genelde ilk karar bazı ürünleri kapatmak, ikincisi bazı tedarikçileri elemek olur. İkisi de büyümeyi hızlandırır.
Ölçek büyüdükçe manuel yöntem yalnızca yorucu değil, yanıltıcı hale gelir. Bu yüzden currency ve e-pin satan işletmeler belli bir noktadan sonra kendi tablolarını bırakıp bir e-pin yazılımı altyapısına geçer. Paket farklarını ve limitleri fiyat bölümünde karşılaştırabilirsin.
Script tarafında hangi kayıtlar seni koruyor?
Somut liste kısa: sipariş anında toplanan karakter ve lig bilgisi, ödeme adımında onaylanan sorumluluk metni, teslim miktarının alıcı onayı, operatör kimliğiyle işlem logu, tedarikçi ve parti bazlı maliyet kaydı, askıya alma vakaları için ayrı etiket. Altı kalem. Hepsi bir arada olduğunda hem itirazları kazanırsın hem kârını gerçekten bilirsin.
Bu altı kalemi kurmanın maliyeti bir kez ödenir; kurmamanın maliyeti her ay ödenir. Currency işinde marj zaten ince olduğu için, kaybı kayıt tutmayarak finanse eden işletmeler uzun süre ayakta kalamaz.
| Kontrol | Koruduğu risk | Kurulum zorluğu |
|---|---|---|
| Karakter ve lig alanı zorunlu | Teslim gecikmesi | Düşük |
| Ödeme adımında sorumluluk onayı | Askıya alma tartışması | Düşük |
| Alıcı onaylı teslim miktarı | Miktar itirazı | Orta |
| Operatör bazlı işlem logu | İç kaynaklı kayıp | Orta |
| Parti bazlı maliyet kaydı | Sahte kâr | Orta |
| Tedarikçi iade oranı raporu | Kötü kaynak | Orta |
| Ayrı iade kuyruğu | Yanıt süresi | Düşük |
Marjını tahminle değil kayıtla koru
Teslim onayı, parti maliyeti, operatör logu ve tedarikçi raporu tek panelde. Pinova'yı kendi currency kataloğunla dene.
Teslimatı ekran görüntüsüyle kanıtlamak yeterli mi?
Değil. Ekran görüntüsü taraflı ve doğrulanamaz bir kanıttır. İşe yarayan şey siparişe bağlı, zaman damgalı ve alıcı onaylı bir teslim kaydıdır; itiraz dosyalarında yalnızca bu tür kayıtlar ağırlık taşır.
Lig başında fiyatı ne sıklıkla güncellemeliyim?
İlk hafta günde birkaç kez, sonrasında günlük yeterli olur. Önemli olan sıklık değil, fiyatın parti maliyetine bağlı bir formülden gelmesi; sabit fiyat hem tepe noktada hem düşüşte zarar ettirir.
Alıcının hesabı kısıtlanırsa iade vermek zorunda mıyım?
Politikanı ödeme adımında onaylanmış bir metinle belirlemişsen zorunda değilsin. Yine de vakaları kaydedip tedarikçi ve operatör bazında oranını izlemen gerekir; oran belirli bir kaynakta yükseliyorsa sorun sende değil o kaynaktadır.
Aynı yazılımda e-pin ve currency birlikte yönetilir mi?
Yönetilir. İkisi de dijital teslimat mantığıyla çalışır; fark teslimat tipinde ve kanıt gereksinimindedir. Ürün sınıfı bazında farklı teslimat akışı ve iade politikası tanımlanabiliyorsa tek panel yeterlidir.
Path of Exile para birimi satışında uzun vadede ayakta kalanlar en ucuz satanlar değil, her siparişin arkasında bir kayıt bırakanlar oluyor. Teslim onayı, parti maliyeti ve sorumluluk metni üçlüsünü kurduğun gün hem itirazların hem tartışmaların büyük kısmı sessizce kayboluyor. Bu akışın pratikte nasıl göründüğünü merak ediyorsan canlı demo üzerinde bir currency ürünü tanımlayıp teslim onayı adımını kendin dene; kayıt disiplininin ne kadar az efor istediğini göreceksin.