Жизнен цикъл на билета и комуникация с клиенти в Helpdesk
Въведение
В тази статия ще разгледаме процеса на издаване на билети в зависимост от начина, по който се създава билет в бюрото за помощ и според достъпа на клиента във вашата система. Ще намерите съвети за какво да внимавате при различни конфигурации на обработка на билети.
Тази статия съдържа съвети и предложения за различни конфигурации, но не и директно как се правят конфигурациите. Ето съответните статии:
- Документация на Help Desk
- Ръководство на собственика (работен процес, настройки за уведомяване)
Три основни комуникационни маршрута
Започвайки със схема на жизнения цикъл на билета в ясни ситуации - когато билетът следва само един тип поток от началото до края.
- Имейл
- Пълен потребител в приложението
- Потребител на бюрото за помощ в приложението
Създаване и по-нататъшна комуникация в рамките на билет
Създаването на билети и по-нататъшната комуникация могат да комбинират горните подходи.
Възможно е да създадете билет чрез имейл и след това да проследите в приложението (независимо дали от пълен потребител или потребител на бюро за помощ). Възможно е също така да създадете билет чрез системата и след това да следвате само имейли.
Пример 1
- Тикетите се създават чрез имейл - клиентът изпраща нов имейл на адреса на бюрото за помощ.
- Клиентът влиза в системата и може да види тикета там, тъй като той е автор на тикета.
- Клиентите могат да променят статуси и други полета, както и да оставят коментари, според техните разрешения.
Пример 2
- Клиентът влиза в системата и създава нов билет.
- Клиентът получава актуализации по имейл и само наблюдава тези актуализации и вече не изпитва нужда да влиза в системата.
Пример 3
- Клиентът създава билет чрез портала на бюрото за помощ
- Клиентът решава, че иска да следва само имейли и повече да не влиза в портала
- След това клиентът решава, че иска да следва през портала, регистрира I и въвежда някои отговори през портала.
За удобство на Вашите клиенти можете да решите по какви методи искате да им позволите да създават и/или актуализират билети. Но най-важното е, че трябва да покриете всяка възможна ситуация, така че билетите да не се изгубят в задънена улица. Работният процес и другите конфигурации предоставят всички необходими опции.
Чести проблеми
Клиентът отговаря на редовно известие за задача, но отговорът не се обработва правилно.
Тази история се отнася до Пример 2. Клиентите смятат, че отговарят на билет чрез имейл, но имейлът не е сдвоен със съществуващия билет и вместо това се създава нов, или имейлът изобщо не достига до системата. Клиентът отговаря на известие или по погрешка създава нов имейл.
Причината: Настройките за известяване по имейл не очакват отговори на адреса за известяване.
Решение: Отговорът на клиента трябва да бъде изпратен на посочен адрес от бюрото за помощ и трябва да съдържа номера на билета. Имейл адрес за известия (Администрация >> Настройки >> Известия по имейл >> Имейл адрес за известия (FROM)) може да е същият като имейл адреса на бюрото за помощ, за да улавя всички отговори от клиенти и да ги сдвоява с билета, от който първоначално е изпратено известието.
Друг вариант е просто да деактивирате редовните известия по имейл до потребителите на клиента. Единствените имейли от билети, които биха получили, ще бъдат активно изпращани от операторите чрез имейл шаблони на бюрото за помощ.
Ключов изход: Вашите клиенти естествено ще бъдат изкушени да отговорят на всички имейл съобщения, които получат. Уверете се, че получават само съобщения, чиито отговори могат да бъдат обработени правилно.
Клиентът промени статуса на билета на "неправилен".
Това се случва най-вече в ситуации, когато клиентът има пълен потребител в приложението (вместо потребител на Help desk). Клиентът може да има опцията да редактира много полета, включително състояние, и може да тълкува погрешно значението на различни състояния. Или от друга страна може да не промени статуса, когато очаквате да бъде променен.
Причината: Клиентът носи отговорност за правилното задаване на статус.
Решение: Това е ясен анти-модел, клиентът не трябва да помни никакви правила за статуси на задачи.
Едно решение е да превключите клиентския акаунт към потребители на Help desk вместо пълни потребители. Потребителите на бюрото за помощ могат да създават билети и да въвеждат коментари в съществуващи билети, промените в статуса се основават на конфигурациите на бюрото за помощ, така че няма шанс клиентът да "счупи" някой правилен процес. Актуализациите на тикетите на потребителите на бюрото за помощ са практически проектирани да следват логиката и настройките за комуникация по имейл на бюрото за помощ. Единствената разлика е, че потребителят действително може да види и работи с физическа форма на билета.
Ако трябва да запазите пълните потребители за вашите клиенти, нашето предложение е напълно да деактивирате всички промени в състоянието (или промени в други полета), което може да наруши някои от вашите вътрешни процеси. Използвайте други начини за проследяване на билети, които трябва да бъдат актуализирани - например по поле Последна актуализация на задачата (дата на последна актуализация), Последна актуализация от (кой направи последната актуализация), можете да покажете последния коментар за билет в списъка, така че да е ясно, че клиентът е направил актуализацията.
Малко по-сложен сценарий е от Пример 1, когато разрешавате комуникация с билети чрез имейл, но също така позволявате на клиентите да влизат като пълен потребител. Ето за какво да внимавате:
- Промяната на състоянието след отговор на клиента по имейл е зададена в глобалните настройки на бюрото за помощ
- Няма принудителна промяна на състоянието за влезли потребители - винаги има опция за запазване на състоянието, както е
В този случай трябва да се уверите, че вашите опашки за отговор съдържат и двата вида ситуации, актуализирани по имейл (напр. филтър за конкретен статус), и билети, актуализирани от клиенти от приложението (напр. списък с билети с колона Последен коментар).
Ключов изход: Клиентът никога не трябва да се тревожи за вашите вътрешни процеси, те просто се нуждаят от място, където да представят своите проблеми и да комуникират с вас, процесите са за вас и приложението има различни опции, за да ги настрои здраво.
Смесване на пълни потребители и потребители на бюро за помощ
Това е само силно предупреждение да не комбинирате решения, които никога не са били предназначени за комбиниране. Вие можете да решите дали да използвате
- Потребители на Help desk - безплатно, с твърдо кодиран ограничен достъп, или
- Пълни потребители - редовни лицензирани потребители, където вие решавате до какво имат достъп
, но не трябва да използвате и двете едновременно, особено за едни и същи клиенти. Технически пълният потребител и потребителите на бюрото за помощ не са свързани по никакъв начин. Те дори имат различна страница за вход. Те представляват различно поле на задачите (автор срещу автор на бюрото за помощ). Така че няма причина да объркате клиента си, като му предоставите и двете опции за достъп.
Що се отнася до вашите вътрешни процеси, технически е възможно да предоставите на някои клиенти пълни потребители, а на други просто потребители на бюро за помощ. Това обаче изисква точни описания на процесите и обучения за вашите агенти, за да сте сигурни, че няма да смесват обработката на билети от тези много различни канали. Поради организационната му трудност, силно препоръчваме да изберете само една опция за клиентски достъп.
Oбобщение
Нека върнем предишната информация в смилаема форма. Ето таблица със ситуации, които могат да възникнат в зависимост от типа достъп на вашите клиенти до вашата система.
| Клиентски достъп до приложението | Опции за изпращане на билет (клиент) |
Известия от билет (агент) |
Опции за актуализиране на билет (клиент) |
Нашите препоръки |
| Без достъп | Изпратете имейл до имейл адрес на бюро за помощ. | Агентът изпраща имейл чрез шаблон от билета. |
|
|
| Пълен потребител |
|
|
|
|
| Потребител на бюро за помощ |
|
Агентът изпраща имейл чрез шаблон от билета. |
|
|
