Rehber
Finansal Kuruluşlar İçin Şikayet Yönetim Sistemi Nasıl Seçilir?
13 Haziran 2026 • 7 dk okuma
Genel destek araçları regüle finansal kuruluşların şikayet uyum gereksinimlerini karşılamıyor. BDDK ve TCMB denetimine hazır bir şikayet yönetim sistemi seçerken bakılması gereken 5 kriter.
Bir şikayet yönetim sistemi seçimi, genel yazılım değerlendirme süreçlerinden farklı çalışır. Bankalar, ödeme kuruluşları, e-para şirketleri ve diğer BDDK veya TCMB denetimine tabi yapılar için bu seçim; araç kullanım kolaylığının çok ötesinde, yasal uyum, veri egemenliği ve denetim hazırlığı kriterlerini kapsar.
Bu rehberde, regüle bir finansal kuruluş olarak şikayet yönetim sistemi değerlendirirken sormak zorunda olduğunuz beş soruyu ve bu soruların neden belirleyici olduğunu ele alıyoruz.
Neden Genel Destek Araçları Yeterli Olmuyor?
Zendesk, Freshdesk, Jira Service Management gibi araçlar; büyük ölçekli müşteri destek operasyonları için tasarlanmıştır. SLA takibi, bilet yönetimi ve raporlama konusunda güçlü yeteneklere sahiptirler.
Ancak BDDK veya TCMB kapsamındaki bir finansal kuruluşun ihtiyaçları bu temel özellik setinin ötesine geçer:
- Yasal SLA takibi: 30 günlük sürenin bireysel başvuru bazında yasal başlangıç tarihinden itibaren otomatik hesaplanması
- Değiştirilemez denetim izi: Her işlem adımının zaman damgası ve kullanıcı kimliğiyle birlikte silinemeyen kayıt altına alınması
- Veri egemenliği: Müşteri şikayet verilerinin yurt içinde, kurum kontrolündeki altyapıda tutulması
- Regülatör entegrasyonu: TCMB Şikayet Yönetim Sistemi ve BDDK E-Şikayet portalından gelen bildirimlerin otomatik işlenmesi
Bu gereksinimlerin hiçbiri, küresel destek platformlarının temel özellik setinde yer almaz. Bazıları ek entegrasyonlarla kısmen karşılanabilir; ancak bu entegrasyonların kendisi de uyum sürecini karmaşıklaştırır.
Kriter 1: Veri Egemenliği ve Kurulum Modeli
Şikayet verileri; müşteri kimlik bilgilerini, işlem detaylarını ve bazen hassas finansal bilgileri içerir. Bu verilerin nerede işlendiği ve saklandığı, birden fazla yasal yükümlülük açısından kritik öneme sahiptir.
KVKK: 6698 sayılı Kanun, kişisel verilerin yurt dışına aktarılmasını açık rızaya veya yeterli koruma kararına bağlar. Bulut tabanlı bir sistemde şikayet verilerinin hangi ülkede işlendiğinin belirsiz olması, bu yükümlülükle doğrudan çelişir.
BDDK kayıt saklama: 5411 sayılı Bankacılık Kanunu kapsamında müşteri bilgileri ve işlemlere ilişkin kayıtlar yurt içinde saklanmak zorundadır. Bu yükümlülük şikayet kayıtlarını da kapsar.
TCMB kayıt saklama: 6493 sayılı Kanun'un 23. maddesi, ödeme ve e-para kuruluşları için 10 yıllık yurt içi saklama zorunluluğu öngörür.
Değerlendirdiğiniz sistemin on-premise kurulum seçeneği sunup sunmadığını, sunmuyorsa veri lokasyonu garantisini nasıl sağladığını ve denetimde bu garantiyi nasıl kanıtlayabileceğinizi sorgulamanız gerekir.
Kriter 2: Yerleşik Yasal SLA Takibi
30 günlük yanıt süresi, BDDK ve TCMB kapsamındaki kuruluşlar için genel bir hedef değil, yasal zorunluluktur. Süre aşımı doğrudan idari yaptırıma yol açar.
Genel destek araçlarında SLA takibi mevcuttur; ancak bu takip genellikle iş günü veya saat bazındaki servis hedefleri için tasarlanmıştır. Hukuki anlamda başlangıç tarihi hesabı, farklı kanal ve başvuru türleri için farklı süreler, eskalasyon eşiklerinin yasal süreye göre otomatik tetiklenmesi gibi özellikler standart konfigürasyonda bulunmayabilir.
Değerlendirdiğiniz sistemde şu soruların yanıtını arayın:
- Yasal başlangıç tarihi (başvurunun alınma anı) ve iş akışı başlangıcı birbirinden ayrılabiliyor mu?
- Süre ihlaline birkaç gün kala otomatik uyarı ve eskalasyon tetiklenebiliyor mu?
- SLA uyum oranı denetim formatında raporlanabiliyor mu?
Kriter 3: Değiştirilemez Denetim İzi
TCMB ve BDDK denetimlerinde denetçilerin aradığı şey; bir şikayetin kimler tarafından, hangi sırayla, ne zaman işlendiğinin değiştirilmemiş kaydıdır. Bu iz, şikayet kapatıldıktan sonra oluşturulamaz; süreç boyunca gerçek zamanlı olarak üretilmesi gerekir.
Değiştirilemez denetim izi şu bilgileri kapsamalıdır:
- Başvurunun alınma zamanı ve kanalı
- Sorumlu atama ve değişiklik geçmişi
- Müşteriye gönderilen her yanıt ve gönderen kullanıcı kimliği
- Süre uzatma veya eskalasyon kararları ve gerekçeleri
- Başvurunun kapanış zamanı ve kapanış kategorisi
Bu iz, sistemden silinebilir veya düzenlenebilir olmamalıdır. Kullandığınız sistemin denetim izini nasıl sakladığını, bu kayıtlara kimin erişebildiğini ve bunların ibraz sürecinde nasıl dışa aktarılabildiğini sormak, seçim sürecinin kritik adımlarından biridir.
Kriter 4: Regülatör Portal Entegrasyonu
TCMB Şikayet Yönetim Sistemi (esikayet.tcmb.gov.tr) ve BDDK E-Şikayet (ebulten.bddk.org.tr/esikayet) portallarından gelen bildirimler, şikayet hacminin önemli bir bölümünü oluşturur ve yasal SLA bu bildirimin geldiği anda başlar.
Bu bildirimi manuel olarak takip etmek; gecikmeye, süre ihlali riskine ve denetim izinde boşluğa yol açar. Değerlendirdiğiniz sistemin bu portallardan gelen bildirimleri otomatik olarak yakalayıp işleyip işleyemediğini ve SLA takibini o andan başlatıp başlatamadığını doğrulayın.
TCMB portalıyla doğrudan API entegrasyonu sunan yaygın genel destek araçları bulunmamaktadır. Bu entegrasyon, Türk ödeme regülasyonunu bilen ve bu ekosistemi ürününe işlemiş platformlarda mümkündür.
Kriter 5: Omnichannel Kapsam ve Kategori Yapısı
Finansal kuruluşlarda şikayetler; e-posta, telefon, web formu, WhatsApp ve TCMB/BDDK portalları aracılığıyla gelir. Bu kanalların ayrı sistemlerde yönetilmesi; mükerrer kayıt, kayıp başvuru ve tutarsız SLA takibi risklerini beraberinde getirir.
Seçeceğiniz sistemde tüm kanalların tek havuzda toplandığını, her başvuruya kategorinin başvuru anında otomatik veya kolayca atanabildiğini ve periyodik TCMB/BDDK raporlamasının bu kategori yapısına göre otomatik üretilebildiğini doğrulayın. Kategori tutarlılığı; hem operasyonel verimlilik hem de düzenleyici raporlama açısından doğrudan etkilidir.
Genel Araç mı, Amaca Yönelik Platform mu?
| Kriter | Genel destek aracı | Amaca yönelik platform |
|---|---|---|
| Yasal SLA takibi | Ek konfigürasyon/entegrasyon | Yerleşik |
| Değiştirilemez denetim izi | Genellikle yok | Yapısal |
| On-premise kurulum | Kısıtlı/yok | Mevcut |
| TCMB/BDDK portal entegrasyonu | Yok | Mümkün veya yol haritasında |
| Periyodik regülatör raporlaması | Manuel derleme | Sistem çıktısı |
| Türk finans regülasyonu bilgisi | Yok | Temel tasarım ilkesi |
Genel araçlar büyük müşteri destek operasyonları için optimize edilmiştir. Regüle finansal kuruluşlar için gerekli olan uyum katmanı; her kurulumda sıfırdan inşa edilmesi gereken bir ek yapı haline gelir.
FlowDesk ile Karşılaştırma Yazılarımız
Hangi araçların bu kriterleri nasıl karşıladığını daha ayrıntılı incelemek istiyorsanız:
- Freshdesk mi, FlowDesk mi? Ödeme Kuruluşları ve Fintechler İçin TCMB Uyumlu Şikayet Yönetimi
- Zendesk mi, FlowDesk mi? Regüle Müşteri Operasyonlarında Veri Egemenliği ve KVKK
- Jira Service Management mi, FlowDesk mi? Fintech Müşteri Şikayet Operasyonu
Sık Sorulan Sorular
Genel destek yazılımları (Zendesk, Freshdesk) neden finansal kuruluşlar için yeterli değil?
Bu araçlar TCMB veya BDDK yasal SLA takibini yerleşik olarak sunmaz, değiştirilemez denetim izi üretmez ve veri egemenliği gerektiren on-premise kuruluma uygun değildir. Regüle kuruluşlarda uyum eksikliği bu araçtan değil operasyonun yapısından kaynaklanır; ancak doğru araç bu yapıyı inşa etmeyi kolaylaştırır.
Şikayet yönetim sistemi seçiminde on-premise zorunlu mu?
BDDK ve TCMB mevzuatı veri lokasyonunu açıkça bulut yasağıyla sınırlandırmaz; ancak kayıt saklama, denetim izi ibrazı ve KVKK yükümlülükleri pratikte on-premise veya özel barındırma tercihini güçlü biçimde destekler. Bulut tabanlı bir araç seçildiğinde veri işleme sözleşmesi, lokasyon doğrulaması ve erişim loglaması bu yükümlülükleri karşılamalıdır.
TCMB Şikayet Yönetim Sistemi entegrasyonu hangi sistemlerde mevcut?
TCMB'nin esikayet.tcmb.gov.tr portalıyla doğrudan API entegrasyonu sunan yaygın genel destek araçları bulunmuyor. FlowDesk, TCMB portalından gelen e-posta bildirimlerini mevcut ingestion altyapısı üzerinden işleyerek otomatik vaka açıyor ve SLA'yı başlatıyor; daha derin API entegrasyonu yol haritasında.
Şikayet yönetim sistemi geçişi ne kadar sürer?
Mevcut veri hacmine ve entegrasyon ihtiyaçlarına bağlıdır. Temel kurulum ve yapılandırma genellikle birkaç hafta içinde tamamlanır. On-premise kurulum, altyapı hazırlığına göre değişir. Geçiş öncesinde mevcut şikayet verilerinin taşınması ve ekip eğitimi süreci de planlamaya dahil edilmelidir.
Bu konuyla ilgili yazılar:
- TCMB Şikayet Yönetim Sistemi: Ödeme ve E-Para Kuruluşları İçin Uyum Rehberi
- BDDK E-Şikayet Sistemi: Yasal Yanıt Süreleri ve Süreç Yönetimi
- Freshdesk mi, FlowDesk mi? TCMB Uyumlu Şikayet Yönetimi Karşılaştırması
- Zendesk mi, FlowDesk mi? Regüle Operasyonlarda Veri Egemenliği ve KVKK
Bu yazı genel bilgilendirme amaçlıdır ve hukuki danışmanlık niteliği taşımaz; mevzuat değişikliklerine göre güncellenebilir. Kurumunuza özel gereksinimler için hukuk ve uyum biriminizi esas alın.
FlowDesk — Ücretsiz Demo
TCMB Uyumlu Şikayet Yönetim Sistemini Deneyin
30 günlük SLA takibi, değiştirilemez denetim izi ve TCMB Şikayet Yönetim Sistemi entegrasyonu: tek katmanda, 20 dakikalık demoda.