Bir tedarikçiyle ilk kez kod sorunu konuştuğunda duyacağın cümle neredeyse ezberdir: “Stok sağlam, hata müşteride.” Çoğu işletme sahibi de buna inanır. Reddedilen her kodu üst kaynağın kusuru sanır, destek ekibine “tedarikçiyle görüşüyoruz” mesajını yazdırır, konuyu kapatır. Oysa kendi kayıtlarını tarih, saat ve sipariş kırılımında açıp incelemeye başladığın anda tablo tersine döner: reddedilen kodların büyük bölümü aslında geçerlidir; sadece yanlış kişiye, yanlış bölgeye ya da yanlış biçimde ulaşmıştır.
Yani sorun genelde kodun kendisinde değil, kodun müşteriye kadar geçtiği zincirin içindedir. O zinciri kuran şey de senin kullandığın altyapıdır: hangi e-pin scripti üzerinde çalışıyorsun, stok nereden düşüyor, teslimat hangi anda tetikleniyor, aynı kod iki kez okunabiliyor mu. Aşağıda sahada en sık rastlanan dokuz sebebi tek tek açacağım ve her birinin altında “bunu yazılım tarafında nasıl kapatırsın” sorusuna cevap vereceğim.
Kod gerçekten bozuk mu, yoksa senin teslimat zinciri mi kırık?
Bir müşteri “kod çalışmıyor” yazdığında iki ihtimal vardır: ya kod ölü, ya da kod müşteriye ulaşırken bozulmuş. İkinci ihtimal hep hafife alınır. Oysa WhatsApp üzerinden yapıştırılan bir kodun sonundaki boşluk, panelden kopyalanırken araya giren satır sonu karakteri, ekran görüntüsünde 0 ile O harfinin karışması — bunların hepsi “geçersiz kod” olarak geri döner. Platform tarafında kodun kaydı canlıdır, ama müşterinin elindeki metin artık o kod değildir.
Bunu ölçmenin en hızlı yolu, teslimat kanalını tek noktaya indirmektir. Kod sadece sipariş sayfasında, tek tıkla kopyalanabilir bir alanda görünüyorsa insan hatası neredeyse sıfıra iner. Düzgün bir dijital ürün satış scripti kodu ekrana basmakla yetinmez; kopyalama butonu koyar, boşlukları temizler, kodu maskeleyip sadece yetkili oturuma açar. Pinova’da teslimat ekranının tek kanal olarak tasarlanmasının sebebi tam olarak budur: kodu insan eli taşımadığında bozulmaz.
Bölge kilidi: aynı kodun iki ülkede iki ayrı kaderi var
Reddedilen kodların en sinir bozucu grubu bölge uyuşmazlığıdır. Kod tamamen geçerlidir, ama başka bir pazara basılmıştır. Müşteri hesabı Türkiye bölgesindeyse Avrupa stoklu bir kodu yükleyemez; platform da açıklayıcı bir hata vermez, sadece “bu kod kullanılamaz” der. Sen de tedarikçiyle karşılıklı suçlama turuna girersin.
Çözüm, stoğu bölgeye göre ayrıştırmaktan geçer. Ürün kartında tek bir havuz tutuyorsan bu hatayı asla engelleyemezsin. Bölge, para birimi ve platform kırılımını ürün varyantı seviyesinde tanımlamak zorundasın. Kullandığın e-pin satış yazılımı varyant bazlı stok desteklemiyorsa, her satışta kumar oynuyorsun demektir. Üstüne bir de ürün sayfasında görünür bir bölge uyarısı koyarsan iade taleplerinin ciddi bir kısmı zaten oluşmadan biter.
| # | Ret sebebi | Görülme sıklığı | Asıl kusur nerede | Yazılım tarafında çözümü |
|---|---|---|---|---|
| 1 | Kopyalama hatası / boşluk karakteri | Çok yüksek | Teslimat kanalı | Tek tık kopyalama + otomatik trim |
| 2 | Bölge uyuşmazlığı | Yüksek | Stok kurgusu | Varyant bazlı bölge etiketi |
| 3 | Kod daha önce kullanılmış | Yüksek | Çift teslimat | Tek seferlik kilit + durum damgası |
| 4 | Süresi dolmuş stok | Orta | Depo yönetimi | Son kullanma tarihi alanı + uyarı |
| 5 | Yanlış ürün eşleşmesi | Orta | Katalog | SKU kilidi, serbest atama yok |
| 6 | Hesap tipi uyumsuzluğu | Orta | Ürün açıklaması | Zorunlu ön onay kutusu |
| 7 | Platform tarafı geçici arıza | Düşük | Dış kaynak | Durum notu + otomatik tekrar dene |
| 8 | Tedarikçi iptali / geri çağırma | Düşük | Üst kaynak | Parti (batch) takibi |
| 9 | Kötü niyetli iade talebi | Düşük | Müşteri | Görüntüleme logu + IP kaydı |
Tek kod iki müşteri: çift teslimatın sessiz matematiği
Bu, küçük işletmeleri en çok yaralayan kalemdir ve genelde fark edilmez. Aynı kod iki siparişe düşer; ilk müşteri sorunsuz kullanır, ikinci müşteri “kod kullanılmış” hatası alır. Sen ikinci müşteriye yeni kod verirsin, yani o satıştan kâr etmek yerine bir kod bedeli daha ödersin. Ay sonunda kasan tutmaz ama sebebini bulamazsın.
Çift teslimatın kaynağı neredeyse her zaman aynıdır: stok düşümü ile teslimat aynı işlemde kilitlenmemiştir. Ödeme onayı geldiğinde kod satırı atomik biçimde rezerve edilmeli, durumu anında “teslim edildi” olarak damgalanmalı ve bir daha hiçbir sorguda görünmemelidir. Excel ile stok tutan, kodu elle yapıştıran bir akışta bunu garanti etmen imkânsızdır. Sağlam bir epin yazılım mimarisi bu kilidi veritabanı seviyesinde kurar, kullanıcı arayüzüne güvenmez.
Ret vakalarının gerçek kaynak dağılımı
- Teslimat ve stok kurgusu 45%
- Bölge ve ürün eşleşmesi 25%
- Müşteri kaynaklı hata 20%
- Üst kaynak / platform 10%
Süresi geçmiş stok: depoda bekleyen kodun sessiz ölümü
Toplu alımda indirim cazip gelir, sen de fazladan kod alırsın. Sonra kampanya döner, o ürün yavaşlar ve kodlar depoda bekler. Bazı ürün ailelerinde kodların basım tarihine bağlı geçerlilik sınırı olur; sınır dolduğunda kod sessizce ölür. Kimse sana haber vermez, sen de aylar sonra satmaya çalışırken öğrenirsin.
Bu riski kapatmanın yolu her koda giriş tarihi ve varsa son geçerlilik tarihi yazmaktır. Panel, belirli bir yaşı geçen stoğu ayrı bir listede göstermeli ve önce onu teslim etmelidir. Yani depon FIFO çalışmalı: en eski kod önce çıkmalı. Bunu insan hafızasına bırakırsan çalışmaz. Sıralamayı yazılımın yapması gerekir; özellik listesinde stok yaşlandırma kalemini bu yüzden ararsın.
Teslimat ekranına “kodu görüntüleme zamanı” damgası koy. Müşteri kodu saat 14:02’de gördüyse ve 14:40’ta “hiç almadım” diyorsa tartışma orada biter. Bu tek alan, haksız iade taleplerinin büyük kısmını konuşmadan kapatır.
Yanlış ürün eşleşmesi ve hesap tipi uyumsuzluğu neden senin sorumluluğun?
Katalogda birbirine çok benzeyen ürünler olur: aynı oyunun farklı para birimi paketleri, aynı platformun mobil ve masaüstü sürümleri, aynı markanın abonelik ve tek seferlik kodu. Müşteri hangisini aldığını bilmeden sipariş verir, kodu yükler, tutmaz. Teknik olarak hatalı bir şey yapmış değildir; sen ona doğru olanı seçtirmemişsindir.
Burada işini kurtaran şey ürün sayfasının netliğidir. Paket adında para birimi ve bölge açıkça yazmalı, ödeme adımında “hesabımın bölgesini doğruladım” gibi zorunlu bir onay bulunmalı, kodun hangi hesap tipinde çalıştığı tek satırda söylenmelidir. Bunlar pazarlama süsü değil, iade maliyetini düşüren mühendislik kararlarıdır. Serbest kod atamasını tamamen kapatıp SKU kilidi uygulamak da aynı ailede: bir kod yalnızca tanımlı ürününe düşebiliyorsa, yanlış eşleşme diye bir kalem kalmaz.
Bu dokuz sebebi tek panelde nasıl kapatırsın?
Listeye yukarıdan bakınca şu ortaya çıkar: dokuz sebebin yedisi doğrudan altyapı kararıdır. Yani tedarikçi değiştirmek sorunun çoğunu çözmez; süreci değiştirmek çözer. Kod havuzu tek kaynakta olmalı, her kodun bir durumu ve geçmişi olmalı, teslimat ile stok düşümü tek işlemde gerçekleşmeli, görüntüleme kayda geçmeli ve destek ekranı satışın tüm izini tek yerden gösterebilmeli.
Pinova’yı bir e-pin satış scripti olarak kurgularken referans noktası bu dokuz maddeydi; süslü panel değil, ret oranını düşüren akış. Kendi durumunu ölçmek istiyorsan aşağıdaki kontrol listesini panelinde tek tek dene. Dört maddeden fazlasına “hayır” diyorsan, sorunun tedarikçin değil, üzerinde çalıştığın dijital ürün satış yazılımı. Karşılaştırma yapmak için fiyat tablosuna bakıp kendi aylık iade kaybınla kıyaslaman yeterli olur.
| Kontrol maddesi | Nasıl test edersin | Beklenen sonuç |
|---|---|---|
| Tek seferlik kod kilidi | Aynı kodu iki siparişe atamayı dene | Sistem reddetmeli |
| Bölge etiketi | Ürün varyantlarını listele | Her varyantta bölge görünmeli |
| Görüntüleme logu | Test siparişinde kodu aç | Tarih, saat, IP kaydedilmeli |
| Stok yaşlandırma | En eski kodu sorgula | İlk teslimatta o çıkmalı |
| Otomatik trim | Sonuna boşluk ekli kod yükle | Boşluk temizlenmeli |
| Parti takibi | Tedarikçi partisini filtrele | Toplu geri çağırma yapılabilmeli |
| Destek tek ekran | Sipariş numarasıyla ara | Ödeme, kod, log aynı sayfada |
Ret oranını tahmin etmeyi bırak, ölçmeye başla
Pinova, her kodun durumunu, görüntüleme zamanını ve parti bilgisini kayıt altına alır; destek ekibin tartışmaya değil kanıta bakar.
Reddedilen kodun parasını tedarikçiden geri alabilir miyim?
Genelde alabilirsin, ama tek şartla: kodun sende kullanılmadığını kanıtlayabilmen gerekir. Görüntüleme logu, teslimat zamanı ve parti numarası elinde yoksa üst kaynak talebi kapatır. Kayıt tutan bir panel, bu görüşmelerin tamamında elini güçlendirir.
Müşteri “kod çalışmıyor” dediğinde ilk ne sormalıyım?
Önce hata metninin tam ekran görüntüsünü iste. “Kullanılmış”, “geçersiz” ve “bölgen uygun değil” birbirinden tamamen farklı üç vakadır; ilk mesajda bunu ayırırsan çözüm süresi dakikalar yerine saniyelere iner.
Excel ile stok tutmak gerçekten bu kadar riskli mi?
Evet, çünkü Excel eşzamanlılık bilmez. İki sipariş aynı saniyede gelirse aynı satırı iki kişiye verebilirsin. Çift teslimat kaybının neredeyse tamamı bu tek nedenden çıkar.
Otomatik teslimat ret oranını düşürür mü?
Dolaylı olarak evet. Otomatik teslimat insan elini zincirden çıkarır; kopyalama hatası, yanlış kod gönderimi ve çift teslimat kalemleri birlikte küçülür. Kalan ret vakaları da artık gerçek ve ölçülebilir olur.
Ret vakalarını azaltmanın kısayolu yok; ölçmek, kaydetmek ve akışı sıkılaştırmak var. Panelinde bu dokuz maddenin kaçını kapatabildiğini görmek istiyorsan, örnek stok ve test siparişleriyle hazırlanmış canlı demo üzerinde aynı senaryoları birkaç dakika içinde kendin deneyebilirsin.