Tüm yazılar

Rehber

Müşteri CEO'ya Mail Attığında: Kritik Şikayet Nasıl Eskale Edilmeli?

6 Haziran 20267 dk okuma

RehberMüşteri CEO'ya Mail Attığında: Kritik Şikayet Nasıl Eskale Edilmeli?

Bir müşteri çözüm alamayınca doğrudan üst yönetime yazar. O mail düştüğü an, kuruluşun eskalasyon sürecinin gerçek sınavıdır. Kritik şikayet nasıl yönetilir?

Bir müşteri sorununa çözüm alamadığında, çoğu zaman bir üst makama, hatta doğrudan CEO'nun gelen kutusuna yazar. O mail düştüğü an, kuruluşun eskalasyon sürecinin gerçek sınavıdır: Bu şikayet zaten görünür müydü ve doğru kişide miydi, yoksa tepe yönetim mi ilk kez haberdar oluyor? Bu yazıda kritik şikayetlerin nasıl tanımlanacağını ve sürpriz yaşamadan nasıl eskale edileceğini ele alıyoruz.

Eskalasyon nedir, ne değildir

Eskalasyon, bir şikayeti gelişigüzel "yukarı iletmek" değildir. İyi tanımlanmış bir eskalasyon, bir vakayı önceden belirlenmiş kurallarla, doğru seviyeye, doğru zamanda taşımaktır.

Kötü eskalasyon, panikle yöneticileri e-postaya CC'lemek ve sorumluluğu belirsiz bırakmaktır. İyi eskalasyon ise sistematiktir: tetikleyici bellidir, sahiplik nettir ve her adım kayda geçer. Aradaki fark, bir krizin yönetilip yönetilemediğini belirler.

Kritik bir şikayeti ne tanımlar

Her şikayet aynı ağırlıkta değildir. Kritikliği belirleyen tetikleyiciler genellikle şunlardır:

  • Yüksek finansal tutar veya doğrudan gelir kaybı
  • Tekrarlayan şikayet (aynı müşteri ya da aynı konu kısa sürede yeniden)
  • Regülasyon riski (BDDK veya TCMB yanıt süresine yaklaşılması)
  • İtibar riski (sosyal medyada büyüyen, basına ya da hukuki tehdide dönüşen vaka)
  • VIP veya kurumsal müşteri hassasiyeti
  • Yetkisiz işlem veya dolandırıcılık şüphesi (MASAK ile kesişen vakalar)

Bu tetikleyicilerin elle takip edilmesi beklenemez. Doğru kurgu, onları bir kural motoruyla otomatik yakalamak ve vakayı insan müdahalesine gerek kalmadan işaretlemektir.

İyi bir eskalasyon akışının adımları

Sağlam bir eskalasyon, altı adımdan oluşur:

  1. Tetikleyici tanımı. Hangi koşulların bir vakayı kritik yaptığı önceden, kural olarak yazılır.
  2. Otomatik yükseltme. Koşul sağlandığında vaka, doğru ekibin veya yöneticinin ekranına kendiliğinden düşer.
  3. Net sahiplik. Vakayı kimin devraldığı belirsiz bırakılmaz; tek bir sorumlu atanır.
  4. Eskalasyon SLA'sı. Yükseltilen vaka için ayrı, daha kısa bir yanıt süresi başlar.
  5. Bildirim. İlgili yönetici, vakadan anlık olarak haberdar edilir.
  6. Kayıt. Kimin, ne zaman ve neden eskale ettiği değiştirilemez biçimde saklanır.

Bu adımlar tanımlandığında eskalasyon, kişilerin inisiyatifine değil, operasyonun kurgusuna bağlı hale gelir.

Kademeli eskalasyon: her vaka aynı yere gitmez

Tüm kritik vakaları doğrudan tepe yönetime taşımak, eskalasyonu işlevsiz kılar; bir süre sonra hiçbir uyarı ciddiye alınmaz. Sağlıklı bir kurgu kademelidir:

  • Birinci seviye: Ekip lideri veya vardiya sorumlusu. Çoğu kritik vaka burada çözülür.
  • İkinci seviye: İlgili birim yöneticisi. Süre ihlali yaklaşan veya tekrarlayan vakalar.
  • Üçüncü seviye: Üst yönetim ve gerekiyorsa uyum birimi. İtibar, regülasyon veya yüksek tutarlı risk taşıyan vakalar.

