Küçük işletmeler için müşteri desteği eskalasyon sürecinin yönetim katmanlarına veya karmaşık bir kural kitabına ihtiyacı yoktur. Ortak bir karara ihtiyacı vardır: Bir talep mevcut sorumlusu tarafından artık ele alınamıyorsa, sonra ne olur?
Küçük ekiplerde destek sorumlulukları genellikle paylaşılır. Bir müşteri mesajını okuyan kişi yanıt verebilir, farklı bilgiye sahip bir iş arkadaşına ihtiyaç duyabilir ya da ayrı bir işlem gerektiren bir sorun fark edebilir. Mutabık kalınmış bir yol olmadan talepler yanlış yerde bekleyebilir, mesajlar içinde elden ele dolaşabilir veya yeni sorumluya hikâyenin yalnızca bir bölümü ulaşabilir.
Uygulanabilir bir eskalasyon yolu, sonraki adımı netleştirirken müşteri görüşmesini bütün hâlde tutar. Tetikleyicileri tanımlar, sonraki sorumluyu belirler, bağlamı kaydeder ve çözüm bulunana kadar talebi görünür tutar. Sonuç yalnızca kişiler arasında daha hızlı ilerleme değildir. Müşteriler için daha güvenilir bir deneyim ve ekibin işini yönetmesi için daha net bir yoldur.
Önce ekibiniz için eskalasyonun ne anlama geldiğini tanımlayın
Eskalasyon, bir destek görüşmesinin başarısız olduğunun göstergesi değildir. Talebin farklı türde bir ilgiye ihtiyaç duyduğu durumlarda yapılan kontrollü bir devirdir. Küçük bir işletmede bu, bir talebin belirli bir alandan sorumlu kişiye aktarılması, işin aciliyetinin artırılması veya bildirilen bir sorunun takip için kayda alınması anlamına gelebilir.
Herkesin uygulayabileceği kısa bir tanım yazın. Örneğin, mevcut sorumlu elindeki bilgi ve yetkiyle talebi çözemediğinde, müşteri üzerindeki etki daha hızlı ilgilenilmesini gerektirdiğinde veya görüşme adı belirlenmiş bir sorumlu gerektiren operasyonel bir sorunu ortaya çıkardığında talebi eskale edin.
Bu tanım, ekip üyelerine erken harekete geçme yetkisi verir. Ayrıca eskalasyonun, o gün gelen kutusuyla ilgilenen kişiye göre değişen tutarsız bir değerlendirmeye dönüşmesini önler.
Net eskalasyon tetikleyicileri kullanın
Tetikleyiciler, niyeti tekrarlanabilir bir sürece dönüştürür. Müşteriyi veya talebi ele alan kişiyi suçlamak yerine talebi tanımlamalıdır. Listeyi, insanların hatırlayıp kullanabileceği kadar kısa tutun.
- Farklı bilgi gerekir: Talep, başka bir kişinin sahip olduğu bilgiye veya verebileceği karara ihtiyaç duyar.
- Farklı bir sorumlu yetkilidir: Soru, belirli bir ekip arkadaşına ya da işletmenin belirli bir alanına ait işle ilgilidir.
- Öncelik değişmelidir: Talebin etkisi, normal destek işlerinden daha erken değerlendirilmesini gerektirir.
- Tekrarlanan veya farklı bir sorun bildirilir: Görüşme, ayrıca kaydedilmesi, atanması ve takip edilmesi gereken bir sorunu ortaya çıkarır.
- Görüşme ilerleyemez: Mevcut sorumlu makul sonraki adımları atmıştır ancak ilerlemek için başka birine ihtiyaç vardır.
Bu tetikleyicilerin olası her durumu kapsaması gerekmez. Ekibe güvenilir bir başlangıç noktası sunarlar. Bir talep tetikleyiciyle eşleşmiyorsa mevcut sorumlu yanıt vermeyi sürdürebilir. Eşleşiyorsa ekip, talebin bir iş arkadaşına gayriresmî olarak bahsedilmesinden ziyade açık bir sonraki adım gerektirdiğini bilir.
Talep devredilmeden önce sonraki sorumluyu seçin
Her eskalasyonun adı belirlenmiş bir sonraki sorumlusu olmalıdır. “Ekip” bir sorumlu değildir; “ilgilenin” gibi belirsiz bir talimat da öyle değildir. Adı belirlenmiş bir sorumlu, talebi kimin değerlendirmesi, sonraki adıma karar vermesi veya işi koordine etmesi gerektiğini açıkça ortaya koyar.
Bu, ilk destek sorumlusunun görüşmeden ayrıldığı anlamına gelmez. Müşteriyle iletişim kurmak için hâlâ en uygun kişi olabilir. Önemli ayrım, müşteri yazışmasının sahipliği ile çözüm için gereken işin sahipliği arasındadır. Küçük bir ekipte iki rolü de aynı kişi üstlenebilir, ancak roller yine de net olmalıdır.
Sonraki sorumluyu atarken devir nedenini ekleyin. Ondan ne istendiğini belirtin: bir yanıt, karar, inceleme, öncelik değerlendirmesi veya kayda alınmış bir sorunun sahipliği. Bu, bir talebin yeniden atandığı ancak yeni sorumlunun önce nedenini anlamak zorunda kaldığı yaygın destek talebi eskalasyonu sorununu önler.
Müşteri desteği, küçük ekiplerin talepleri almasına, görüşmeleri düzenlemesine ve her yazışmayı tek yerde tutarken sorumlular atamasına yardımcı olabilir. Bu, özellikle sorumluluklar dönüşümlü olduğunda veya aynı müşteri geçmişini birkaç kişinin görmesi gerektiğinde faydalıdır.
Basit bir sahiplik kuralı belirleyin
Yararlı bir kural şudur: Eskalasyonu alan kişi sahipliği kabul ederken, devreden kişi bağlamı kaydeder. Kabul, açık bir durum değişikliği veya sonraki sorumlunun talebi aldığını doğrudan teyit etmesi olabilir.
Hedeflenen sorumlu uygun değilse, yedek olarak kimin devreye gireceğine önceden karar verin. Küçük ekiplerin uzun bir yedek zincirine ihtiyacı yoktur. Acil veya tıkanmış bir talebin sahipsiz kalmaması için bilinen bir alternatife ihtiyaçları vardır.
Eskalasyon, çözüme birden fazla kişi katkı sağlasa bile müşteri talebinin her zaman görünür tek bir sonraki sorumlusu olduğunda işe yarar.
Her devirde müşteri bağlamını koruyun
Dahili sorumlu değiştiği için müşterilerin durumlarını yeniden anlatmak zorunda kalmaması gerekir. Eskalasyon kaydı, sonraki kişinin görüşmeyi dağınık mesajlardan yeniden kurmadan veya müşteriden baştan başlamasını istemeden anlamasını sağlamalıdır.
Bir talebi devretmeden önce temel bağlamı kısa bir dahili özette toplayın:
- müşterinin ne talep ettiği veya bildirdiği;
- halihazırda neyin iletildiği veya denendiği;
- talebin neden eskale edildiği;
- artık hangi kararın, bilginin veya işlemin gerektiği;
- sonraki adımdan kimin sorumlu olduğu ve önceliğinin ne olduğu.
Bu özet, görüşme geçmişinin yerine geçmemeli; onu tamamlamalıdır. Özgün mesajlar önemini korur çünkü müşterinin kendi ifadelerini ve talebin arkasındaki ayrıntıları içerir. Özet yalnızca yeni sorumlunun duruma daha hızlı hâkim olmasını sağlar.
Bağlamı uzun bir dahili anlatıya dönüştürmemeye dikkat edin. Amaç harekettir. Sonraki sorumlu “ne oldu, ne gerekiyor ve şimdi ne yapmalıyım?” sorularını hızla yanıtlayabiliyorsa devir amacına ulaşmıştır.
Gerektiğinde müşteri talebini operasyonel sorundan ayırın
Her destek talebi operasyonel bir sorun değildir. Birçoğu doğrudan müşteri görüşmesinde çözülebilir. Ancak bazı talepler kendi başına çalışma gerektiren bir problemi ortaya çıkarır: Acil olarak incelenmesi, önceliklendirilmesi, atanması veya kayda geçirilmesi gereken bir durum olabilir.
Böyle bir durumda, sorun ile kaynak müşteri talebi arasındaki bağlantıyı ekibinizin çalışma bağlamında koruyarak ayrı bir olay kaydı oluşturun. Destek görüşmesi müşteriyle iletişime odaklanmayı sürdürebilir. Olay kaydı ise dahili probleme, sorumlusuna, önceliğine, son tarihine ve çözümüne odaklanabilir.
Bu ayrım, ekibin iki zayıf kalıptan kaçınmasına yardımcı olur. İlki, müşteri yanıt aldıktan sonra gözden kaçabilecek operasyonel bir sorunu destek görüşmesinin içinde gömülü bırakmaktır. İkincisi ise tüm görüşmeyi olay kaydına taşımak ve müşteriye ne söylendiğini gözden kaçırmaktır.
Operasyonel olay, küçük işletmelere operasyonel sorunları kaydetmek, sorumlular atamak ve durumlarını takip etmek için merkezi bir alan sunar. Müşteri desteğiyle birlikte kullanıldığında, dağınık mesajlara veya notlara dayanmadan bildirilen bir sorundan görünür takibe uzanan net bir yol oluşturur.
Müşterinin ne duyması gerektiğine karar verin
Eskalasyon dahili bir süreçtir, ancak müşteri mesajının kaybolup kaybolmadığını düşünerek bekletilmemelidir. Doğru ve yararlı bir güncelleme gönderin. Talebin incelendiğini teyit edin, biliniyorsa sonraki adımı açıklayın ve ekibin henüz doğrulamadığı bir sonucu vaat etmeyin.
Doğrudan bir güncelleme, sahiplik gösterdiği için güven oluşturur. Amaç her dahili devri açıklamak değildir. Talebin aktif kaldığını ve müşterinin bilgileri tekrar etmesine gerek olmadığını netleştirmektir.
Talep çözülene kadar durumu takip edin
Eskalasyon, atamayla sona ererse eksik kalır. Ekip, talebin bilgi bekleyip beklemediğini, incelenip incelenmediğini, üzerinde çalışılıp çalışılmadığını, müşteriye yanıt vermeye hazır olup olmadığını veya çözülüp çözülmediğini gösteren görünür bir yönteme ihtiyaç duyar. Ekibinizin kullandığı gerçek aşamaları yansıtan durumlar seçin ve bunları tutarlı uygulayın.
Her eskale edilmiş talep için şu üç soruyu gözden geçirin:
- Sonraki işlemden kim sorumlu?
- Mevcut durum nedir?
- Müşteri bir sonraki anlamlı güncellemeyi veya nihai yanıtı almadan önce ne olmalı?
Bu sorular basittir, ancak taleplerin belirsiz bir ara durumda kaybolmasını önler. Ayrıca biri uzaktayken veya başka bir ekip arkadaşının yardım etmesi gerektiğinde ortak destek işinin devralınmasını kolaylaştırır.
Çözüm, yalnızca dahili bir görevin tamamlanmasından daha fazlasını ifade etmelidir. Talebi kapatmadan önce müşterinin uygun yanıtı aldığını ve ayrı bir olay kaydının kendi işi için doğru durumda olduğunu doğrulayın. Müşteri ilk güncellemeyi aldıktan sonra bir olay kaydı açık kalabilir; her iki kaydın da net sorumluları ve sonraki adımları olduğu sürece bu uygundur.
Destek iş akışını geliştirmek için eskalasyonları gözden geçirin
Eskalasyonlar, destek işinin nerede zorlaştığına ilişkin yararlı sinyallerdir. Düzenli bir gözden geçirmenin uzun bir toplantı olması gerekmez. Son eskalasyonlara bakın ve tetikleyicinin net olup olmadığını, doğru sorumlunun seçilip seçilmediğini, bağlamın eksiksiz olup olmadığını ve müşterinin zamanında bir güncelleme alıp almadığını sorun.
Özellikle tekrarlanan nedenlere dikkat edin. Aynı talep türü sürekli farklı bir sorumluya ihtiyaç duyuyorsa ekibin daha net sahiplik yönlendirmesine ihtiyacı olabilir. Aynı bildirilen sorun birkaç görüşmede ortaya çıkıyorsa daha görünür olay takibini hak edebilir. Devirlerde sıkça bağlam eksikse kısa bir dahili kontrol listesi anlamlı bir fark yaratabilir.
İyileştirmeleri küçük ve uygulanabilir tutun. Bir tetikleyiciyi güncelleyin, yedek sorumluyu netleştirin, bir durumu iyileştirin veya asgari devir özeti üzerinde anlaşın. Zamanla bu değişiklikler, gereksiz süreç eklemeden desteği daha tutarlı hâle getirir.
Sonuç: Eskalasyonu desteğin net bir devamı hâline getirin
Güçlü bir eskalasyon yolu, küçük ekiplere müşteri taleplerini ne zaman eskale edeceklerine dair uygulanabilir bir yanıt sunar. Tetikleyiciyi tanımlayın, sonraki sorumluyu belirleyin, görüşme bağlamını koruyun, gerektiğinde operasyonel sorunları ayırın ve hem müşteri talebini hem de dahili işi çözüme kadar takip edin.
Müşterilere kendilerini tekrar ettirmeden eskalasyonları netleştirin. Önce tetikleyicileriniz ve sahiplik kurallarınız üzerinde anlaşın; ardından her sonraki adımı görünür tutmak için ortak bir destek ve olay takip iş akışı kullanın.
