Životní cyklus ticketu a komunikace s klienty v rámci Helpdesku
Úvod
V tomto článku se budeme zabývat procesem zadávání tiketů v závislosti na způsobu vytvoření tiketu v systému Help desk a na přístupu klienta do systému. Najdete zde tipy, na co si dát pozor při různých konfiguracích zprocesování tiketu.
Tento článek obsahuje tipy a návrhy pro různé konfigurace, ale ne přímo způsob jejich provedení. Zde jsou uvedeny příslušné články:
- Help Desk dokumentace
- 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 přímočarých situacích - kdy ticket postupuje pouze jedním směrem od začátku do konce.
- Plnohodnotný uživatel v rámci aplikace
- Uživatel HelpDesku
Vytvoření ticketu a další komunikace v rámci ticketu
Vytváření a další komunikace v rámci tiketu může kombinovat výše uvedené přístupy.
Je možné vytvořit tiket prostřednictvím e-mailu a následně pokračovat v komunikaci v aplikaci (ať už plnohodnotným uživatelem, nebo uživatelem HelpDesku). Je také možné vytvořit tiket prostřednictvím systému a poté následovat komunikací pouze e-maily.
Příkad 1
- Tickety jsou vytvořeny prostřednictvím e-mailu - klient odešle nový e-mail na adresu helpdesku.
- Klient se přihlásí do systému a ticket tam vidí, protože je jeho autorem.
- Klienti mohou měnit stavy a další pole a také zanechávat komentáře dle svých oprávnění.
Příklad 2
- Klient se přihlásí do systému a vytvoří nový ticket.
- Klient dostává aktualizace e-mailem a tyto aktualizace pouze sleduje a necítí potřebu se do systému dále přihlašovat.
Příklad 3
- Klient vytvoří ticket prostřednictvím portálu helpdesku.
- Klient se rozhodne, že chce sledovat pouze e-maily, a do portálu se již nepřihlašuje.
- Klient se poté rozhodne, že chce sledovat ticket prostřednictvím portálu, přihlásí se, a zadá některé odpovědi prostřednictvím portálu.
Pro pohodlí klientů se můžete rozhodnout, jakými metodami jim umožníte vytvářet a/nebo aktualizovat tikety. Nejdůležitější však je, abyste pokryli všechny možné situace, aby se tikety neztratily ve slepé uličce. Workflow a další konfigurace poskytují všechny potřebné možnosti
Obvyklé problémy
Klient odpoví na upozornění z úkolu, ale odpověď není správně zpracována.
Tento příběh se týká příkladu 2. Klienti si myslí, že odpovídají na tiket e-mailem, ale e-mail není spárován s existujícím ticketem a místo toho je vytvořen nový, nebo e-mail do systému vůbec nedorazí. Klient odpoví na oznámení nebo omylem vytvoří nový e-mail.
Příčina: V případě, že je e-mailová zpráva odeslána na e-mailovou adresu, je možné, že se jedná o upozornění z úkolu: Nastavení e-mailových oznámení neočekává odpovědi na adresu oznámení.
Řešení: Odpověď klienta musí být zaslána na adresu určenou helpdeskem a musí obsahovat číslo ticketu. E-mailová adresa oznámení (Administrace >> Nastavení >> E-mailová oznámení >> E-mailová adresa oznámení (OD)) může být stejná jako e-mailová adresa helpdesku, aby se zachytily případné odpovědi klientů a spárovaly se s ticketem, ze kterého bylo oznámení původně odesláno.
Další možností je jednoduše zakázat pravidelné zasílání e-mailových oznámení klientským uživatelům. Jediné e-maily z ticketů, které by dostávali, by aktivně odesílali pracovníci HelpDesku prostřednictvím e-mailových šablon HelpDesku.
Klíčový poznatek: Vaši klienti budou mít přirozeně tendenci odpovídat na všechny e-mailové zprávy, které obdrží. Zajistěte, aby dostávali pouze zprávy, které je možné řádně zpracovat.
Klient změnil tiket na "nesprávný" stav
K tomu dochází většinou v situacích, kdy má klient v aplikaci plnohodnotného uživatele (místo uživatele Helpdesku). Klient může mít možnost upravovat mnoho polí včetně stavu a může si nesprávně vyložit význam různých stavů. Nebo naopak nemusí změnit stav, i když se očekává, že bude změněn.
Příčina: Zodpovědnost za nastavení správného stavu necháme na klientovi.
Řešení: Klient by neměl být nucen si pamatovat žádná pravidla pro stavy úkolů.
Jedním z řešení je přepnout klientský účet na uživatele Helpdesku místo plnohodnotného uživatele. Uživatelé helpdesku mohou vytvářet tickety a zadávat komentáře do existujících ticketů. Změny stavů vycházejí z konfigurace HelpDesku, takže není možné, že by klient "porušil" nějaký správný proces. Aktualizace ticketů uživatelů helpdesku jsou prakticky navrženy tak, aby se řídily logikou a nastavením e-mailové komunikace HelpDesku. Jediný rozdíl je v tom, že uživatel skutečně vidí fyzickou podobu tiketu a může s ní pracovat.
Pokud potřebujete zachovat plnohodnotné uživatele pro své klienty, doporučujeme zcela zakázat jakékoli změny stavu (nebo jiné změny polí), které mohou narušit některé vaše interní procesy. Pro sledování ticketů, které je třeba aktualizovat, použijte jiné způsoby – například můžete filtrovat podle následujících polí: Úkol naposledy aktualizován (datum poslední aktualizace), Naposledy aktualizoval (kdo provedl poslední aktualizaci). V seznamu můžete zobrazit sloupec s posledním komentářem k ticketu, aby bylo zřejmé, že aktualizaci provedl klient.
Poněkud složitější je scénář z příkladu 1, kdy povolíte komunikaci prostřednictvím e-mailu, ale zároveň umožníte klientům přihlašovat se prostřednictvím plnohodnotného uživatele. Zde je uvedeno, na co si dát pozor:
- Změna stavu po odpovědi klienta e-mailem je nastavena v globálním nastavení HelpDesku.
- Pro přihlášené uživatele není změna stavu vynucována – vždy je k dispozici možnost ponechat stav takový, jaký je.
V tomto případě byste se měli ujistit, že vaše fronty pro odpověď obsahují oba typy situací, tedy tickety aktualizované e-mailem (např. filtr pro konkrétní stav) a tickety aktualizované klienty z aplikace (např. seznam tiketů se sloupcem Poslední komentář).
Klíčový poznatek: Klient by se neměl starat o vaše interní procesy, potřebuje jen místo, kde může zadat své potíže a komunikovat s vámi. Procesy jsou na vás a aplikace má různé možnosti, jak je pevně nastavit.
Kombinace plnohodnotných uživatelů a uživatelů HelpDesku
Toto je jen důrazné varování, abyste nekombinovali řešení, která nikdy nebyla určena ke kombinaci. Můžete se rozhodnout, zda použijete:
- Uživatele HelpDesku – zdarma, s pevně nastaveným omezeným přístupem, nebo
- Plnohodnotné uživatele – běžné licencované uživatele, u nichž sami rozhodujete, k čemu budou mít přístup.
, ale neměli byste používat obojí současně, zejména pro stejné klienty. Technicky spolu plnohodnotní uživatelé a uživatelé HelpDesku nijak nesouvisí. Mají dokonce odlišnou přihlašovací stránku. V úlohách představují jiné pole (autor vs. autor HelpDesku). Není tedy důvod mást klienta tím, že mu poskytnete obě možnosti přístupu
Co se týče vašich interních procesů, je technicky možné poskytnout některým klientům plnohodnotné uživatele a jiným pouze uživatele HelpDesku. To však vyžaduje přesný popis procesů a školení pro vaše pracovníky, abyste zajistili, že nebudou zaměňovat zpracování ticketů z těchto velmi odlišných kanálů. Vzhledem k organizační náročnosti důrazně doporučujeme zvolit pouze jednu možnost přístupu klientů.
Shrnutí
Převeďme si předchozí informace do stravitelné podoby. Zde je tabulka situací, které mohou nastat podle typu přístupu klientů do vašeho systému.
| Přístup klienta do aplikace | Možnosti odeslání ticketu (klient) |
Oznámení z ticketu (pracovník) |
Možnosti aktualizace ticketu (klient) |
Naše doporučení |
| Bez přístupu | Odeslání e-mailu na e-mailovou adresu HelpDesku. | Pracovník odešle e-mail prostřednictvím šablony z ticketu. |
|
|
| Plnohodnotný uživatel |
|
|
|
|
| Uživatel HelpDesku |
|
Pracovník odešle e-mailem odpověď prostřednictvím šablony z ticketu |
|
|