Her seviyenin neyi devraldığı önceden tanımlandığında, tepe yönetim yalnızca gerçekten kendi müdahalesini gerektiren vakalarla ilgilenir. Bu, hem dikkati doğru yere odaklar hem de eskalasyonun "kurt geldi" çağrısına dönüşmesini engeller.

"CEO'ya mail" anının anatomisi

İdeal bir operasyonda, bir şikayet CEO'nun gelen kutusuna ulaşmadan çok önce sistem onu zaten kritik olarak işaretlemiş, doğru yöneticiye düşürmüş ve bir eskalasyon SLA'sı başlatmış olur. Yani tepe yönetim, vakayı ilk kez müşterinin mailinden öğrenmez.

Mail yine de gelirse, fark şudur: yönetici tek bir ekranda vakanın tüm geçmişini görür. Şikayet hangi kanaldan geldi, ne zaman açıldı, kim sahiplendi, hangi adımlar atıldı, süre neye yakın. Cevap vermek için kimseye "bu konu ne durumda" diye sormak gerekmez. Sürpriz ortadan kalkar; geriye yalnızca hızlı ve bilgili bir müdahale kalır.

Eskalasyon ve SLA ilişkisi

Eskalasyon ile SLA birbirinden ayrı değil, iç içe çalışır. Yanıt süresi ihlaline yaklaşan bir vaka, beklemek yerine otomatik olarak eskale edilebilir. Eskalasyonun kendisi de yeni bir süre saati başlatır; böylece "yukarı taşındı ama orada da unutuldu" durumu engellenir.

Bu bağ, özellikle regüle sektörlerde kritiktir: yasal yanıt süresinin kaçırılması idari yaptırım doğurabilir, dolayısıyla eskalasyon yalnızca bir nezaket değil, bir uyum mekanizmasıdır.

Eskalasyonda sık yapılan dört hata

Çoğu kuruluş eskalasyonu bir süreç olarak değil, bir refleks olarak yaşar. En sık görülen hatalar şunlardır:

  • Kurala değil kişiye bağlamak. "Bu işi en iyi Ahmet bilir" yaklaşımı, o kişi izinde olduğunda çöker.
  • Sahipliği belirsiz bırakmak. Bir vaka herkese iletilirse, aslında kimse sahiplenmez.
  • Süre koymamak. Yükseltilen ama yeni bir süresi olmayan vaka, daha üst bir masada beklemeye devam eder.
  • Kaydı sonradan tutmak. Eskalasyon gerçek zamanlı kayda geçmezse, denetimde "neden geç kalındı" sorusu cevapsız kalır.

Bu hataların ortak paydası, eskalasyonun sistematik değil, anlık kararlarla yürütülmesidir.

Denetim izi: eskalasyonun kanıtı

Regülasyon, "kritik şikayetleri nasıl yönetiyorsunuz" sorusunu er ya da geç sorar. Bu sorunun cevabı bir slayt değil, kayıttır.

Her eskalasyonun değiştirilemez bir izi olduğunda, bir vakanın ne zaman, hangi gerekçeyle ve kim tarafından yükseltildiği geriye dönük olarak gösterilebilir. Bu iz, hem denetçiye hem de kurum içi sorumluluk zincirine net bir kanıt sunar.

İyi eskalasyon, CEO'ya mail gelmeden önce şikayetin zaten doğru masada olmasıdır.

FlowDesk'i tam da bu nedenle, e-posta, WhatsApp, IVR ve webhook'tan gelen her talebi kategori ve risk seviyesine göre değerlendiren, kritik vakaları kurallı biçimde eskale eden ve her adımı değiştirilemez denetim izine bağlayan bir müşteri operasyonları katmanı olarak tasarladık. Ve yalnızca on-premise çalışacak şekilde. Çünkü kritik bir şikayetin nasıl yönetildiği, en az çözümü kadar önemlidir.


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.

© 2026 FlowDesk. Tüm hakları saklıdır.