POS ve Ödeme İtirazı Şikayetlerini Regülasyon Uyumlu Yönetmek

Bir POS şikayeti yalnızca teknik bir arıza değil; süre baskısı, risk sınıflandırması ve denetim izi taşıyan bir uyum sürecidir. Uçtan uca nasıl yönetilir?

Bir ödeme kuruluşuna sabah düşen "POS cihazım çalışmıyor, gün boyu tahsilat yapamadım" mailini düşünün. Bu, görünüşte sıradan bir destek talebidir. Oysa arkasında tahsilat yapamayan bir üye iş yeri, olası bir gelir kaybı tazminatı, belki bir ödeme itirazı ve regülasyonun öngördüğü bir yanıt süresi vardır. Ödeme tarafında müşteri şikayeti, aynı anda hem bir operasyon hem de bir uyum olayıdır. Bu yazıda POS ve ödeme itirazı şikayetlerinin uçtan uca, regülasyona uyumlu biçimde nasıl yönetileceğini ele alıyoruz.

POS şikayeti neden sıradan bir talep değildir

Ödeme ekosisteminde tek bir şikayetin birden fazla muhatabı olur: üye iş yeri, son kullanıcı, banka ve kuruluşun kendi operasyonu. "Cihaz çalışmıyor" diye gelen bir kayıt, incelendiğinde bir donanım arızası, bir bağlantı sorunu, yanlış bir ücretlendirme ya da yetkisiz bir işlem itirazı çıkabilir. Bunların her biri farklı bir ekibe, farklı bir aciliyete ve farklı bir yasal çerçeveye karşılık gelir.

TCMB denetimlerinde ödeme ve elektronik para kuruluşlarından beklenen şey, şikayetlerin tek tek sonuçlanması değil; izlenebilir, ele alınabilir ve takip edilebilir tanımlı bir sürecin varlığıdır. Yani bir POS şikayetini doğru çözmek yeterli değildir; nasıl çözüldüğünün de kayıt altında ve gösterilebilir olması gerekir.

Bir POS şikayetinin anatomisi

Regülasyona uyumlu bir operasyonda, kanaldan bağımsız olarak her şikayet aynı akıştan geçmelidir:

1. Tek kapıdan giriş. E-posta, çağrı merkezi veya WhatsApp'tan gelen temas, aynı müşteri kaydına bağlı tek bir şikayet haline gelir.
2. Kategorilendirme. Talep "cihaz arızası", "ödeme itirazı" veya "yetkisiz işlem" gibi net bir sınıfa atanır.
3. Risk seviyesi. Tutar, tekrar sıklığı ve dolandırıcılık şüphesine göre bir risk derecesi belirlenir.
4. SLA ataması. Kategoriye ve riske göre yasal ve içsel yanıt süresi otomatik tanımlanır.
5. Operasyon ekranına düşme. Doğru ekip, bağlamı kaybetmeden vakayı devralır.
6. Eskalasyon. Kritik vakalar tanımlı kurallarla üst seviyeye taşınır.
7. Kapanış ve denetim izi. Çözüm kaydedilir; kim, ne zaman, neye dayanarak karar verdi sorusu değiştirilemez biçimde saklanır.

Bu akışın değeri, hiçbir adımın temsilcinin hafızasına veya kişisel disiplinine bırakılmamasındadır. Süreç, operasyonun varsayılan davranışı haline gelir.

Doğru kategorilendirme önceliklendirmenin temelidir

POS şikayetlerinde en pahalı hata, yanlış sınıflandırmadır. Basit bir kağıt rulosu talebiyle, yetkisiz işlem itirazını aynı kuyrukta bekletmek hem müşteri hem regülatör nezdinde sorun yaratır. Bu nedenle kategori, sadece raporlama için değil, doğrudan önceliklendirme için kullanılmalıdır.

Özellikle iki sınıf ayrı ele alınmalıdır:

• Ödeme itirazı (chargeback) vakaları, belirli süre içinde bankaya dönüş gerektirdiği için saatler düzeyinde hassastır.
• Yetkisiz işlem ve dolandırıcılık şüphesi, MASAK kapsamında şüpheli işlem değerlendirmesini tetikleyebileceği için ayrı bir akışa ve daha sıkı bir kayda ihtiyaç duyar.

