Destek talebi ve SLA: Müşteriye verilen süreyi takip etmenin yolu

“Talebimi açalı epey oldu, hâlâ dönüş yok.” Destek ekiplerinin en sık duyduğu cümlelerden biri budur. Çoğu zaman sorun cevabın kalitesinde değildir; sorun, talebin kimde olduğunun ve ne zamana kadar yanıtlanması gerektiğinin belli olmamasıdır. Müşteri bekletildiğini hisseder, ekip ise bekleten kişinin kendisi olduğunu fark etmez.

SLA (hizmet seviyesi anlaşması), bir destek talebine ne kadar sürede yanıt vereceğinizi ya da çözeceğinizi müşteriye bildirdiğiniz süre taahhüdüdür. Bu yazıda SLA’nın günlük destek işinde nasıl izlenebileceğini, YazSis CRM AI’ın talep sayfası üzerinden anlatıyoruz.

SLA izlemede üç yaygın hata

• Talebin sahibi belli değil. Ortak bir e-posta kutusuna düşen talebi herkes görür ve bu yüzden kimse üstlenmez. Atama yapılmamış talep, süresi işlemeye devam eden ama kimsenin listesinde bulunmayan taleptir. Her talebin tek bir sorumlusu olmalıdır.
• Süre talepten ayrı bir yerde duruyor. SLA süresi bir sözleşmede ya da tabloda yazıyorsa, talebe bakan kişi o süreyi çoğu zaman bilmez. Süre talebin yanında görünmelidir; yanıt veren kişi aciliyeti işin içinde fark etmeli, tablo açıp kontrol etmek zorunda kalmamalıdır.
• İç konuşma ile müşteri yanıtı karışıyor. Ekip kendi arasında “önce şunu kontrol edelim” yazarken bu not yanlışlıkla müşteriye gidebilir. Ya da hiç yazılmaz ve bilgi tek bir kişinin kafasında kalır. İç not, müşterinin görmediği ayrı bir alanda tutulduğunda hem iletişim düzgün olur hem de talep başka birine sorunsuz devredilir.

Tek talep sayfasında neler olmalı?

YazSis CRM AI’da bir talep tek sayfada yürür. Müşteriye yanıt, yalnız personelin gördüğü iç not, ek dosya, durum, öncelik ve atama aynı yerdedir; SLA hedefi de talebin yanında durur. Yani talebe bakan kişi, sayfadan ayrılmadan hem ne yapılacağını hem de ne kadar vaktinin kaldığını görür.

• Yanıt: müşterinin göreceği mesaj ve ek dosyalar.
• İç not: yalnız personelin gördüğü araştırma ve devir notları.
• Atama ve öncelik: talebin sahibi ve aciliyeti.
• SLA hedefi: talebin yanında görünen, yanıt için verilmiş süre.

Talepler üç yoldan açılabilir: müşterinin kendi paneli, KurumsalPortal köprüsü ya da müşteri adına çalışan personel. KurumsalPortal kullanan bir müşteri portaldan talep açtığında talep merkeze düşer; merkezden verilen yanıt portala geri döner. Müşteri paneli, kapanan talebin 1–5 arasında puanlanmasına da imkân tanır.

Bir talep sayfada nasıl ilerler?

Kurgusal bir senaryo: bir müşteri firması KurumsalPortal üzerinden bir sorun bildiriyor; talep merkeze düşüyor ve destek ekibinden birine atanıyor. Talep sayfasında SLA hedefi görünüyor. Destek uzmanı sorunu araştırırken kendi notlarını iç nota yazıyor, müşteriye ise yalnız anlaşılır bir yanıt gönderiyor. Yanıt portala geri dönüyor ve müşteri cevabı kendi ekranında görüyor. Talep kapandığında müşteri onu puanlıyor. Bu zincirde hiçbir adım e-posta kutusuna, kişisel tabloya ya da telefon notuna bağlı değildir; her şey tek kayıtta ilerler.

Yönetici sabah nereye bakar?

1. SLA’yı aşan talepler. Pano süresi geçmiş talepleri öne çıkarır; ilk bakılacak yer burasıdır, çünkü müşteri zaten beklemektedir.
2. Size atanan talepler. Kişisel kuyruk, gün boyunca yanıtlamanız gereken işleri toplar ve önceliği netleştirir.
3. Bitmek üzere olan lisanslar ve sessiz kurulumlar. Destek yalnız talebe cevap vermek değildir; süresi dolmak üzere olan lisans ya da uzun süredir durum bildirmeyen kurulum da yakın takip ister.
4. Kapanan taleplerin puanı. Düşük puanlanan talepleri incelemek, hızın yanında yanıtın niteliğini de gösterir.

SLA yalnız hız değildir

Hızlı ama eksik bir yanıt süreyi korur, müşteriyi korumaz. Bu yüzden SLA’yı memnuniyet puanıyla birlikte okumak gerekir. Süre içinde yanıtlanıp düşük puan alan talepler, sürecin neresinin aksadığını gösterir: bilgi eksik miydi, devir mi uzun sürdü, yoksa müşteriye gereğinden teknik bir dille mi cevap verildi? Yanıt süresi bir hedeftir, amaç ise müşterinin sorununun gerçekten çözülmesidir; ikisini birbirinden ayırmak SLA’nın yanlış yönetilmesine yol açar.

Süreleri belirlerken önceliği de hesaba katmak yararlıdır. Üretimi durduran bir arıza ile bir ekran ayarı sorusu aynı süreye bağlanırsa, ya acil iş geç kalır ya da sıradan işler için gereksiz bir baskı oluşur. Önce talepleri öncelik düzeylerine ayırın, süreyi sonra o düzeylere göre konuşun. Her haftanın sonunda süresini aşan talepleri tek tek gözden geçirmek de iyi bir alışkanlıktır: neden aştığını bulduğunuzda çoğunlukla yeni bir kural değil, eksik bir atama ya da geç gelen bir bilgi karşınıza çıkar. Düzeltmeyi oradan yapmak, süreleri uzatmaktan çok daha kalıcı bir çözümdür.

YazSis CRM AI, YazSis’in help.yazsis.com üzerinde çalışan kendi destek merkezinde bugün bu şekilde kullanılıyor. Kurumunuza uyarlanmış kurulumun kapsamını ihtiyaç analizinden sonra birlikte belirliyoruz. Talep, SLA ve müşteri paneli ekranlarını YazSis CRM AI sayfasında inceleyebilirsiniz.