Çoğu e-pin satıcısı işin özetini şöyle kurar: ürün girilir, müşteri öder, kod gider, sipariş kapanır. Kulağa temiz geliyor. Ama bu akışta kimsenin konuşmadığı bir boşluk var: kodun kime, hangi saniyede, hangi IP'den, hangi ödeme yöntemiyle ve kaçıncı denemede teslim edildiği bilgisi çoğu kurulumda ya hiç tutulmuyor ya da üç farklı yere dağılmış halde duruyor. Sipariş tablosunda bir satır, stok dosyasında bir satır, WhatsApp geçmişinde bir ekran görüntüsü. Bunlar birleşmediği sürece elinde satış var ama kanıt yok.
Kanıtın olmadığı yerde kaybedeceğin tartışmayı müşteri belirler. "Kod çalışmadı", "ben bunu almadım", "iki kere ödedim" cümleleri geldiğinde elinde sadece hafızan varsa, iade masasında her seferinde sen kaybedersin. Pin CRM mantığı tam olarak buradan doğdu: müşteri kaydı ile kod kaydını aynı zincirde, aynı anda, geri alınamaz biçimde tutmak. Bu yazıda o zincirin nasıl kurulduğunu, hangi alanların kritik olduğunu ve iyi bir e-pin scripti ile derme çatma bir panelin farkının nerede ortaya çıktığını tek tek açacağım.
Neden "kodu gönderdim, iş bitti" düşüncesi sana her ay para kaybettiriyor?
Dijital ürün satışında fiziksel bir kargo takip numarası yok. Elinde kargo fişi olmadığı için, teslimatın gerçekleştiğini gösteren tek şey senin sisteminin tuttuğu kayıt. Bu kaydı basit bir "gönderildi" etiketiyle geçiştirirsen, itiraz anında söyleyebileceğin tek cümle "ama ben gönderdim" olur. Ödeme sağlayıcısının, bayinin ya da müşterinin karşısında bu cümlenin ağırlığı sıfırdır.
İşin acı tarafı şu: kaybettiğin sadece o kodun parası değil. Her çözülemeyen itiraz, ödeme sağlayıcındaki iade oranını yukarı çeker. Oran yükseldikçe komisyonun artar, bazı noktada hesabın incelemeye düşer. Yani teslim kaydını tutmamanın maliyeti, kaybettiğin kodun on katı olabilir. Bir dijital ürün satış yazılımı seçerken sorman gereken ilk soru "kaç ödeme yöntemi var" değil, "teslimatı nasıl kanıtlıyor" olmalı.
Pin CRM tam olarak nedir, sıradan müşteri listesinden farkı ne?
Klasik CRM müşteriyi tanır: ad, mail, telefon, sipariş sayısı, harcama toplamı. Pin CRM bunun bir adım ötesine geçer ve müşteriyi tek tek koda bağlar. Yani sistemde "Ahmet 4 sipariş verdi" bilgisi değil, "Ahmet'in 3. siparişinde teslim edilen kodun ilk 4 ve son 4 hanesi şu, teslim saati şu, o an bağlandığı IP şu, kodu panelde kaç kez görüntüledi" bilgisi durur.
Bu ters yönde de çalışır. Elinde bir kod varsa, o kodun hangi partide geldiğini, hangi tedarikçiden alındığını, hangi müşteriye gittiğini, satıldıktan sonra iade talebi olup olmadığını tek ekranda görebilirsin. İyi kurulmuş bir e-pin satış scripti bu iki yönlü sorguyu saniyeler içinde cevaplar. Zayıf bir kurulumda ise aynı cevabı bulmak için üç tablo arasında elle eşleştirme yapman gerekir, ki gece 2'de gelen bir itirazda bunu kimse yapmaz.
| Kayıt Katmanı | Ne Tutulur | Hangi Krizi Çözer | Zorunluluk |
|---|---|---|---|
| Müşteri kimliği | Hesap no, mail, telefon, kayıt IP'si | "Bu siparişi ben vermedim" | Kritik |
| Ödeme izi | Sağlayıcı referansı, tutar, saat, durum | Çift ödeme ve eksik tahsilat | Kritik |
| Stok kökeni | Parti no, tedarikçi, alış maliyeti | Bozuk parti tespiti | Yüksek |
| Teslim anı | Kod maskesi, teslim saati, teslim kanalı | "Kod gelmedi" itirazı | Kritik |
| Görüntüleme günlüğü | Kodun panelde kaç kez açıldığı | "Kod kullanılmış çıktı" | Yüksek |
| İtiraz geçmişi | Talep, kanıt, sonuç, not | Tekrarlayan suistimal | Orta |
| Risk puanı | Hesap yaşı, iade oranı, ödeme davranışı | Peşin dolandırıcılık | Orta |
Bir e-pin scripti müşteri kaydını koda nasıl bağlar?
Teknik olarak olay tek bir prensibe iniyor: teslimat anında yazılan kayıt değiştirilemez olmalı. Kodun kendisi veritabanında şifreli durur, ama teslim kaydında kodun maskelenmiş hali, teslim zamanı ve siparişin kimliği birlikte yazılır. Sonradan stok satırını silsen bile teslim kaydı ayakta kalır. Bu yüzden sağlam bir epin yazılım mimarisinde stok tablosu ile teslim tablosu ayrıdır; biri değişken, diğeri arşivdir.
İkinci prensip atomiklik. Ödeme onayı geldiği anda stoktan kod ayrılması, siparişe yazılması ve müşteriye gösterilmesi tek işlem bloğu içinde olmalı. Aksi halde klasik felaket yaşanır: kod stoktan düşer ama siparişe yazılmaz, müşteri boş ekran görür, sen de o kodun nereye gittiğini asla bulamazsın. Pinova'da bu akış tek transaction içinde kilitlenir; yarım kalan bir teslimat mümkün değildir, ya tamamı yazılır ya hiçbiri.
Çözülemeyen teslimat itirazlarının kök nedeni
- Teslim kaydı hiç tutulmamış 45%
- Kayıt var ama müşteriye bağlı değil 25%
- Stok kökeni bilinmiyor 20%
- Görüntüleme günlüğü yok 10%
İade ve "kod çalışmıyor" iddiası geldiğinde hangi veri seni kurtarır?
Bu itirazın iki gerçek sebebi var: kod gerçekten bozuk gelmiştir ya da müşteri kodu kullandıktan sonra iade istiyordur. İkisini ayırmanın tek yolu kayıt. Elinde kodun geldiği parti bilgisi varsa, aynı partiden satılan diğer 40 kodun şikâyetsiz gittiğini görebilirsin. Bu tek bakış, sorunun tedarikçide değil müşteride olduğunu söyler. Tersi de doğru: aynı partiden üç şikâyet geldiyse, dördüncüsünü beklemeden partiyi satıştan çekersin.
Görüntüleme günlüğü ise en sessiz kahramandır. Müşteri kodu panelde açtı mı, kaç kez açtı, hangi cihazdan açtı? Bu üç satır, "ben kodu hiç görmedim" iddiasını tek hamlede bitirir. Ciddi bir e-pin satış yazılımı bu günlüğü müşteriye de gösterir; şeffaflık itirazın büyük kısmını zaten doğmadan önler.
Aynı müşteri ikinci kez geldiğinde sisteminin ne bilmesi gerekir?
Pin CRM'in savunma tarafını anlattık, şimdi kazanç tarafına gelelim. Müşteri ile kod kaydı birleştiğinde elinde sadece kanıt değil, davranış haritası olur. Hangi müşteri hangi oyunun kodunu ayın hangi haftasında alıyor, ortalama sepeti ne, hangi tutarın üstünde bakiye yüklemeye geçiyor. Bu bilgi olmadan yaptığın her kampanya körlemedir.
Pratik örnek: belirli bir oyunun kodunu son 90 günde üç kez alan müşteriler, o oyunun yeni sezon paketinde en yüksek dönüşümü veren gruptur. Bu listeyi elle çıkarmak imkânsız; kod bazlı kayıt tutan bir sistemde ise iki filtreyle elde edilir. Aynı mantık ters yönde de işler: iade oranı yüksek, hesabı yeni, ödemesi riskli müşterileri otomatik olarak manuel onaya düşürebilirsin.
| Kontrol | Nasıl Test Edersin | Sağlıklı Sonuç | Durum |
|---|---|---|---|
| Teslim kaydı kalıcı mı | Stok satırını sil, siparişi aç | Teslim bilgisi hâlâ görünür | Zorunlu |
| Kod maskeleme var mı | Yönetici günlüğüne bak | Tam kod loglarda görünmez | Zorunlu |
| Atomik teslimat | Ödeme sırasında bağlantıyı kes | Yarım sipariş oluşmaz | Zorunlu |
| Parti takibi | Bir kodu geriye doğru sorgula | Tedarikçi ve parti görünür | Yüksek |
| Görüntüleme günlüğü | Müşteri panelinden kodu aç | Zaman ve cihaz kaydı düşer | Yüksek |
| Müşteri 360 ekranı | Tek müşteriyi aç | Tüm kodlar, ödemeler, itirazlar birlikte | Yüksek |
| Dışa aktarım | Tek siparişin kanıt dosyasını al | Tek tuşla PDF/CSV | Orta |
Teslim kaydına siparişin ödeme referansını da yaz. Ödeme sağlayıcısıyla yaşadığın her tartışmada, tek satırda hem parayı hem kodu aynı referansla eşleştirirsin. Bu alanı sonradan eklemek neredeyse imkânsız.
Kendi tablonu mu kurmalısın, hazır bir dijital ürün satış scripti mi?
Kendi kodunu yazmak ilk bakışta cazip. Üç tablo, birkaç sorgu, olur biter. Gerçekte olan şu: ilk ay çalışır, ikinci ay eşzamanlı iki sipariş aynı kodu alır, üçüncü ay stok ile teslim tabloları birbirini tutmaz, dördüncü ay elle düzeltmeye çalışırken arşivi bozarsın. Bu işin zor kısmı arayüz değil, eşzamanlılık ve arşiv disiplini.
Hazır bir e-pin yazılımı seçmenin asıl değeri buradadır: kilitleme, atomik teslimat, maskeleme, günlükleme ve müşteri-kod eşleştirmesi zaten çözülmüş halde gelir. Sen ürün ve tedarikçi tarafına odaklanırsın. Pinova'nın Pin CRM modülü tam olarak bu katmanı kapatmak için tasarlandı; hangi alanların nasıl tutulduğunu özellikler sayfasında kalem kalem görebilir, sana uygun paketi fiyat tablosundan karşılaştırabilirsin.
Teslimatını kanıtlayamadığın her sipariş, açık bir risk
Müşteri ve kod kaydını tek zincirde tutan, itirazı kanıtla kapatan yapıyı kendin kurmak zorunda değilsin.
Pin CRM ile normal CRM arasındaki fark tam olarak nedir?
Normal CRM müşteriyi ve siparişi tanır. Pin CRM ise her müşteriyi tek tek teslim edilen kodun kaydına bağlar; hem müşteriden koda hem koddan müşteriye sorgu yapabilirsin.
Kodların tamamını veritabanında açık tutmak sorun mu?
Evet. Kodlar şifreli saklanmalı, günlüklerde ise yalnızca maskelenmiş hali görünmeli. Yönetici ekranında bile tam kodun gereksiz yere basılması ciddi bir risktir.
Stoktan silinen bir kodun teslim kaydı kaybolur mu?
Doğru tasarlanmış bir sistemde kaybolmaz. Teslim kaydı ayrı ve değiştirilemez bir arşiv katmanıdır; stok satırı silinse bile siparişin kanıtı yerinde kalır.
Bu yapıyı mevcut panelime sonradan ekleyebilir miyim?
Kısmen. Bundan sonraki satışlar için ekleyebilirsin, ancak geçmiş siparişlerin teslim anı, IP'si ve görüntüleme geçmişi geri getirilemez. Bu yüzden erken kurmak kritiktir.
Pin CRM mantığı karmaşık bir teori değil; sadece "kim, hangi kodu, ne zaman, nasıl aldı" sorusuna her koşulda cevap verebilmek. Bu cevabı verebildiğin gün iade masasında savunmadan çıkıp veriyle konuşmaya başlarsın. Zincirin gerçek bir panelde nasıl göründüğünü kendi gözünle görmek istersen canlı demo üzerinden bir sipariş oluşturup teslim kaydının nasıl yazıldığını adım adım izleyebilirsin.