Životní cyklus vstupenky a komunikace s klienty v Helpdesku
Úvod
V tomto článku projdeme procesem ticketingu v závislosti na způsobu vytvoření ticketu v Help desku a podle přístupu klienta do vašeho systému. Najdete tipy, na co si dát pozor v různých konfiguracích procesu tiketů.
Tento článek obsahuje tipy a návrhy pro různé konfigurace, ale ne přímo, jak jsou konfigurace vytvořeny. Zde jsou příslušné články:
- Dokumentace Help Desku
- Uživatelský manuál (pracovní postup, nastavení oznámení)
Tři hlavní komunikační trasy
Počínaje schématem životního cyklu vstupenky v přímých situacích – kdy vstupenka sleduje od začátku do konce pouze jeden typ toku.
- Plný uživatel v aplikaci
- Uživatel help desk v aplikaci
Vytvoření a další komunikace v rámci tiketu
Vytvoření tiketu a další komunikace může kombinovat výše uvedené přístupy.
Je možné vytvořit tiket prostřednictvím e-mailu a následně sledovat v aplikaci (ať už plným uživatelem, nebo uživatelem helpdesku). Přes systém je také možné vytvořit tiket a pak už jen sledovat emaily.
Příklad 1
- Vstupenky jsou vytvářeny prostřednictvím emailu – klient zašle nový email na adresu helpdesku.
- Klient se přihlásí do systému a tam tiket vidí, protože je jeho autorem.
- Klienti mohou měnit stavy a další pole, stejně jako zanechávat komentáře, podle svých oprávnění.
Příklad 2
- Klient se přihlásí do systému a vytvoří nový tiket.
- Klient dostává aktualizace e-mailem a tyto aktualizace pouze sleduje a již necítí potřebu se do systému přihlašovat.
Příklad 3
- Klient vytvoří tiket přes portál helpdesk
- Klient se rozhodne, že chce sledovat pouze e-maily a již se do portálu nepřihlašuje
- Klient se pak rozhodne, že chce sledovat přes portál, zaloguje se a zadá nějaké odpovědi přes portál.
Pro pohodlí vašich klientů se můžete rozhodnout, jakými metodami jim umožníte vytvářet a/nebo aktualizovat vstupenky. Ale hlavně je potřeba obsáhnout každou možnou situaci, aby se vstupenky neztratily do slepé uličky. Workflow a další konfigurace poskytují všechny potřebné možnosti.
Běžné problémy
Klient odpovídá na běžné oznámení o úkolu, ale odpověď není zpracována správně.
Tento příběh se týká příkladu 2. Klienti si myslí, že odpovídají na tiket prostřednictvím e-mailu, ale e-mail není spárován se stávajícím tiketem a místo toho je vytvořen nový, nebo se e-mail do systému vůbec nedostane. Klient odpoví na oznámení nebo omylem vytvoří nový e-mail.
Příčina: Nastavení upozornění e-mailem neočekává odpovědi na adresu upozornění.
Řešení: Odpověď klienta musí být zaslána na zadanou adresu helpdesku a musí obsahovat číslo tiketu. E-mailová adresa pro upozornění (Administrace >> Nastavení >> E-mailová upozornění >> E-mailová adresa pro upozornění (FROM)) může být stejná jako e-mailová adresa helpdesku pro zachycení všech odpovědí od klientů a jejich spárování s tiketem, ze kterého bylo upozornění původně odesláno.
Další možností je jednoduše zakázat pravidelná e-mailová upozornění pro klientské uživatele. Jediné e-maily ze vstupenek, které by dostali, by operátoři aktivně posílali prostřednictvím e-mailových šablon helpdesku.
Klíčové kroky: Vaši klienti budou přirozeně v pokušení odpovědět na jakékoli e-mailové zprávy, které obdrží. Ujistěte se, že dostávají pouze zprávy, na které lze správně zpracovat odpovědi.
Klient změnil lístek na "nesprávný" stav
K tomu dochází většinou v situacích, kdy má klient v aplikaci plného uživatele (místo uživatele Help desku). Klient může mít možnost upravit mnoho polí, včetně stavu, a může si nesprávně vyložit význam různých stavů. Nebo na druhou stranu nemusí změnit stav, když očekáváte, že se změní.
Příčina: Klient je odpovědný za nastavení správného stavu.
Řešení: Toto je jasný anti-vzor, klient by si neměl pamatovat žádná pravidla pro stavy úkolů.
Jedním z řešení je přepnout klientský účet na uživatele Helpdesku namísto plnohodnotných uživatelů. Uživatelé helpdesku mohou vytvářet vstupenky a vkládat komentáře k existujícím ticketům, změny stavu jsou založeny na konfiguracích Help desku, takže není šance, že klient nějaký správný proces „rozbije“. Aktualizace lístků uživatelů helpdesku jsou prakticky navrženy tak, aby odpovídaly logice a nastavení e-mailové komunikace helpdesku. Jediný rozdíl je v tom, že uživatel může skutečně vidět a pracovat s fyzickou podobou tiketu.
Pokud potřebujete zachovat plné uživatele pro své klienty, navrhujeme zcela zakázat jakékoli změny stavu (nebo změny jiných polí), které mohou narušit některé vaše interní procesy. Využijte jiné způsoby sledování tiketů, které je třeba aktualizovat – například podle oboru Úkol naposledy aktualizován (datum poslední aktualizace), Naposledy aktualizováno uživatelem (kdo provedl poslední aktualizaci), můžete zobrazit poslední komentář k tiketu v seznamu, aby bylo jasné, že klient provedl aktualizaci.
Poněkud složitější scénář je z příkladu 1, kdy povolíte komunikaci lístků prostřednictvím e-mailu, ale zároveň umožníte klientům přihlášení pomocí plného uživatele. Zde je na co si dát pozor:
- Změna stavu po odpovědi klienta e-mailem je nastavena v globálním nastavení helpdesku
- U přihlášených uživatelů není vynucena změna stavu - vždy je zde možnost zachovat stav tak, jak je
V tomto případě byste se měli ujistit, že vaše fronty na odpověď obsahují oba typy situací, aktualizované e-mailem (např. filtr na konkrétní stav), a tipy aktualizované klienty z aplikace (např. seznam tiketů se sloupcem Poslední komentář).
Klíčová cesta: Klient by se nikdy neměl starat o vaše interní procesy, jen potřebuje místo, kde může podávat své problémy a komunikovat s vámi, procesy jsou na vás a aplikace má různé možnosti, jak to nastavit.
Míchání plných uživatelů a uživatelů help desk
Toto je pouze důrazné varování, abyste nekombinovali řešení, která nikdy nebyla kombinována. Můžete se rozhodnout, zda použít
- Uživatelé help desk - zdarma, s pevně zakódovaným omezeným přístupem, popř
- Plní uživatelé – běžní licencovaní uživatelé, u kterých rozhodujete o tom, k čemu mají přístup
, ale neměli byste používat oba současně, zejména pro stejné klienty. Technicky nejsou plnohodnotní uživatelé a uživatelé helpdesku nijak propojeni. Mají dokonce jinou přihlašovací stránku. Představují jiné pole úkolů (autor vs. autor help desk). Není tedy důvod zmást klienta tím, že mu poskytnete obě možnosti přístupu.
Pokud jde o vaše interní procesy, je technicky možné poskytnout některým klientům plné uživatele a jiným pouze uživatele helpdesku. To však vyžaduje přesné popisy procesů a školení pro vaše agenty, aby bylo zajištěno, že nebudou zaměňovat zpracování tiketů 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 klientského přístupu.
Shrnutí
Vraťme předchozí informace zpět do stravitelné podoby. Zde je tabulka situací, které mohou nastat v závislosti na typu přístupu vašich klientů k vašemu systému.
| Klientský přístup do aplikace | Možnosti odeslání tiketu (klient) |
Oznámení od tiketu (agent) |
Možnosti aktualizace tiketu (klient) |
Naše doporučení |
| Bez přístupu | Pošlete e-mail na e-mailovou adresu helpdesku. | Agent odešle e-mail přes šablonu z tiketu. |
|
|
| Plný uživatel |
|
|
|
|
| Uživatel help desk |
|
Agent odešle e-mail přes šablonu z tiketu. |
|
|
