Bu rehberi okuduğunuzda, bir talebin sisteme girdiği andan kapandığı ana kadar hangi kararların kim tarafından verileceğini tanımlayabileceksiniz. Talep yönetimi bir ekran kullanımı değildir; bir kaydın yaşam döngüsünün yazılı hale getirilmesidir. Durum listesi, öncelik ölçeği ve kapatma tanımı bir sayfada yazılı değilse, on kişilik bir ekipte on farklı uygulama oluşur ve ay sonunda çıkan rapor kimsenin işine yaramaz.
Durum Listesi Kısa Olmalıdır
Talep durumu, sistemin en çok kirletilen alanıdır. Sebep basittir: her yeni ihtiyaç için bir durum eklenir. "Müşteri bekleniyor", "tedarikçi bekleniyor", "onay bekleniyor", "test ediliyor", "yayına alınacak" derken liste on beş satıra çıkar ve kimse hangi durumun ne demek olduğunu bilmez.
Durum listesi tasarlanırken tek bir soru yeterlidir: bu durum, "top kimde" sorusunun farklı bir yanıtı mı? Farklı bir yanıt değilse durum değil, bir alandır.
| Durum | Ne anlatır | Top kimde |
|---|---|---|
| Açık | Talep alındı, henüz çalışılmadı | Bizde |
| İşlemde | Bir temsilci fiilen üzerinde çalışıyor | Bizde |
| Beklemede | Bizim yapabileceğimiz bir şey yok, dışarıdan yanıt bekleniyor | Karşı tarafta |
| Çözüldü | Çözüm sunuldu, müşteri teyidi bekleniyor | Müşteride |
| Kapalı | İş bitti, kayıt kapandı | Kimsede |
Beş durum, gördüğümüz operasyonların büyük çoğunluğu için yeterlidir. "Tedarikçi bekleniyor" ile "müşteri bekleniyor" arasındaki fark durum değil, bekleme sebebi alanıdır. Bu ayrımı yapmak, hem listeyi kısa tutar hem de "neyi bekliyoruz" sorusunu raporlanabilir hale getirir.
Beklemede, SLA sayacını duraklatan durumdur. Bu yüzden oraya yalnız dış bekleme girer: müşteri, tedarikçi veya üçüncü taraf bekleniyorsa. İç bekleme oraya girmez. Onay, test ve yayın bekleyen talepler İşlemde kalır; iç gecikme sizin sorununuzdur ve sayacın durmaması gerekir. Bu ayrım yapılmazsa SLA raporu olduğundan iyi görünür. Ekip sayacı durdurmak için talepleri gereksiz yere beklemeye alıyorsa, metrik iyileşir ama müşteri deneyimi kötüleşir; bu, ölçünün davranışı bozmasının klasik örneğidir.
Öncelik: Müşteri Belirlemez
Ö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.
Sahiplik: Her Talebin Bir Adı Olmalı
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.
Kapatma Tanımı
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.
Temsilci çözümü sunar ve durumu Çözüldü yapar
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.
Belirli 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.
Üç 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.
Yeniden açılma oranı izlenir
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.
Otomatik kapatma penceresini kısa tutmak, müşteriyi aynı konuyu yeniden yazmaya iter ve hacmi yapay olarak artırır. Uzun tutmak ise açık talep sayısını şişirir ve kuyruğun gerçek durumunu gizler. Üç iş günü, gördüğümüz operasyonların çoğunda dengeli sonuç veriyor.
Mükerrer Talep ve Birleştirme
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.
İç Yazışma ile Müşteri Yazışmasını Ayırmak
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.
Kuyruğu Okumak
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.
Sahipsiz
Kimseye atanmamış talepler. Bu liste her zaman boşa yakın olmalıdır.
SLA riski
Süresi dolmak üzere olanlar. İhlal edilenler değil, edilecekler.
En eski
Kuyruğun dibinde unutulanlar. Sessiz müşteri, memnun müşteri değildir.
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.
