Bölge kilidi konusunda yaygın bir yanlış inanç var: satıcılar bunu bir ürün özelliği sanır. Aslında bölge kilidi bir iletişim yükümlülüğüdür. Kod teknik olarak kusursuz olabilir, tedarikçin güvenilir olabilir, fiyatın rekabetçi olabilir; müşteri ürünü kendi hesabında kullanamıyorsa senin için sonuç tek kelimeyle aynıdır: iade.
Daha can sıkıcısı şu: bu iadelerin büyük kısmı "yanlış ürün sattın" diye gelmez, "bunu bana söylemedin" diye gelir. Ve haklıdırlar. Ürün sayfasının bir köşesine gri renkle yazılmış tek satır, hukuki olarak da ticari olarak da bilgilendirme sayılmaz. Bu yazıda bölge kilidini satış öncesi, satış anı ve satış sonrası olmak üzere üç aşamada nasıl yöneteceğini; bir dijital ürün satış scriptinin bu işi senin adına neresinden tutması gerektiğini konuşacağız.
Bölge kilidi tek bir şey değil: sattığın kilidi tanıyor musun?
Satıcıların çoğu her kısıtı "bölge kilitli" diye etiketler ve orada bırakır. Oysa sahada en az dört farklı kısıt tipi dolaşır. Aktivasyon kilidi, kodun yalnızca belirli ülkedeki bir hesapta kullanılabilmesidir. Oyun/servis kilidi, kod girildikten sonra içeriğin o bölgede çalışmasıdır. Para birimi kilidi, cüzdan bakiyesinin hesabın kuruluş para birimiyle uyuşması zorunluluğudur. IP/coğrafi doğrulama ise aktivasyon anında bağlantının nereden geldiğine bakar.
Bunlar birbirinin yerine geçmez. Bir kod ülke A'da aktive edilebilirken içeriğin ülke B'de oynanması serbest olabilir. Müşteriye "Türkiye bölgesi" demek, bu dört boyuttan hangisini kastettiğini anlatmaz. İyi bir e-pin satış yazılımı ürün kaydında bu boyutları ayrı alanlar olarak tutar; tek bir serbest metin kutusuna sıkıştırmaz. Alanlar ayrı olduğunda ürün sayfasındaki uyarı otomatik ve tutarlı üretilir, her ürünü elle yazmaktan kurtulursun.
| Kısıt tipi | Ne kilitler | Müşterinin sorması gereken | Ürün kartında yazılacak |
|---|---|---|---|
| Aktivasyon kilidi | Kodun girilebileceği hesabın ülkesi | Hesabım hangi ülkede kurulu? | Yalnızca TR hesaplarda aktive edilir |
| Servis/içerik kilidi | İçeriğin çalışacağı bölge | Bulunduğum yerde açılır mı? | TR sunucularda geçerli |
| Para birimi kilidi | Cüzdan/bakiye uyumu | Hesabımın para birimi ne? | Hesap para birimi TRY olmalı |
| IP/coğrafi doğrulama | Aktivasyon anındaki bağlantı | VPN kullanmam gerekir mi? | TR bağlantısı gerekebilir |
| Global (kısıtsız) | Hiçbir şey | — | Tüm bölgelerde geçerli |
Ürün açıklamasına yazmak niye yeterli değil?
Bir müşteri ürün sayfasında ortalama on bir saniye geçirir ve bu sürede başlığa, fiyata ve butona bakar. Açıklama metninin üçüncü paragrafındaki kritik bilgi pratikte okunmamış bilgidir. Bunu müşterinin dikkatsizliği diye geçiştirmek kolay ama fatura sana gelir.
Bilgilendirmenin işe yaraması için kararın verildiği yere taşınması gerekir: sepete ekleme anına ve ödeme adımına. Bölge kısıtı olan ürünler için sepette ayrı bir uyarı bandı, ödeme öncesinde ise "bu kodun yalnızca TR hesaplarda çalıştığını anladım" gibi işaretlenmesi zorunlu bir onay kutusu doğru kurgudur. Bu kutu müşteriyi caydırmaz; aksine kararını netleştirdiği için iade riski düşer.
Önemli nokta, bu akışın ürün bazında koşullu çalışmasıdır. Global ürünlerde ek adım çıkmaz, kısıtlı ürünlerde çıkar. Pinova'da bölge alanı doldurulmuş ürünler sepette ve ödeme adımında otomatik olarak bu onayı ister; özellikler tarafında bunun nasıl kurgulandığını tek tek görebilirsin.
Peki onay kutusu gerçekten seni koruyor mu?
Koruyor, ama yalnızca kaydı tutuluyorsa. Ekranda görünüp hiçbir yere yazılmayan onay kutusu, itiraz dosyasında hiçbir şey ifade etmez. Ödeme sağlayıcısına veya tüketici tarafına sunacağın şey şudur: hangi sipariş, hangi saatte, hangi metni onaylamış.
Bu yüzden onay kaydı siparişe bağlı olmalı ve onaylanan metnin tam hali arşivlenmeli. Metni altı ay sonra değiştirirsen eski siparişte gösterilen eski metin duruyor olmalı. Bunu "onay: evet" şeklinde tek bayrakla tutan sistemler işe yaramaz, çünkü neyin onaylandığını kanıtlamaz. Kurumsal bir epin yazılım altyapısı bu kaydı sürüm damgasıyla saklar.
Ek olarak teslim e-postasının gövdesinde de kısıt bilgisi tekrar etmeli. Müşteri kodu kullanmadan önce son bir kez uyarılmış olur; sen de "bilgilendirme üç ayrı noktada yapıldı" diyebilir hale gelirsin. Tek noktada uyarı savunma değildir, tekrarlanan uyarı savunmadır.
Bölge kaynaklı taleplerin çıkış noktası
- Hesap ülkesi farklı 40%
- Para birimi uyuşmazlığı 30%
- VPN/IP doğrulaması 20%
- Yanlış platform seçimi 10%
Müşteri yanlış bölgeden geliyorsa satışı engellemek mi, uyarmak mı?
Burada satıcılar iki uca savrulur. Bir kısım hiçbir şey yapmaz, satar, sonra tartışır. Bir kısım ise agresif biçimde bölge dışı ziyaretçiye ürünü gizler ve gerçek satışları kaybeder. Doğru yol ortada: engelleme değil, hedefli uyarı.
Ziyaretçinin bağlantı ülkesi ürünün kısıtıyla uyuşmuyorsa sayfada belirgin ama saygılı bir bilgi çıkar: "Bu kod TR hesaplar için. Hesabın farklı bir ülkede kuruluysa çalışmayacaktır." Satın almayı yasaklamazsın, çünkü müşteri seyahatte olabilir veya hesabı gerçekten TR olabilir. Ama karar sorumluluğunu bilinçli biçimde ona devretmiş olursun.
İkinci adım, doğru alternatifi hemen yanına koymaktır. Bölge dışı ziyaretçiye uygun bölge sürümü veya global sürüm varsa öneri olarak gösterilmeli. Böylece uyarı bir kayıp değil, doğru ürüne yönlendirme aracı olur. Bu tür koşullu görünüm kuralları modern bir e-pin scripti içinde katalog seviyesinde tanımlanır, her sayfaya elle kod yazmayı gerektirmez.
Ürün adının sonuna köşeli parantezle bölge eklemek destek yükünü tek hamlede düşürür: arama sonucunda, sepette ve e-postada aynı bilgi görünür. Başlıkta duran bilgi, okunmadı denilemeyen bilgidir.
Bölge kilidi olan ürünü hiç satmamak daha mı kârlı?
Bazı satıcılar iade yükünden bıkıp bölge kilitli ürünleri katalogdan çıkarır. Bu çoğu zaman yanlış bir optimizasyondur, çünkü fiyat avantajının kaynağı tam olarak o kısıttır. Bölge kilitli kodlar genellikle daha iyi marj bırakır; asıl mesele marjı destek maliyetiyle yakmamaktır.
Karar vermenin sağlıklı yolu ürün bazlı bir hesap tutmaktır: bu SKU'nun iade oranı, destek dokunuşu başına süresi ve net marjı. Bilgilendirme akışını düzelttikten sonra iade oranı hâlâ kabul edilemez seviyedeyse o ürünü bırakırsın; ama bunu duyguyla değil veriyle yaparsın. Fiyat tarafında ürün bazlı iade ve destek raporlaması olan bir plan seçmek bu kararı mümkün kılar.
Unutma: kısıtı iyi anlatan satıcı, kısıtı olan üründe bile rakiplerinden daha az iade alır. Fark ürün değil, anlatım.
| Kontrol maddesi | Nerede uygulanır | Amaç | Öncelik |
|---|---|---|---|
| Bölge bilgisi ürün başlığında | Katalog, arama, sepet | Görünmezliği bitirir | Yüksek |
| Kısıt tipleri ayrı alanlarda | Ürün yönetimi | Tutarlı metin üretimi | Yüksek |
| Sepette uyarı bandı | Sepet ekranı | Karar anında görünürlük | Yüksek |
| Zorunlu onay kutusu | Ödeme adımı | Bilinçli rıza | Yüksek |
| Onaylanan metnin arşivi | Sipariş kaydı | İtirazda kanıt | Yüksek |
| Teslim mailinde tekrar uyarı | E-posta şablonu | Son savunma katmanı | Orta |
| Bölge dışı ziyaretçiye alternatif | Ürün sayfası | Kaybı satışa çevirir | Orta |
| SKU bazlı iade raporu | Yönetim paneli | Veriyle ürün kararı | Orta |
Bölge kısıtını iade sebebi olmaktan çıkar
Kısıt alanları, koşullu uyarılar, arşivlenen onay kayıtları ve SKU bazlı iade raporu bir arada. Pinova ile bilgilendirmeyi sisteme yaptır.
Bölge bilgisini ürün başlığına yazmak dönüşümü düşürür mü?
Pratikte düşürmez, niteliği artırır. Doğru bölgedeki müşteri zaten satın alır; yanlış bölgedeki müşteriyi baştan filtrelemek ise sana iade ve destek maliyeti olarak geri dönmeyen bir kazançtır.
Onay kutusu tüketici hakkından feragat anlamına gelir mi?
Hayır. Onay kutusu müşterinin yasal haklarını ortadan kaldırmaz; yalnızca bilgilendirmenin yapıldığını kanıtlar. Bu ayrımı metinde net tutmak hem dürüst hem de daha güçlü bir duruştur.
Müşteri VPN ile aktive ederse sorumluluk kimde?
Ürün açıklamasında VPN gereksinimi veya yasağı açıkça yazılıysa sorumluluk kullanıcıdadır. Yazılı değilse tartışmayı büyük olasılıkla kaybedersin; bu yüzden IP doğrulaması gerektiren ürünleri ayrı etiketlemek gerekir.
Aynı ürünün farklı bölge sürümlerini nasıl yönetmeliyim?
Her bölgeyi ayrı SKU olarak tut, tek üründe seçenek olarak değil. Böylece stok, fiyat, iade oranı ve uyarı metni birbirine karışmaz; müşteri de sepette hangi sürümü aldığını net görür.
Bölge kilidi satılamayacak bir özellik değil, yalnızca doğru anlatılması gereken bir gerçektir. Kısıtı ürün kaydında yapılandırır, uyarıyı karar anına taşır, onayı kanıtlanabilir biçimde saklarsan aynı ürün hem daha iyi marj hem daha az tartışma getirir. Bu akışın uçtan uca nasıl çalıştığını görmek için canlı demo içinde bölge alanı dolu bir ürün oluştur ve sepete ekleyip ödeme adımına kadar ilerle; uyarının nerede çıktığını ve onayın nereye yazıldığını birkaç dakikada anlarsın.