Životní cyklus ticketu a komunikace s klienty v rámci Helpdesku
Úvod
Tento článek popisuje, jak probíhá zadávání a zpracování tiketů v systému HelpDesk podle toho, jak tiket vznikl a jaký přístup do systému má klient. Najdete zde tipy, na co si dát pozor při různých konfiguracích zpracování tiketu.
Článek obsahuje tipy a doporučení pro různé konfigurace, ne přesný postup jejich nastavení. Ten najdete v těchto článcích:
- Dokumentace HelpDesku
- Uživatelská příručka (workflow, nastavení upozornění)
Tři hlavní komunikační kanály
Začněme schématem životního cyklu tiketu v jednoduchých situacích, kdy tiket postupuje jen jedním kanálem od začátku do konce:
- Plnohodnotný uživatel v aplikaci
- Uživatel HelpDesku
Vytvoření tiketu a další komunikace v tiketu
Vytvoření tiketu a další komunikace v něm mohou výše uvedené kanály kombinovat.
Tiket lze vytvořit e-mailem a v komunikaci pokračovat v aplikaci (jako plnohodnotný uživatel nebo uživatel HelpDesku). Stejně tak lze tiket vytvořit v aplikaci a dál komunikovat už jen e-mailem.
Příklad 1
- Klient vytvoří tiket e-mailem – pošle nový e-mail na adresu HelpDesku.
- Klient se přihlásí do aplikace a tiket vidí, protože je jeho autorem.
- Klient může podle svých oprávnění měnit stav a další pole a přidávat komentáře.
Příklad 2
- Klient se přihlásí do aplikace a vytvoří nový tiket.
- Klient dostává aktualizace e-mailem, jen je sleduje a do aplikace se už nepřihlašuje.
Příklad 3
- Klient vytvoří tiket na portálu HelpDesku.
- Klient se rozhodne sledovat tiket jen e-mailem a na portál se už nepřihlašuje.
- Později se klient rozhodne sledovat tiket na portálu, přihlásí se a odpoví přes portál.
Pro pohodlí klientů se můžete rozhodnout, jakými způsoby jim umožníte tikety vytvářet a aktualizovat. Nejdůležitější je pokrýt všechny možné situace, aby žádný tiket neskončil ve slepé uličce. Workflow a další nastavení k tomu nabízejí všechny potřebné možnosti.
Obvyklé problémy
Klient odpoví na upozornění z úkolu, ale odpověď se nezpracuje správně
Tato situace se týká příkladu 2. Klient si myslí, že odpovídá na tiket e-mailem, ale e-mail se nespáruje s existujícím tiketem. Místo toho vznikne nový tiket, nebo e-mail do systému vůbec nedorazí. Klient odpoví na systémové upozornění, nebo omylem napíše nový e-mail.
Příčina: Systémová e-mailová upozornění nepočítají s tím, že na ně někdo odpoví. Odpověď proto nemusí dorazit do HelpDesku.
Řešení: Odpověď klienta musí přijít na adresu HelpDesku a musí obsahovat číslo tiketu. Adresu, ze které se upozornění odesílají (Administrace » Nastavení » E-mailová oznámení » E-mailová adresa oznámení (OD)), můžete nastavit stejně jako adresu HelpDesku. Odpovědi klientů se pak zachytí a spárují s tiketem, ze kterého upozornění přišlo.
Další možností je klientským uživatelům běžná e-mailová upozornění úplně vypnout. Klienti pak dostávají jen e-maily, které jim aktivně pošlou pracovníci HelpDesku přes e-mailové šablony HelpDesku.
Klíčový poznatek: Klienti mají přirozeně tendenci odpovídat na každý e-mail, který dostanou. Zajistěte, aby dostávali jen zprávy, jejichž odpovědi umí systém zpracovat.
Klient změnil tiket na „nesprávný“ stav
To se stává hlavně tehdy, když má klient v aplikaci plnohodnotného uživatele (místo uživatele HelpDesku). Klient může upravovat řadu polí včetně stavu a může si význam jednotlivých stavů vyložit jinak. Nebo naopak stav nezmění, i když se to od něj očekává.
Příčina: Odpovědnost za nastavení správného stavu nese klient.
Řešení: Klient by si neměl muset pamatovat žádná pravidla pro stavy úkolů.
Jedním z řešení je změnit klientský účet z plnohodnotného uživatele na uživatele HelpDesku. Uživatelé HelpDesku mohou vytvářet tikety a přidávat komentáře do existujících tiketů. Změny stavů se řídí nastavením HelpDesku, takže klient nemůže „porušit“ váš proces. Aktualizace od uživatelů HelpDesku se řídí stejnou logikou a nastavením jako e-mailová komunikace HelpDesku. Jediný rozdíl je, že uživatel tiket skutečně vidí a může s ním pracovat.
Pokud potřebujete klientům ponechat plnohodnotné uživatele, doporučujeme úplně zakázat změny stavu (a dalších polí), které by mohly narušit vaše interní procesy. Tikety, které čekají na vaši reakci, sledujte jinak – například filtrem podle polí Úkol naposledy aktualizován (datum poslední aktualizace) a Naposledy aktualizoval (kdo aktualizaci provedl). V seznamu si můžete zobrazit i sloupec s posledním komentářem, aby bylo vidět, že aktualizaci provedl klient.
Složitější je scénář z příkladu 1, kdy povolíte komunikaci e-mailem a zároveň umožníte klientům přihlásit se jako plnohodnotní uživatelé. Na co si dát pozor:
- Změna stavu po odpovědi klienta e-mailem se nastavuje v globálním nastavení HelpDesku.
- Přihlášeným uživatelům se změna stavu nevynucuje – vždy mohou stav ponechat beze změny.
V tomto případě zajistěte, aby vaše fronty tiketů čekajících na odpověď zachytily oba typy situací: tikety aktualizované
