Yalnızca ilk yanıt süresi, müşterilerin yardım alıp almadığını neden göstermez?
Hızlı bir ilk yanıt önemlidir. Müşteriye talebinin görüldüğünü ve birinin sorumluluk aldığını gösterir. Ancak sorunun ele alınıp alınmadığını göstermez. Bir ekip dakikalar içinde yanıt verebilir ama yine de bir soruyu yanıtsız, bir iade talebini çözümsüz veya bir sorunu karar bekler durumda bırakabilir.
Bu nedenle küçük işletmeler için müşteri desteği çözüm süresi, ilk yanıt süresiyle birlikte değerlendirilmelidir. Çözüm süresi, bir talebi ulaştığı andan ekibin müşterinin ihtiyacının makul biçimde karşılandığını kabul edebileceği ana kadar takip eder. Müşteri deneyimi ve görünür konuşmanın arkasında gerçekleşen çalışmalar hakkında daha kapsamlı bir bakış sağlar.
Küçük ekiplerin başlamak için karmaşık bir puan kartına ihtiyacı yoktur. İki pratik soru sorun: Müşteri bizimle ilk ne zaman iletişime geçti ve ilerleyebilmesi için gereken işlemi ne zaman tamamladık veya yanıtı ne zaman sunduk? Bu noktalar arasındaki süre, taleplerin nerede beklediğini ortaya çıkarabilir: atamadan önce, kurum içi devir sırasında, bilgi toplanırken veya bir yanıt hazırlandıktan sonra.
İlk yanıt süresini, talebin alındığının bildirilmesini güvence altına almak için kullanın. Çözüm süresini ise tamamlanmayı anlamak için kullanın. İkisine birlikte bakmak, talebi gerçekten ilerletmeyen hızlı yanıtlara dar biçimde odaklanmayı önler.
Yaygın talep türleri için pratik bir çözüm noktası tanımlayın
Çözüm süresi yalnızca ekip çözüldü tanımını paylaştığında yararlıdır. Bu tanım olmadan, bir kişi talimatları gönderdikten sonra talebi kapatabilirken bir başkası, müşteri başarıyı doğrulayıncaya kadar benzer bir talebi açık tutabilir. Bu tutarsızlık karşılaştırmaları güvenilmez kılar ve farklı müşteri deneyimleri yaratabilir.
En sık aldığınız talep türleri için kısa bir çalışma tanımı oluşturun. Yalnızca ekibin yaptığı son işlemi değil, müşteri sonucunu tanımlayın. Örneğin:
- Basit soru: müşteri doğru ve anlaşılır bir yanıt aldığında ve ekipten başka bir işlem gerekmediğinde çözülür.
- Hesap veya sipariş talebi: istenen değişiklik, kontrol veya açıklama tamamlanıp müşteriye iletildiğinde çözülür.
- Sorun bildirimi: bir düzeltme, geçici çözüm veya net bir sonraki adım sunulduğunda ve ekip işin kendisine düşen kısmını tamamladığında çözülür.
- Müşterinin yanıtını bekleyen talep: ekip bekliyor diye talebi tamamen çözülmüş saymayın. Bekleme durumunu netleştirin ve süreciniz için ne zaman takip yapılmasının veya kapatmanın uygun olduğuna karar verin.
Tanımı yoğun bir gün içinde kullanılabilecek kadar kısa tutun. Her istisnayı kapsaması gerekmez. Amaç, farklı bir işlem gerektiren olağandışı durumlara yönelik bir notla birlikte tutarlı bir varsayılan yaklaşım oluşturmaktır.
Tamamlanmış bir iç görevi, tamamlanmış bir müşteri talebinden ayırmak da faydalıdır. Ekip bir iş arkadaşına soru yöneltmiş veya ikame ürün hazırlamış olabilir; ancak müşteri sonucu alana kadar destek talebi hâlâ aktif olabilir. Bu ayrım, destek talebi çözüm sürecini daha dürüst ve yararlı hâle getirir.
Gelen talepten atanan sorumluya ve kapanışa uzanan basit bir akış oluşturun
Net bir destek talebi akışı, destek çözüm süresini takip etmenin temelidir. Ekibin kullanmayı bırakacağı kadar çok aşama eklemeden, bir sonraki işlemi ve sorumlu kişiyi açıkça göstermelidir.
- Alın ve inceleyin: gelen talebi kaydedin ve müşterinin neye ihtiyacı olduğunu belirleyin.
- Bir sorumlu atayın: başkaları katkıda bulunsa bile her aktif talebin ilerletilmesinden sorumlu tek bir kişi atayın.
- Yanıtlayın ve inceleyin: müşteriye talebin alındığını bildirin, eksik ayrıntıları isteyin ve talebi çözmek için gereken çalışmayı tamamlayın.
- Mevcut durumu kaydedin: aktif çalışmayı, müşterinin yanıtını ya da kurum içi bir yanıtı veya kararı bekleyen taleplerden ayırın.
- Çözün ve kapatın: yararlı olduğu durumlarda net bir son mesajla, yalnızca ekibin tanımladığı çözüm noktası karşılandığında kapatın.
Atama, özellikle ortak gelen kutusunda önemlidir. Herkes bir talebi görebildiğinde ama kimse ona sahip çıkmadığında, kişiler başka birinin yanıt vereceğini varsayabilir. Net destek talebi sorumluluğu bu sessiz gecikmeyi önler. Sorumlunun her görevi kişisel olarak tamamlaması gerekmez; ancak takip yapması, müşteriyi bilgilendirmesi ve talebin kapanışa ulaşmasını sağlaması gerekir.
Sorumluluk değişirse devri açıkça kaydedin. Kimlerin devraldığını, neler olduğunu, hâlâ neye ihtiyaç duyulduğunu ve müşterinin bilgilendirilip bilgilendirilmediğini not edin. Bu, bir talebin devam ettirilmek yerine yeniden keşfedilmesini önler.
Konuşmaları, iç ilerlemeyi ve sorumluluğu bir arada tutun
Küçük ekipler çoğu zaman gelen kutusuna, sohbet mesajlarına, notlara ve kişisel hafızaya dağılmış taleplerle başlar. Bu, düşük hacimde işe yarayabilir; ancak kısa süre içinde müşterinin yanıt alıp almadığını, bir iş arkadaşının inceleme yapıp yapmadığını veya talebin ne kadar süredir açık olduğunu anlamak zorlaşır.
Ortak bir destek çalışma alanı, ekibe talepleri almak, konuşmaları düzenlemek, sorumlular atamak ve her yanıtı çözüme kadar takip etmek için tek bir yer sunar. Müşteri desteği, küçük ekiplerin her müşteri konuşmasının bağlamını korurken ortak gelen kutusundaki talepleri yönetmesine yardımcı olarak bu yaklaşımı destekler.
Her talep için, müşteriye yönelik mesajları kısa iç ilerleme notlarıyla birlikte tutun. Bir sonraki adımı etkileyen bilgileri kaydedin: müşterinin ne istediği, nelerin kontrol edildiği, kimin sorumlu olduğu, ilerlemeyi neyin engellediği ve müşterinin sizden ne zaman yeniden haber alması gerektiği. Kısa ve güncel bir güncelleme, uzun ve yinelenen bir konuşma dökümünden daha yararlıdır.
İlgili müşteri bağlamını erişilebilir tutmak, daha geniş bir iş akışının önemli bir parçasıdır. Destek çalışmasının ekibinizin genel sürecine nasıl uyduğunu değerlendirirken ilgili Müşteri kaynaklarını ayrıca inceleyin.
Aşırı ölçüm yapmadan darboğazları belirlemek için yanıt ve çözüm süresini kullanın
Destek çözüm süresini takip ederken, bireysel performansı değerlendirmeden önce örüntülere bakın. Küçük bir ekipte uzun çözüm süresi; zor bir talepten, eksik bilgiden, ulaşılamayan bir müşteriden veya destek dışındaki bir bağımlılıktan kaynaklanabilir. Bu sayı bir hüküm değil, konuşma için başlangıç noktasıdır.
Yalnızca ekibinizin etkileyebileceği ölçütleri gözden geçirin. İlk yanıt süresi, yeni taleplerin alındığının bildirilip bildirilmediğini gösterir. Çözüm süresi, müşteri ihtiyacını tamamlamanın ne kadar sürdüğünü gösterir. Açık talep sayısı mevcut iş yükünü gösterir. Kurum içi yanıt bekleyen taleplerin basit bir sayımı, tekrarlayan bir devir sorununu ortaya çıkarabilir.
Mümkün olduğunda benzer talepleri karşılaştırın. Basit bir sorunun ve karmaşık bir sorun bildiriminin aynı hızda kapanması beklenmemelidir. Karmaşık bir sınıflandırma sistemi kurmadan talepleri sorular, hesap konuları ve sorun bildirimleri gibi geniş gruplara ayırın. Bir grup düzenli olarak daha uzun süre açık kalıyorsa, çevresindeki iş akışını inceleyin.
Alışılmadık derecede uzun süreleri olan tekil destek taleplerini de okuyun. Tek bir uzun durum makul olabilir; aynı adımda takılan birkaç durum ise bir darboğaza işaret eder. Talepler sabahları atanmadan bekleyebilir, bir karar yavaş alınabilir veya müşterilerin ilk yanıtta istenebilecek ayrıntılara düzenli olarak ihtiyaç duyması söz konusu olabilir.
Geciken talepleri ve tekrarlanan nedenleri kısa bir haftalık rutinle gözden geçirin
Kısa bir haftalık değerlendirme, ölçümü iyileştirmeyle bağlantılı tutar. Aktif kuyruğa ve kapanması en uzun süren destek taleplerine bakmak için düzenli zaman ayırın. Amaç sırf raporlama yapmak değildir. Gelecek haftanın müşteri desteği yanıt ve çözüm süresini daha güvenilir hâle getirecek bir veya iki değişikliği bulmaktır.
Tekrarlanabilir bir gündem kullanın:
- Ekibin türü için beklediğinden daha uzun süredir açık olan her talebi kontrol edin.
- Her aktif talebin bir sorumlusu ve görünür bir sonraki adımı olduğunu doğrulayın.
- En uzun sürede çözülen talepleri okuyun ve zamanın nerede harcandığını belirleyin.
- Eksik müşteri bilgileri, belirsiz sorumluluk veya tekrarlayan bir kurum içi bağımlılık gibi yinelenen nedenleri not edin.
- Çözüm tanımının tutarlı biçimde uygulanıp uygulanmadığına karar verin.
Konuşmayı yapıcı tutun. Bir talep gecikmişse, süreçte bu gecikmeyi olası kılan şeyin ne olduğunu sorun. Kaçırılan bir devir, eksik bir sorumluluk adımına işaret edebilir; tekrarlanan takip soruları ise belirsiz bir talep alma sürecine işaret edebilir. Bu yaklaşım, erken kapatmayı ödüllendirmek yerine sistemi iyileştirir.
İşin nerede beklediğini görecek kadar ölçüm yapın; ardından öğrendiklerinizi tek bir bekleme nedenini ortadan kaldırmak için kullanın.
Gelecek hafta test etmek üzere küçük bir iyileştirme seti seçin
Her darboğazı aynı anda gidermeye çalışmayın. Odaklı bir veya iki deneme seçin ve bunları sonraki haftalık oturumda değerlendirin. Her günün başında kuyruk sorumlusu atayabilir, yaygın sorun bildirimleri için ayrıntı kontrol listesi ekleyebilir veya her devirde adı belirtilmiş bir sonraki sorumlunun ve müşteri güncellemesinin yer alması konusunda anlaşabilirsiniz.
Beklenen etkiyi sade bir dille yazın: sorumlusu olmadan bekleyen daha az talep, inceleme öncesinde daha az karşılıklı mesajlaşma veya daha net kapanış kararları. Ardından ilgili talepleri gelecek hafta inceleyin. Bir değişiklik sürtünmeyi azaltıyorsa, onu standart küçük ekip destek talebi çözüm iş akışının parçası yapın. Azaltmıyorsa değiştirin veya başka bir fikri test edin.
Sonuç
Ortak bir çözülme tanımıyla başlayın, her aktif talep için bir kişiyi sorumlu tutun ve konuşma ile ilerlemeyi aynı yerde saklayın. Yanıt ve çözüm süresini birlikte gözden geçirin; ardından en çok fayda sağlayacak birkaç iş akışı değişikliğini belirlemek için geciken destek taleplerini kullanın.
Net bir çözülme tanımını belgeleyin, her aktif talebe bir sorumlu atayın ve her hafta kapanması en uzun süren birkaç destek talebini gözden geçirin.