Software helpdesku: Vytvořte spolehlivý pracovní postup tiketů
Software pro help desk je nejpřínosnější, když podporuje jasný způsob práce. Zakoupení nástroje nerozhodne, kdo je zodpovědný za požadavek, kdy má ticket čekat ani co se považuje za vyřešené. Tato rozhodnutí musí váš tým učinit nejprve.
Tato příručka vám ukáže, jak navrhnout praktický workflow ticketů kolem vaší stávající e-mailové podpory. Zaměřuje se na provozní model, nikoli na porovnání funkcí. Pokud chcete vidět, jak do jednoho produktu zapadají e-mail, přiřazení, stav, priorita, štítky, poznámky a historie ticketu, projděte si při práci jednotlivými kroky funkce sdílené schránky a ticketingu v Deskhero.
Začněte cestou, kterou by měl požadavek zákazníka projít
Než cokoli nastavíte, zakreslete běžnou cestu od přijetí po vyřešení. Užitečná první verze je jednoduchá: zpráva dorazí, někdo ji zkontroluje, správná osoba převezme odpovědnost, tým požadavek zpracuje a zákazník obdrží závěrečnou odpověď.
Poté sepište výjimky, které tuto cestu pravidelně narušují. Fakturační dotaz může vyžadovat zapojení jiného týmu. Technický problém může vyžadovat prověření. Zákazník může přestat odpovídat. Dvě zprávy mohou popisovat stejný problém. Tyto případy vám ukážou, které stavy, předání a ochranné mechanismy váš workflow potřebuje.
Držte mapu zaměřenou na rozhodnutí. U každé fáze odpovězte na tyto otázky:
- Kdo odpovídá za další akci?
- Jaké informace musí být k dispozici, než se ticket posune dál?
- Co se má stát, když vlastník není k dispozici?
- Jak může jiný User pochopit aktuální stav, aniž by si musel vyžádat shrnutí?
- Jaká událost znamená, že je požadavek skutečně dokončen?
Workflow je zdravý, když jakýkoli User může otevřít ticket a zjistit, co se stalo, co se stane dál a kdo odpovídá za další krok.
Používejte malou sadu stavů s přesnými významy
Názvy stavů často vypadají jednoznačně, ale týmy si je vykládají odlišně. Každý stav definujte podle toho, kdo má provést další akci. Toto jediné pravidlo zabrání mnoha uvízlým ticketům.
| Účel stavu | Použijte jej, když | Kdo jedná jako další |
|---|---|---|
| Nová práce | Požadavek dorazil, ale ještě nebyl zkontrolován | Tým zajišťující příjem požadavků |
| Aktivní práce | User požadavek prověřuje nebo připravuje odpověď | Přiřazený User |
| Čeká se | Tým potřebuje informace nebo akci od zákazníka či jiné strany | Uvedená externí strana, přičemž uvnitř týmu je určen vlastník pro následné kroky |
| Vyřešeno | Tým dokončil požadovanou práci a odeslal výsledek | Nikdo, pokud zákazník neodpoví |
Vyhněte se vytváření stavu pro každé oddělení, téma nebo úroveň naléhavosti. Pro vlastnictví používejte přiřazení nebo skupiny, pro témata štítky a pro naléhavost prioritu. Když má každé pole jediný účel, mohou Users frontu konzistentně číst.
Oddělte vlastnictví, prioritu a klasifikaci
Tyto tři pojmy odpovídají na různé otázky. Vlastnictví určuje, kdo má jednat. Priorita říká, jak rychle je třeba se požadavku věnovat. Klasifikace určuje, o jaký typ požadavku jde. Jejich směšování vytváří vágní fronty a nespolehlivé reporty.
Určete jednoho Usera nebo skupinu, která ponese odpovědnost
Každý otevřený ticket by měl mít jasného vlastníka. Sdílená odpovědnost se snadno promění v odpovědnost nikoho. Skupina může přijímat nové úkoly, ale jakmile práce začne, měl by ji převzít konkrétní User. Definujte pravidlo zastupování pro případ nepřítomnosti a pravidlo předání, když se změní potřebná odbornost.
Definujte prioritu pomocí pozorovatelných podmínek
Pravidla priority napište srozumitelným jazykem. Například výpadek ovlivňující mnoho zákazníků by měl mít vyšší prioritu než obecný dotaz. Nedovolte, aby se priorita stala způsobem, jak označit každý netrpělivý požadavek jako urgentní. Krátká písemná definice poskytne Userům důvod, který mohou uplatňovat konzistentně.
Štítky používejte pro budoucí akce, ne jako ozdobu
Štítek vytvořte pouze tehdy, když týmu pomůže směrovat práci, najít užitečný segment nebo odpovědět na opakující se otázku. Štítky pravidelně kontrolujte a slučujte téměř duplicitní štítky. Menší slovník vytváří přehlednější zobrazení a důvěryhodnější analýzy.
Navrhujte předání tak, aby zachovalo kontext
Předání by mělo převést odpovědnost, aniž by další User musel případ znovu rekonstruovat. Odpovědi zákazníka i interní poznámky uchovávejte na časové ose ticketu. Před přeřazením přidejte aktuální zjištění, otázku, která zůstává otevřená, a další očekávanou akci.
Interní poznámky používejte pro spolupráci, která nemá být odeslána zákazníkovi. Odpověď zákazníkovi použijte, když potřebujete potvrdit přijetí, vyžádat si informace nebo vysvětlit zpoždění. Toto rozlišení udržuje konverzaci přehlednou a poskytuje kolegům potřebný kontext.
Když se dva tickety týkají stejného problému, rozhodněte, který záznam je zdrojem pravdy. Duplicitní ticket sloučte s hlavním ticketem a poté pokračujte na jednom místě. Paralelní záznamy vedou ke konfliktním odpovědím a rozdělují historii.
Přidejte servisní cíle, až bude workflow stabilní
Cíle nemohou napravit nejasné vlastnictví. Nejprve se ujistěte, že nová práce je kontrolována, přiřazení jsou viditelná a tickety ve stavu čekání mají naplánovaný další krok. Poté definujte očekávání pro odpověď a vyřešení s ohledem na hodiny, kdy váš tým skutečně pracuje.
Sledujte tickety, které se blíží ke splnění cíle, nejen ty, u nichž již došlo k jeho překročení. Cílem je podnítit akci v době, kdy je stále ještě čas. Zásady SLA v Deskhero podporují cíle pro první odpověď a vyřešení, rozvrhy pracovní doby, filtry, upozornění a zobrazení v podobě dashboardu.
Otestujte workflow pomocí skutečných scénářů
Než proces zavedete, projděte si reprezentativní požadavky. Zahrňte jednoduchý dotaz, požadavek, u něhož se mění vlastník, případ čekající na zákazníka, duplicitu a znovu otevřenou konverzaci. U každého scénáře ověřte, zda zůstávají další akce a vlastník zřejmé.
Test proveďte s Usery, kteří workflow nenavrhovali. Pokud potřebují slovní instrukce, pravidla nebo názvy polí ještě nejsou dostatečně jasné. Proces upravte a scénáře zopakujte.
Během zavádění veďte krátký protokol výjimek. Zaznamenávejte situace, kdy Users nevědí, který stav, vlastníka nebo prioritu zvolit. Protokol pravidelně kontrolujte a workflow měňte pouze tehdy, když se objeví opakující se vzorec. Zabráníte tak hromadění jednorázových pravidel v systému.
Měřte tok práce, ne aktivitu pro aktivitu samotnou
Užitečné reporty by měly ukázat, kde zákazníci čekají a kde se práce zadrhává. Začněte objemem ticketů, dobou do první odpovědi, dobou do vyřešení, stářím nevyřízených ticketů a znovu otevřenými požadavky. Sledujte trendy a segmenty, místo abyste jeden průměr považovali za celý příběh.
Každou metriku spojte s rozhodnutím. Narůstající počet starých nevyřízených ticketů může vyžadovat jasnější vlastnictví nebo větší kapacitu. Pomalé první odpovědi mohou poukazovat na nedostatečné pokrytí příjmu požadavků. Časté znovuotevírání může signalizovat neúplná vyřešení nebo matoucí odpovědi. Podrobnější plán měření najdete v naší příručce o metrikách reportingu help desku.
Workflow zkontrolujte, když důkazy ukazují na opakující se úzké hrdlo. Nepřidávejte pole ani kroky jen proto, že je software umožňuje. Nejlepší nastavení help desku je to nejmenší, které spolehlivě zviditelní vlastnictví, kontext a další akce.
Praktický kontrolní seznam pro zavedení
- Namapujte běžnou cestu požadavku a obvyklé výjimky.
- Definujte každý stav podle toho, kdo má provést další akci.
- Oddělte vlastnictví, naléhavost a klasifikaci tématu.
- Zdokumentujte, co musí úplné předání obsahovat.
- Otestujte workflow pomocí realistických scénářů podpory.
- Servisní cíle přidejte, až budou směrování a vlastnictví spolehlivé.
- Vyberte malou sadu metrik propojených s provozními rozhodnutími.
- Kontrolujte výjimky a zjednodušujte pravidla, která Users uplatňují nekonzistentně.
Jakmile jsou tato rozhodnutí zapsána, konfigurace je mnohem snazší. Váš nástroj by měl zviditelnit a opakovatelně podporovat dohodnutý proces a zároveň ponechat dostatek flexibility pro neobvyklé případy.