Müşteri kaybı nadiren tek bir olayla olur. Genellikle yanıtsız kalan birkaç talebin ardından, sessizce gerçekleşir.
Talepler telefonla, e-postayla ve mesajla gelir; kimin ne söz verdiği kayıt altına alınmadığında takip imkânsızlaşır.
Bu yazıda servis talebi akışını, öncelik kurgusunu ve SLA takibini anlattık.
İçindekiler
Servis talebi nedir?
Servis talebi, müşterinin bir sorunu veya isteğini ilettiği kayıttır. Kaydın kendisi, sözlü bir sözden farklı olarak takip edilebilir.
Her talebin bir numarası, sahibi, durumu ve tarihi olur. Bu dört bilgi, takibin temelidir.
Talep açılmadan yapılan işler görünmez kalır. Ekibin gerçek yükü, ancak kayıtlar üzerinden ölçülebilir.
Bu nedenle telefonla gelen talepler de sisteme girilmelidir; kayıt dışı kalan iş, hem ölçülemez hem unutulur.
Talepler CRM modülünde yönetilir.
Talep akışı
Akış, talebin açılmasıyla başlar. Açılış sırasında müşteri, konu ve açıklama kaydedilir.
Ardından sınıflandırma yapılır; talebin türü, sonraki adımları belirler.
Atama aşamasında sorumlu belirlenir. Sahipsiz talep, çözülmeyen taleptir.
Çözüm sürecinde yapılan işlemler kayda geçer; müşteriye verilen her bilgi de not edilmelidir.
Kapanış, müşteri onayıyla yapılmalıdır. Tek taraflı kapatılan talepler, memnuniyetsizliği gizler.
Öncelik belirleme
Öncelik, iki boyutun birleşimidir: etkinin büyüklüğü ve aciliyet.
Üretimi durduran bir arıza ile kozmetik bir talep aynı önceliğe sahip olamaz.
Öncelik kuralları yazılı olmalıdır; aksi halde en yüksek sesle talep eden müşteri öncelik kazanır.
Müşteri segmenti de öncelikte rol oynayabilir; ancak bu, kural olarak tanımlanmalı ve şeffaf olmalıdır.
Öncelik, açılış sırasında belirlenir ve gerektiğinde yükseltilir; her değişiklik gerekçesiyle kaydedilmelidir.
SLA nedir, nasıl tanımlanır?
SLA, hizmet seviyesi taahhüdüdür. Bir talebe ne kadar sürede yanıt verileceğini ve ne kadar sürede çözüleceğini belirler.
İki farklı süre tanımlanmalıdır: ilk yanıt süresi ve çözüm süresi. İkisi çok farklı taahhütlerdir.
Süreler önceliğe göre değişir. Kritik bir talebin ilk yanıt süresi, düşük öncelikli bir talepten kısa olmalıdır.
Çalışma saatleri de tanıma dahil edilmelidir; hafta sonu kapalıysa süre hesabı buna göre yapılmalıdır.
Hedef belirleme yöntemini SLA hedefleri yazısında ele aldık.
Atama ve eskalasyon
Atama, talebin doğru kişiye ulaşmasıdır. Yanlış atama, süreyi boşa harcatır.
Otomatik atama kuralları kurulabilir; talep türüne veya müşteri grubuna göre yönlendirme yapılır.
Eskalasyon, süre aşımı yaklaştığında devreye girer. Sorumlu ve yöneticisi uyarılır.
Uyarının aşımdan önce gelmesi gerekir; aşım gerçekleştikten sonra gelen uyarı, yalnızca bir rapor kaydıdır.
Bu kurguları otomasyon kuralları yazısında anlattık.
Saha müdahalesi gerektiğinde
Bazı talepler uzaktan çözülemez ve yerinde müdahale gerektirir. Bu durumda talep bir iş emrine dönüşür.
İş emri, teknisyeni, planlanan tarihi ve gereken parçaları içerir.
Yol süresi de SLA hesabına dahil edilmelidir; uzak lokasyonlar için farklı süreler tanımlanabilir.
Müdahale sonrası kullanılan parçalar stoktan düşmeli ve gerekiyorsa faturalanmalıdır.
Saha iş emri akışını iş emri takibi yazısında ele aldık.
Raporlama ve iyileştirme
SLA takibinin amacı ceza vermek değil, tekrar eden sorunları bulmaktır.
En sık açılan talep türleri, hangi konuda iyileştirme gerektiğini gösterir.
Aşım yaşanan talepler incelendiğinde çoğu zaman sistemik bir neden bulunur: eksik bilgi, yetersiz kaynak veya belirsiz süreç.
Müşteri bazlı talep yoğunluğu da izlenmelidir; bir müşteride birikme, ilişkinin risk altında olduğunu gösterir.
Memnuniyet ölçümünü CSAT yazısında ele aldık.
Kanal yönetimi
Talepler tek bir kanaldan gelmez. Telefon, e-posta, mesajlaşma uygulamaları ve saha ziyaretleri; hepsi talep kaynağıdır.
Her kanalın ayrı bir kuyruk oluşturması, ekibin gerçek yükünü gizler ve önceliklendirmeyi imkânsız kılar.
Bu nedenle tüm kanallar tek bir talep havuzunda birleşmelidir. Kaynak bilgisi ise kayıt üzerinde saklanmalıdır.
Kaynak bilgisi zamanla değerli bir veriye dönüşür; hangi kanalın hangi tür talebi getirdiği görünür hale gelir.
Telefonla gelen talepler en çok kayıt dışı kalan gruptur. Görüşme sırasında kayıt açma alışkanlığı, bu boşluğu kapatır.
Kanalların tek yerde toplanmasını unified inbox yazısında ele aldık.
Bilgi birikimi ve tekrar eden sorunlar
Destek ekiplerinin çoğu, aynı soruları defalarca yanıtlar. Bu tekrar, hem zaman kaybı hem tutarsızlık kaynağıdır.
Çözüm kayıtlarının yapılandırılmış tutulması, bu bilgiyi ekibin ortak birikimine dönüştürür.
Sık karşılaşılan sorunlar için hazır çözüm metinleri tanımlanabilir; bu, hem hızı hem tutarlılığı artırır.
Tekrar eden taleplerin kök nedeni ayrıca ele alınmalıdır. Aynı sorunun yüz kez çözülmesi, bir kez ortadan kaldırılmasından pahalıdır.
Bunun için talep türlerinin dönemsel olarak gruplanması ve en yoğun üç başlığın incelenmesi yeterlidir.
Ürün veya süreç tarafında yapılan bir düzeltme, destek yükünü kalıcı olarak azaltır.
Sık sorulanlar
Talepler e-postadan otomatik açılabilir mi?
Kanal entegrasyonu kurgulanabilir; kapsamı kurulum aşamasında birlikte belirliyoruz.
Müşteri talebinin durumunu görebilir mi?
Bilgilendirme mesajlarıyla mümkündür; müşteri portalı kapsamını ihtiyacınıza göre değerlendiriyoruz.
SLA süresi durdurulabilir mi?
Müşteriden bilgi beklenen sürelerde durdurma tanımlanabilir; bu, adil ölçüm için gereklidir.
Bakım sözleşmesiyle ilişkilendirilebilir mi?
İlişkilendirilebilir; bakım sözleşmesi yönetimi yazısına bakın.
Servis talebi yönetimi, müşteri ilişkisinin en kırılgan noktasını kayıt altına alan yapı. Kaydedilmeyen talep, çözülmeyen talebe dönüşüyor.
SLA tanımlarken gerçekçi olun. Tutulamayan bir taahhüt, hiç taahhüt vermemekten daha çok zarar veriyor.
Uyarıları da aşımdan önceye kurun; sonradan gelen uyarı yalnızca kötü haber taşıyor.
Telefonla gelen taleplerin de kayda geçmesini sağlayın. Kaydedilmeyen iş, hem ölçülemiyor hem ekibin gerçek yükünü gizliyor.
Tekrar eden talep başlıklarını dönemsel olarak inceleyin; aynı sorunu yüz kez çözmek yerine bir kez ortadan kaldırmak her zaman daha ucuza geliyor.
EQLEM ekibiyle görüşerek destek süreçlerinizi planlayabilirsiniz.