Yardım Masası Yazılımı: Sağlam Bir Talep İş Akışı Oluşturun
Yardım masası yazılımı, net bir çalışma biçimini desteklediğinde en faydalı hâle gelir. Bir araç satın almak, bir talebin kime ait olduğuna, bir biletin ne zaman beklemesi gerektiğine veya neyin çözüldü sayılacağına karar vermez. Bu seçimleri önce ekibinizin yapması gerekir.
Bu kılavuz, mevcut destek e-postanız etrafında pratik bir bilet iş akışını nasıl tasarlayacağınızı gösterir. Özellik karşılaştırmasına değil, çalışma modeline odaklanır. E-posta, atama, durum, öncelik, etiketler, notlar ve bilet geçmişinin tek bir üründe nasıl bir araya geldiğini görmek istiyorsanız adımları uygularken Deskhero'nun paylaşılan gelen kutusu ve biletleme özelliklerini inceleyin.
Bir müşteri talebinin izlemesi gereken yol ile başlayın
Herhangi bir yapılandırma yapmadan önce, talebin ulaşmasından çözülmesine kadar izlediği normal yolu çizin. Yararlı bir ilk sürüm basittir: bir mesaj gelir, biri onu inceler, doğru kişi sorumluluğu üstlenir, ekip işi yapar ve müşteri nihai bir yanıt alır.
Ardından bu yolu düzenli olarak bozan istisnaları listeleyin. Bir faturalandırma sorusu başka bir ekibe ihtiyaç duyabilir. Teknik bir sorun araştırma gerektirebilir. Bir müşteri yanıt vermeyi bırakabilir. İki mesaj aynı sorunu açıklıyor olabilir. Bu durumlar, iş akışınızın hangi durumlara, devirlere ve koruyucu önlemlere ihtiyaç duyduğunu gösterir.
Haritayı kararlar etrafında şekillendirin. Her aşama için şu soruları yanıtlayın:
- Bir sonraki işlemden kim sorumlu?
- Bilet ilerlemeden önce hangi bilgilerin mevcut olması gerekiyor?
- Sorumlu kişi müsait olmadığında ne olmalı?
- Başka bir User, özet istemeden mevcut durumu nasıl anlayabilir?
- Talebin gerçekten tamamlandığını gösteren olay nedir?
Herhangi bir User bir bileti açıp ne olduğunu, bundan sonra ne olacağını ve bir sonraki adımdan kimin sorumlu olduğunu anlayabiliyorsa iş akışı sağlıklıdır.
Kesin anlamlara sahip küçük bir durum kümesi kullanın
Durum adları çoğu zaman açık görünür, ancak ekipler bunları farklı yorumlar. Her durumu, bir sonraki işlemden kimin sorumlu olduğuna göre tanımlayın. Bu tek kural, birçok biletin takılıp kalmasını önler.
| Durum amacı | Şu durumda kullanın | Bir sonraki işlemi kim yapar |
|---|---|---|
| Yeni iş | Talep ulaşmış ancak henüz incelenmemişse | İlk değerlendirmeyi yapan ekip |
| Aktif çalışma | Bir User araştırma yapıyor veya yanıt hazırlıyorsa | Atanan User |
| Beklemede | Ekip, müşteriden veya başka bir taraftan bilgi ya da işlem bekliyorsa | Adı belirtilen dış taraf; ekip içinde ise takibi yapacak sorumlu kişi |
| Çözüldü | Ekip talep edilen işi tamamlayıp sonucu ilettiyse | Müşteri yanıt vermediği sürece hiç kimse |
Her departman, konu veya aciliyet düzeyi için ayrı bir durum oluşturmaktan kaçının. Sorumluluk için atamaları veya grupları, konular için etiketleri, aciliyet için de önceliği kullanın. Her alanın tek bir amacı olduğunda User'lar kuyruğu tutarlı biçimde okuyabilir.
Sorumluluğu, önceliği ve sınıflandırmayı birbirinden ayırın
Bu üç kavram farklı sorulara yanıt verir. Sorumluluk, kimin işlem yapması gerektiğini söyler. Öncelik, ne kadar hızlı ilgilenilmesi gerektiğini belirtir. Sınıflandırma ise talebin ne tür bir talep olduğunu gösterir. Bunları birbirine karıştırmak belirsiz kuyruklara ve güvenilmez raporlara yol açar.
Bir User'ı veya grubu sorumlu kılın
Açık durumdaki her biletin belirgin bir sorumlusu olmalıdır. Paylaşılan sorumluluk kolayca hiç kimsenin sorumlu olmamasına dönüşür. Bir grup yeni işleri alabilir, ancak çalışma başladığında belirli bir User sorumluluğu devralmalıdır. Devamsızlıklar için bir yedekleme kuralı, uzmanlık değiştiğinde ise bir devir kuralı belirleyin.
Önceliği gözlemlenebilir koşullarla tanımlayın
Öncelik kurallarını sade bir dille yazın. Örneğin birçok müşteriyi etkileyen bir kesinti, genel bir sorudan daha yüksek önceliğe sahip olmalıdır. Önceliğin, sabırsızlık gösteren her talebi acil olarak işaretlemenin bir yoluna dönüşmesine izin vermeyin. Kısa ve yazılı bir tanım, User'lara tutarlı biçimde uygulayabilecekleri bir gerekçe sunar.
Etiketleri süsleme için değil, gelecekteki işlemler için kullanın
Bir etiketi yalnızca ekibin işi yönlendirmesine, yararlı bir segment bulmasına veya tekrarlanan bir soruyu yanıtlamasına yardımcı oluyorsa oluşturun. Etiketleri düzenli aralıklarla gözden geçirin ve birbirine çok benzeyenleri birleştirin. Daha küçük bir kelime hazinesi, daha temiz görünümler ve daha güvenilir analizler sağlar.
Bağlamı koruyan devirler tasarlayın
Bir devir, bir sonraki User'ı vakayı baştan oluşturmaya zorlamadan sorumluluğu aktarmalıdır. Müşteri yanıtlarını ve özel notları bilet zaman akışında tutun. Yeniden atama yapmadan önce mevcut bulguyu, geriye kalan soruyu ve beklenen bir sonraki işlemi ekleyin.
Müşteriye gönderilmemesi gereken iş birliği bilgileri için dahili notları kullanın. Alındığını doğrulamanız, bilgi istemeniz veya bir gecikmeyi açıklamanız gerektiğinde müşteriye yanıt verin. Bu ayrım konuşmayı açık tutar ve çalışma arkadaşlarınıza ihtiyaç duydukları bağlamı sağlar.
İki bilet aynı sorunla ilgili olduğunda hangi kaydın asıl kaynak olacağına karar verin. Yinelenen bileti ana biletle birleştirin ve ardından tek bir yerden devam edin. Paralel kayıtlar çelişkili yanıtları teşvik eder ve geçmişi böler.
Hizmet hedeflerini iş akışı istikrarlı hâle geldikten sonra ekleyin
Hedefler, belirsiz sorumlulukları düzeltemez. Önce yeni işlerin incelendiğinden, atamaların görünür olduğundan ve bekleyen biletler için bir takip yolu bulunduğundan emin olun. Ardından yanıt ve çözüm beklentilerini, ekibinizin gerçekten çalıştığı saatler etrafında tanımlayın.
Yalnızca hedefi kaçırmış biletleri değil, hedefe yaklaşan biletleri de izleyin. Amaç, hâlâ zaman varken işlem yapılmasını teşvik etmektir. Deskhero'nun SLA politikaları ilk yanıt ve çözüm hedeflerini, çalışma saatleri programlarını, filtreleri, uyarıları ve gösterge paneli görünümünü destekler.
İş akışını gerçek senaryolarla test edin
Süreci kullanıma sunmadan önce temsili talepleri adım adım inceleyin. Basit bir soruyu, sorumlusunun değiştiği bir talebi, müşterinin yanıtının beklendiği bir vakayı, yinelenen bir bileti ve yeniden açılmış bir konuşmayı dahil edin. Her senaryoda bir sonraki işlemin ve sorumlunun hâlâ açık olup olmadığını kontrol edin.
Testi, iş akışını tasarlamayan User'larla gerçekleştirin. Sözlü yönlendirmeye ihtiyaç duyuyorlarsa kurallar veya alan adları henüz yeterince açık değildir. Süreci ayarlayın, ardından senaryoları tekrarlayın.
Kullanıma sunma sırasında kısa bir istisna günlüğü tutun. User'ların hangi durumu, sorumluyu veya önceliği seçeceklerini bilmediği durumları kaydedin. Bu günlüğü düzenli olarak inceleyin ve iş akışını yalnızca tekrarlanan bir örüntü ortaya çıktığında değiştirin. Bu, sistemin tek seferlik kurallarla dolmasını önler.
Salt etkinliği değil, akışı ölçün
Yararlı raporlama, müşterilerin nerede beklediğini ve işin nerede takıldığını ortaya çıkarmalıdır. Bilet hacmi, ilk yanıt süresi, çözüm süresi, birikmiş işlerin yaşı ve yeniden açılan taleplerle başlayın. Tek bir ortalamayı tüm hikâye olarak görmek yerine eğilimlere ve segmentlere bakın.
Her metriği bir kararla eşleştirin. Eski biletlerden oluşan büyüyen bir birikmiş iş, daha net bir sorumluluk dağılımı veya daha fazla kapasite gerektirebilir. Yavaş ilk yanıtlar, ilk değerlendirme kapsamının yetersiz olduğuna işaret edebilir. Sık yeniden açılmalar, eksik çözümlere veya kafa karıştırıcı yanıtlara işaret edebilir. Daha kapsamlı bir ölçüm planı için yardım masası raporlama metrikleri kılavuzumuza göz atın.
Kanıtlar tekrarlanan bir darboğaz gösterdiğinde iş akışını gözden geçirin. Yazılım bunlara izin veriyor diye alanlar veya adımlar eklemeyin. En iyi yardım masası kurulumu, sorumluluğu, bağlamı ve bir sonraki işlemleri güvenilir biçimde görünür kılan en küçük kurulumdur.
Pratik bir kullanıma sunma kontrol listesi
- Normal talep yolunu ve yaygın istisnaları haritalayın.
- Her durumu, bir sonraki işlemden kimin sorumlu olduğuna göre tanımlayın.
- Sorumluluğu, aciliyeti ve konu sınıflandırmasını birbirinden ayırın.
- Tam bir devrin neleri içermesi gerektiğini belgeleyin.
- İş akışını gerçekçi destek senaryolarıyla test edin.
- Yönlendirme ve sorumluluk güvenilir hâle geldikten sonra hizmet hedefleri ekleyin.
- Operasyonel kararlara bağlı küçük bir metrik kümesi seçin.
- İstisnaları gözden geçirin ve User'ların tutarsız biçimde uyguladığı kuralları basitleştirin.
Bu kararlar yazılı hâle getirildiğinde yapılandırma çok daha kolay olur. Aracınız, üzerinde uzlaşılan süreci görünür ve tekrarlanabilir kılmalı, aynı zamanda olağandışı durumlar için yeterli esnekliği bırakmalıdır.