Bilet yaşam döngüsü ve Yardım Masasındaki Müşterilerle iletişim
Giriş
Bu yazımızda, Yardım masasında ticket oluşturulma şekline ve müşterinin sisteminize erişimine göre ticket oluşturma sürecini ele alacağız. Çeşitli bilet süreci yapılandırmalarında nelere dikkat etmeniz gerektiğine ilişkin ipuçları bulacaksınız.
Bu makale, çeşitli yapılandırmalara ilişkin ipuçları ve öneriler içerir ancak yapılandırmaların nasıl yapıldığını doğrudan içermez. İşte ilgili makaleler:
- Yardım Masası belgeleri
- Kullanım kılavuzu (iş akışı, bildirim ayarları)
Üç ana iletişim yolu
Biletin baştan sona yalnızca tek bir akış türünü izlediği düz ileri durumlarda bilet yaşam döngüsü şemasıyla başlayarak.
- e-posta
- Uygulamada tam kullanıcı
- Uygulamadaki yardım masası kullanıcısı
Bir destek bildiriminde oluşturma ve daha fazla iletişim
Bilet oluşturma ve daha fazla iletişim yukarıdaki yaklaşımları birleştirebilir.
E-posta yoluyla destek bildirimi oluşturmak ve ardından uygulama üzerinden takip etmek mümkündür (ister tam kullanıcı ister yardım masası kullanıcısı tarafından). Sistem üzerinden ticket oluşturup sonrasında sadece e-postaları takip etmek de mümkün.
Örnek 1
- Biletler e-posta yoluyla oluşturulur; müşteri, yardım masası adresine yeni bir e-posta gönderir.
- Müşteri, bilet yazarı olduğu için sisteme giriş yapar ve orada bileti görebilir.
- Müşteriler izinlerine göre durumları ve diğer alanları değiştirebilir, yorum bırakabilirler.
Örnek 2
- Müşteri sisteme giriş yapar ve yeni bir bilet oluşturur.
- Müşteri, güncellemeleri e-posta yoluyla alır ve yalnızca bu güncellemeleri izler ve artık sisteme giriş yapma ihtiyacı hissetmez.
Örnek 3
- Müşteri, yardım masası portalı aracılığıyla bir destek bildirimi oluşturur
- Müşteri yalnızca e-postaları takip etmek istediğine ve artık portalda oturum açmamaya karar verir
- Müşteri daha sonra portal üzerinden takip etmek istediğine karar verir, I'i günlüğe kaydeder ve portal üzerinden bazı yanıtlar girer.
Müşterilerinizin rahatlığı adına, hangi yöntemlerle bilet oluşturmalarına ve/veya güncellemelerine izin vermek istediğinize karar verebilirsiniz. Ancak en önemlisi, biletlerin çıkmazda kaybolmaması için olası her durumu göz önünde bulundurmanız gerekir. İş akışı ve diğer yapılandırmalar gerekli tüm seçenekleri sağlar.
Ortak sorunlar
İstemci normal görev bildirimine yanıt verir ancak yanıt düzgün şekilde işlenmez.
Bu hikaye Örnek 2 ile ilgilidir. Müşteriler bir ticket'a e-posta yoluyla yanıt verdiklerini sanıyorlar, ancak e-posta mevcut ticket ile eşleştirilmiyor ve bunun yerine yeni bir ticket oluşturuluyor veya e-posta sisteme hiç ulaşmıyor. Müşteri bir bildirime yanıt veriyor veya yanlışlıkla yeni bir e-posta oluşturuyor.
Nedeni: E-posta bildirim ayarları, bildirim adresine yanıt beklenmemektedir.
Çözüm: Müşteri yanıtının yardım masasının belirttiği adrese gönderilmesi ve destek bildirim numarasını içermesi gerekir. Bildirim e-posta adresi (Yönetim >> Ayarlar >> E-posta bildirimleri >> Bildirim e-posta adresi (FROM)) müşterilerden gelen yanıtları yakalamak ve bunları bildirimin ilk gönderildiği destek bildirimiyle eşleştirmek için yardım masası posta adresiyle aynı olabilir.
Başka bir seçenek de istemci kullanıcılarına düzenli e-posta bildirimlerini devre dışı bırakmaktır. Biletlerden alacakları tek e-posta, operatörler tarafından yardım masası e-posta şablonları aracılığıyla aktif olarak gönderilecek.
Temel çıkarım: Müşterileriniz doğal olarak aldıkları herhangi bir e-posta mesajına yanıt verme eğiliminde olacaktır. Yalnızca yanıtların düzgün şekilde işlenebileceği iletileri aldıklarından emin olun.
Müşteri bileti "yanlış" durumuna değiştirdi
Bu çoğunlukla istemcinin uygulamada tam bir kullanıcıya sahip olduğu durumlarda (Yardım masası kullanıcısı yerine) meydana gelir. Müşteri, durum dahil birçok alanı düzenleme seçeneğine sahip olabilir ve çeşitli durumların anlamını yanlış yorumlayabilir. Veya diğer taraftan değişmesini beklediğiniz halde durum değişmeyebilir.
Nedeni: İstemci doğru durumu ayarlamaktan sorumlu kılınmıştır.
Çözüm: Bu açık bir anti-kalıptır; istemcinin görev durumları için herhangi bir kuralı hatırlaması gerekmemelidir.
Çözümlerden biri, müşteri hesabını tam kullanıcılar yerine Yardım masası kullanıcılarına geçirmektir. Yardım masası kullanıcıları destek bildirimleri oluşturabilir ve mevcut destek bildirimlerine yorum girebilir, durum değişiklikleri Yardım masası yapılandırmalarına dayalıdır, dolayısıyla istemcinin bazı doğru süreçleri "bozma" şansı yoktur. Yardım masası kullanıcılarının bildirim güncellemeleri, pratik olarak yardım masası e-posta iletişim mantığını ve ayarlarını takip edecek şekilde tasarlanmıştır. Tek fark, kullanıcının aslında biletin fiziksel formunu görebilmesi ve üzerinde çalışabilmesidir.
Müşterileriniz için tam kullanıcıları tutmanız gerekiyorsa önerimiz, bazı dahili süreçlerinizi bozabilecek tüm durum değişikliklerini (veya diğer alan değişikliklerini) tamamen devre dışı bırakmanızdır. Güncellenmesi gereken biletleri takip etmek için başka yöntemler kullanın (örneğin, alana göre) Görev son güncellendi (son güncelleme tarihi), Son güncelleyen (son güncellemeyi kim yaptı), listedeki bir destek talebine ilişkin son yorumu gösterebilirsiniz, böylece güncellemeyi müşterinin yaptığı açıkça anlaşılır.
Biraz daha karmaşık bir senaryo, Örnek 1'deki gibidir; e-posta yoluyla bilet iletişimine izin verdiğinizde, ancak aynı zamanda istemcilerin tam kullanıcı olarak oturum açmasına da izin verirsiniz. İşte dikkat etmeniz gerekenler:
- İstemcinin e-postayla yanıt vermesinden sonraki durum değişikliği genel yardım masası ayarlarında belirlenir
- Oturum açmış kullanıcılar için durum değişikliği uygulaması yoktur; her zaman durumu olduğu gibi tut seçeneği vardır
Bu durumda, yanıt kuyruklarınızın hem e-postayla güncellenen durum türlerini (örneğin belirli bir durum için filtre) hem de istemciler tarafından uygulama içinden güncellenen biletleri (örneğin sütunlu bilet listesi) içerdiğinden emin olmalısınız. Son yorum).
Temel çıkarım: Müşteri asla dahili süreçleriniz hakkında endişelenmemelidir, sadece sorunlarını iletebilecekleri ve sizinle iletişim kurabilecekleri bir yere ihtiyaçları vardır, süreçler size aittir ve uygulamanın bunu sıkı bir şekilde ayarlamak için çeşitli seçenekleri vardır.
Tam kullanıcıları ve yardım masası kullanıcılarını karıştırma
Bu, hiçbir zaman birleştirilmesi amaçlanmayan çözümleri birleştirmemeniz konusunda güçlü bir uyarıdır. Kullanılıp kullanılmayacağına karar verebilirsiniz
- Yardım masası kullanıcıları - ücretsiz, sabit kodlu sınırlı erişimle veya
- Tam kullanıcılar - neye erişebileceklerine sizin karar verdiğiniz normal lisanslı kullanıcılar
ancak ikisini aynı anda, özellikle de aynı istemciler için kullanmamalısınız. Teknik olarak, tam kullanıcı ve Yardım masası kullanıcıları hiçbir şekilde bağlantılı değildir. Hatta farklı bir giriş sayfaları bile var. Görevlerde farklı bir alanı temsil ederler (yazar ve yardım masası yazarı). Dolayısıyla müşterinize her iki erişim seçeneğini de sunarak kafasını karıştırmanıza gerek yok.
Dahili süreçlerinize gelince, bazı müşterilere tam kullanıcı, bazılarına ise sadece yardım masası kullanıcıları sağlamak teknik olarak mümkündür. Ancak bu, temsilcilerinizin bu çok farklı kanallardan gelen biletlerin işlenmesini karıştırmayacaklarından emin olmak için kesin süreç tanımları ve eğitimler gerektirir. Organizasyonel zorluk nedeniyle, müşteri erişimi için yalnızca bir seçeneği seçmenizi önemle tavsiye ederiz.
Özet
Önceki bilgileri sindirilebilir bir forma dönüştürelim. Aşağıda istemcilerinizin sisteminize erişim türüne göre oluşabilecek durumların bir tablosu verilmiştir.
| Uygulamaya istemci erişimi | Bilet gönderme seçenekleri (istemci) |
Biletten (acente) gelen bildirimler |
Bileti güncelleme seçenekleri (istemci) |
Önerilerimiz |
| Erişim olmadan | Yardım masası e-posta adresine e-posta gönderin. | Temsilci, biletteki şablon aracılığıyla e-posta gönderir. |
|
|
| Tam kullanıcı |
|
|
|
|
| Yardım masası kullanıcısı |
|
Temsilci, biletteki şablon aracılığıyla e-posta gönderir. |
|
|