Risk temelli önceliklendirme, öfkeli veya mağduriyeti büyük olan vakaların kuyruğun başına otomatik taşınmasını sağlar. Böylece sınırlı operasyon kapasitesi, en yüksek etkili vakalara önce ayrılır.

SLA: süre bir hedef değil, bir eşiktir

Finans tarafında yanıt süreleri çoğu zaman yasal bir eşiktir ve aşıldığında idari yaptırım doğurabilir. Bu yüzden POS şikayetlerinde süre, panonun bir köşesinde takip edilen bir metrik değil, operasyonu yönlendiren bir mekanizma olmalıdır.

Pratikte bunun anlamı şudur: her şikayetin kalan süresi her an görünür olmalı, ihlale yaklaşıldığında sistem ilgili ekibi ve yöneticiyi uyarmalı, ve süre aşımı yaşandığında bu durum sessizce geçmemeli, kayda geçmelidir. Excel tablolarına veya gelen kutularına dayanan takip, artan işlem hacminde bu güvenceyi veremez.

Eskalasyon: kritik vakayı doğru seviyeye taşımak

Her POS şikayeti aynı ağırlıkta değildir. Yüksek tutarlı bir tahsilat kaybı, tekrarlayan bir cihaz arızası ya da bir üye iş yerinin sosyal medyada büyüttüğü bir mağduriyet, standart akışın dışına çıkıp hızla üst seviyeye taşınmalıdır.

İyi tanımlanmış bir eskalasyon, "müşteri CEO'ya mail attı" anını bir krize dönüşmeden yakalar. Kurallar önceden tanımlandığında, kritik vaka doğru yöneticinin ekranına otomatik düşer ve kimin ne zaman devraldığı kayıt altına alınır. Bu, hem müşteriyi hem de denetçiyi tatmin eden bir izlenebilirlik üretir.

Denetim geldiğinde: geçmişi dakikalar içinde çıkarmak

Bir ödeme kuruluşu için denetim, istisna değil rutindir. Denetçi "geçtiğimiz çeyrekte gelen POS itirazları nasıl yönetildi, hangileri süresinde kapandı, kritik olanlar nasıl eskale edildi" diye sorduğunda, cevabın günler süren bir veri toplama çalışmasına dönüşmemesi gerekir.

Bunu mümkün kılan, her şikayetin yaşam döngüsü boyunca biriken denetim izidir. Her durum değişikliği, her not ve her atama zaman damgasıyla ve değiştirilemez biçimde saklandığında, denetime hazırlık ayrı bir proje olmaktan çıkar ve operasyonun doğal bir çıktısı haline gelir.

Bu veri nerede işleniyor?

POS ve ödeme verisi, sektörün en hassas veri sınıflarından biridir. Bankacılık sırrı, KVKK ve ödeme regülasyonları bir araya geldiğinde, müşteri verisinin ve onu işleyen bileşenlerin nerede çalıştığı başlı başına bir karar kriterine dönüşür.

Bu nedenle şikayet operasyonunu yöneten katmanın, gerektiğinde kurum içinde (on-premise) ve verinin sınır dışına hiç çıkmadan çalışabilmesi, regüle kuruluşlar için bir tercih değil çoğu zaman bir önkoşuldur. Veri kurum sınırının içinde kaldığında, uyumun en zorlu yarısı en baştan çözülmüş olur.

POS şikayetinde asıl mesele cihazı yeniden çalıştırmak değil; sürecin süresinde, doğru sahiplikle ve kanıtlanabilir biçimde işlediğini gösterebilmektir.

FlowDesk'i tam da bu amaçla, bir araç olarak değil; e-posta, çağrı merkezi, WhatsApp ve operasyon ekiplerinden gelen her POS şikayetini kategori, risk, SLA, eskalasyon ve denetim izine bağlayan bir müşteri operasyonları katmanı olarak tasarladık. Ve istendiğinde tümüyle kurum içinde çalışacak şekilde. Çünkü ödeme tarafında müşteri operasyonu, aynı zamanda bir uyum operasyonudur.

---

Bu yazı genel bilgilendirme amaçlıdır ve hukuki danışmanlık niteliği taşımaz; süreler ve yükümlülükler mevzuat değişikliklerine göre güncellenebilir. Kurumunuza özel uyum gereksinimleri için ilgili mevzuatın güncel halini ve hukuk/uyum biriminizi esas alın.