"Kaç saatte döneriz?" sorusuna net bir cevabınız yoksa, müşteri hizmetleriniz kişisel çabaya bağlı çalışıyor demektir — ve kişisel çaba büyüdükçe tükenir. SLA (hizmet seviyesi taahhüdü) ve doğru bir ticket yönetimi, destek kalitesini kişiden bağımsız, ölçülebilir ve tekrarlanabilir hale getirir.
SLA nedir, neden sadece "hızlı yanıt" değildir?
SLA (Service Level Agreement), destek talebine ne kadar sürede ilk yanıt verileceğini ve ne kadar sürede çözüme kavuşturulacağını tanımlayan somut bir taahhüttür. Çoğu işletme burada tek bir sayıya ("2 saat içinde yanıt") odaklanır, ama gerçek bir SLA iki farklı metriği ayrı ayrı tanımlamalıdır: ilk yanıt süresi (müşterinin sesinin duyulduğunu anladığı an) ve çözüm süresi (sorunun gerçekten kapandığı an).
Bu ayrım önemlidir çünkü bir talebe hızlı yanıt vermek her zaman hızlı çözmek anlamına gelmez. "Talebinizi aldık, inceliyoruz" mesajı ilk yanıt SLA'sını karşılar ama müşteri asıl çözümü bekler. İki metriği ayrı takip etmek, ekibinizin nerede yavaşladığını görmenizi sağlar: yanıt vermekte mi, yoksa çözmekte mi zorlanıyorsunuz?
Önceliklendirme: her talep aynı ağırlıkta değildir
Tek bir SLA hedefi tüm taleplere uygulanırsa, ya kritik konular gecikir ya da basit sorular gereksiz yere hızlı işlem kuyruğunu tıkar. Talepleri en az üç seviyede önceliklendirin:
- Acil: Ödeme alınmış ama sipariş işlenmemiş, hesaba erişilemiyor, güvenlik ile ilgili konular — hedef: dakikalar içinde ilk yanıt.
- Yüksek: Teslimat gecikmesi, hasarlı ürün, iade talebi — hedef: birkaç saat içinde ilk yanıt.
- Normal: Genel ürün sorusu, kullanım kılavuzu talebi — hedef: bir iş günü içinde yanıt.
Önceliklendirmeyi elle yapmaya çalışmak, yoğun günlerde ekibin en yüksek sesle şikâyet edeni önceliklendirmesine yol açar — bu genellikle en acil talep değil, en ısrarcı müşteridir. Anahtar kelime ve kanal bazlı otomatik etiketleme (örneğin "iptal", "iade", "hasarlı" geçen talepler otomatik yüksek önceliğe düşsün) bu adaletsizliği ortadan kaldırır. İade ile ilgili taleplerin SLA'sını iyi yönetmek aynı zamanda ticari bir fırsattır; süreci nasıl avantaja çevirebileceğinizi iade ve değişim süreci yazımızda ele aldık. Daha ayrıntılı bir öncelik-SLA eşleşmesi genellikle şu şekilde kurulur:
| Öncelik seviyesi | İlk yanıt SLA | Çözüm SLA | Örnek talep |
|---|---|---|---|
| Kritik | 15 dakika | 2 saat | Ödeme alındı, sipariş işlenmedi |
| Yüksek | 2 saat | 1 iş günü | Hasarlı ürün, teslimat gecikmesi |
| Orta | 1 iş günü | 3 iş günü | Genel ürün sorusu, fatura talebi |
| Düşük | 2 iş günü | 5 iş günü | Öneri, geri bildirim, genel bilgi talebi |
Ticket'ın yaşam döngüsünü tanımlayın
Dağınık bir destek sürecinde talepler e-posta, WhatsApp, telefon ve sosyal medya arasında kaybolur; hiçbirinin net bir "durumu" yoktur. Ticket yönetiminin temel faydası, her talebin belirli, izlenebilir durumlar arasında ilerlemesidir: açık, işlemde, müşteriden yanıt bekleniyor, çözüldü, kapandı. WhatsApp özelinde bu akışı nasıl kurabileceğinizi WhatsApp ile satış ve müşteri iletişimi yazımızda ayrıca işledik.
Bu durumlardan en kritik olanı "müşteriden yanıt bekleniyor"dur; çünkü bu durumdaki bir talep SLA saatinizi haksız yere tüketmemelidir — sizin elinizde değil, müşterinin elinde beklemektedir. SLA hesaplamanızda bu bekleme süresini ayrı tutmazsanız, ekibinizin performansı gerçekte olduğundan kötü görünür ve raporlarınız yanıltıcı hale gelir.
"Müşteri, sorununun ne zaman çözüleceğini bilmek ister; belirsizlik, gecikmenin kendisinden daha çok sinir bozar."
Şablonlarla hız ve tutarlılığı birleştirmek
Destek taleplerinin büyük çoğunluğu, aslında sık tekrar eden birkaç konu etrafında toplanır: kargo takibi, iade süreci, ürün değişimi, ödeme sorunu. Bu tekrar eden konular için önceden hazırlanmış, ama kişiselleştirmeye açık şablon yanıtlar hazırlamak, hem yanıt süresini kısaltır hem de farklı temsilcilerin aynı konuya farklı (ve bazen çelişkili) cevaplar vermesini önler.
Şablonun tuzağı, robotik ve genel görünmesidir. İyi bir şablon, müşterinin adını, sipariş numarasını ve duruma özgü bir cümleyi otomatik doldurur; temsilciye "kopyala-yapıştır" değil, "hızlı başlangıç noktası" sunar. Şablonları çeyrek yılda bir gözden geçirip en çok düzenlenen (yani en az işe yarayan) şablonları yeniden yazmak, kalitelerini korur. Sık tekrar eden konuların bir kısmını insana hiç ulaşmadan çözmek isteyenler için sohbet botu ve canlı destek yazımız hangi soruların otomasyona, hangilerinin insana bırakılması gerektiğini anlatıyor.
Ölçüm: SLA'nızı gerçekten tutuyor musunuz?
SLA tanımlamak yeterli değildir; onu düzenli ölçmezseniz kâğıt üzerinde kalır. Haftalık olarak şu üç göstergeyi takip edin: ortalama ilk yanıt süresi, ortalama çözüm süresi ve SLA ihlali oranı (taahhüt edilen sürenin aşıldığı talep yüzdesi). Bu üç sayı birlikte, ekibinizin gerçekte nerede zorlandığını gösterir.
Bir de görünmeyen ama kritik bir metrik vardır: tekrar açılan ticket oranı. Bir talep "çözüldü" olarak kapatılıp kısa süre sonra aynı müşteri tarafından tekrar açılıyorsa, "çözüm" aslında yüzeysel kalmış demektir. Bu oran yüksekse, sorun SLA hızında değil, çözüm kalitesindedir.
SLA ve ticket kurgusu kontrol listesi
- İlk yanıt ve çözüm süresi ayrı ayrı hedeflenip ölçülüyor mu?
- Talepler en az üç öncelik seviyesine otomatik ayrılıyor mu?
- "Müşteriden yanıt bekleniyor" durumu SLA saatinden hariç tutuluyor mu?
- Sık tekrar eden konular için güncel şablonlarınız var mı?
- SLA ihlali oranı ve tekrar açılan ticket oranı haftalık raporlanıyor mu?
- Tüm kanallar (e-posta, WhatsApp, telefon) tek bir ticket akışında birleşiyor mu?
Bu yapıyı dağınık araçlarla ayakta tutmak, ekip büyüdükçe giderek zorlaşır. Şimşek Software'in müşteri hizmetleri modülü, farklı kanallardan gelen talepleri tek bir ticket akışında toplar, öncelik ve SLA takibini otomatikleştirir; böylece ekibiniz taahhüt ettiği süreyi tutup tutmadığını tahmin etmek yerine anlık olarak görür.