Talep Yönetimi

Öncelik alanını müşteriye açan her kurulumda aynı şey olur: taleplerin çoğu "acil" gelir. Bu, müşterinin kötü niyetinden değil, kendi işi açısından haklı olmasından kaynaklanır. Öncelik, işin sizin tarafınızdaki etkisini ölçen bir alandır ve bu yüzden sizin tarafınızda belirlenir.

Sahada işleyen ölçek, iki boyutun kesişimidir: etki (kaç kişiyi etkiliyor) ve aciliyet (ne kadar beklerse ne olur).

Yüksek öncelik

Çok kullanıcıyı aynı anda durduran, gelir kaybı üreten veya geri dönülemez sonuç doğuran durumlar. Bu tanım dar tutulmazsa öncelik anlamını yitirir.

Normal öncelik

Tek kullanıcıyı etkileyen, geçici çözümle idare edilebilen, işleyişi yavaşlatan ama durdurmayan durumlar. Talebin büyük çoğunluğu buradadır.

Öncelik ölçeğini dört kademeden fazla yapmayın. Beş ve üzeri kademede kimse "üç" ile "dört" arasındaki farkı tutarlı uygulayamaz. Ölçeğin tanımı yazılı olmalı ve talebi açan ekranın yanında görünmelidir; hatırlanması gereken bir kural, hatırlanmayan bir kuraldır.

Sahipsiz talep, destek operasyonunun en sessiz arızasıdır. Kimse üzerine almadığı için kimse geciktiğini fark etmez. Herkes gördüğünü sanır, kimse dokunmaz.

Kural nettir: bir talebin her an tek bir sahibi olmalıdır. Ortak sahiplik yoktur. Birden çok kişi çalışıyorsa biri sahiptir, diğerleri katkı verir. Sahip, o talebin müşteriye karşı sorumlusudur.

• Havuz modeli. Talepler ortak bir kuyruğa düşer, temsilci sıradakini alır. Küçük ve eşit yetkinlikteki ekiplerde iyi çalışır, sahiplik alma anında oluşur.
• Doğrudan atama. Talep açıldığı anda bir kişiye düşer. Sorumluluk nettir, ancak izinli veya yoğun kişiye düşen talep bekler; devir kuralı şarttır.
• Karma model. Kanal veya kategoriye göre otomatik atanır, atanamayanlar havuzda kalır. Sahada en çok işe yarayan modeldir.

Hangi modeli seçerseniz seçin, iki durumu baştan tanımlayın: temsilci izne çıktığında açık talepleri ne olacak ve bir talep kimseye atanmadan belirli bir süre beklerse ne olacak. İkinci soru bir eskalasyon kuralına dönüşür; ayrıntısı Atama, Yönlendirme ve SLA rehberindedir.

Bir talebin ne zaman kapanacağı, ölçtüğünüz her sürenin paydasıdır. Tanım yoksa çözüm süresi ortalaması bir sayıdır ama bir bilgi değildir.

Sahada işleyen tanım iki adımlıdır ve arada bir bekleme penceresi vardır.

1. 01Temsilci çözümü sunar ve durumu Çözüldü yapar

   Bu an, ekibin işini bitirdiği andır ve çözüm süresi burada durur.

   Bu an, ekibin işini bitirdiği andır ve çözüm süresi burada durur. Çözüm mesajı müşteriye ne yapıldığını anlatmalıdır. "Halledildi" yeterli değildir; müşteri neyin değiştiğini bilmeden teyit veremez.

2. 02Belirli bir süre yanıt gelmezse otomatik kapanır

   Müşteri teyidini beklemek gerçekçi değildir; çoğu müşteri memnun olduğunda yazmaz.

   Müşteri teyidini beklemek gerçekçi değildir; çoğu müşteri memnun olduğunda yazmaz. Üç iş günü yaygın bir penceredir. Bu süre içinde müşteri yazarsa talep yeniden açılır ve bu, ilk çözümün yetersiz kaldığının en değerli sinyalidir.

3. 03Yeniden açılma oranı izlenir

   Bu oran, gerçek çözüm kalitesini gösteren tek metriktir.

   Bu oran, gerçek çözüm kalitesini gösteren tek metriktir. Hızlı kapatan ama sık yeniden açılan bir ekip, yavaş kapatan ama bir kerede çözen bir ekipten daha kötü çalışıyordur. Kapanma sayısı tek başına yanıltıcıdır.

Aynı müşteri aynı konuyu iki kanaldan yazdığında iki talep oluşur. Bu normaldir ve engellenemez. Engellenmesi gereken, iki temsilcinin aynı işi habersiz yapmasıdır.

• Birleştirin, silmeyin. Mükerrer talebi silmek, o kanaldan gelen hacmi de kayıtlardan siler. Birleştirme geçmişi korur ve hangi kanaldan kaç kez ulaşıldığını görünür bırakır.
• Aynı kişiden açık talep varsa temsilciyi uyarın. Talep ekranında müşterinin diğer açık talepleri görünmüyorsa, temsilci bunu bilemez.
• Tekrar eden konu, mükerrer talep değildir. Aynı müşterinin aynı sorunu üçüncü kez yaşaması ayrı bir taleptir ve asıl sorunun çözülmediğinin işaretidir. Bu ikisini karıştırmak, gerçek sorunu istatistiğin altına gömer.

Bir talebin altında iki farklı konuşma yürür: müşteriyle olan ve ekip içinde olan. Bu ikisinin ayrılmaması, destek operasyonlarında gördüğümüz en maliyetli tekil hatadır; yanlış tarafa yazılan bir iç yorum, müşteri ilişkisini tek mesajda bozabilir.

Müşteri yanıtı

Dışarı gider. Ton, dil ve içerik müşteriye göredir. Buradaki her mesaj kurumsal bir belgedir ve alıntılanabilir.

İç yorum

Dışarı gitmez. Teknik detay, tahmin, ekip içi soru buraya yazılır. Yine de kalıcı bir kayıttır; kişisel yorum yazılacak yer değildir.

Kurulum aşamasında iki önlem alın: iç yorum alanının görsel olarak belirgin biçimde ayrışması ve yeni temsilcilere ilk gün bu ayrımın gösterilmesi. Ekranda ayrım zayıfsa, eğitim bunu telafi etmez.

Talep yönetiminin günlük pratiği, kuyruğa bakma alışkanlığıdır. Doğru kurulmuş bir kuyruk görünümü, ekibin sabah ilk beş dakikada ne yapacağını söyler. Yanlış kurulmuş bir görünüm, ekibin en yüksek sesle yazan müşteriyle ilgilenmesine yol açar.

1. 1

   Sahipsiz

   Kimseye atanmamış talepler. Bu liste her zaman boşa yakın olmalıdır.

2. 2

   SLA riski

   Süresi dolmak üzere olanlar. İhlal edilenler değil, edilecekler.

3. 3

   En eski

   Kuyruğun dibinde unutulanlar. Sessiz müşteri, memnun müşteri değildir.

4. 4

   Yeniden açılan

   Bir kez çözülüp geri gelenler. Öncelik almalıdır; ikinci kez hayal kırıklığı pahalıdır.

Bu dört görünüm, çoğu ekipte "atanmamış" ve "bugün gelenler" dışında hiç kurulmaz. Oysa destek kalitesini belirleyen, gelen taleplere bakmak değil, kaymakta olan talepleri görmektir.

Kuyruğu okumayı kolaylaştıran asıl yapı, doğru kurulmuş atama ve SLA'dır. Sıradaki rehber tam olarak bunu ele alıyor: Atama, Yönlendirme ve SLA.