HelpDesk

Terminologie
Rozvržení struktury podporových projektů
Napojení emailové schránky do Easy Projectu
Nastavení projektu
Konfigurace projektu - detaily
Zpracování ticketů
Emailové šablony
Obecné nastavení
Filtr "Vyžaduje reakci"
Uživatelé služby HelpDesk
Okrajové případy

Naše návody vás provedou jednotlivými kroky nastavení Helpdesku v uživatelském rozhraní. Od napojení emailových účtů do Easy Projectu, přes nastavení projektů až k doladění dashboardů. Nejedná se o technický manuál na konfiguraci crona (nebo plánovaných úloh na serveru). Cron už musí být nakonfigurován, aby modul Helpdesk mohl korektně fungovat. 

 

0 Terminologie

Jako první si pojďme ujasnit pojmy - nabízíme souhrn používaných pojmů v následujících návodech. 

Mailbox - emailová adresa napojená v Easy Projectu, ze které jsou přijímané emaily předávány jako tickety do příslušných projektů helpdesku
ticket - úkol, vytvořený z doručeného emailu, nebo úkol interně vytvořený zákazníkem v projektu helpdesku
Podporový projekt - projekt, napojený na Helpdesk modul, kde lze vytvářet tickety
Doména - součást emailové adresy za zavináčem. Například v adrese pracovnik.Jan@zakaznik.cz je doména zakaznik.cz
Klíčové slovo - slovo nebo slovní řetezec obsažený v předmětu emailové zprávy
SLA - úroveň poskytovaných služeb (z anglického Service Level Agreement). Zjednodušeně je v Easy Projectu termín používán ve smyslu dodržení stanovené garantované  doby reakce či odpovědi na zákaznické tickety. Uváděno v hodinách. 
Původní email - zpráva zaslaná na emailovou adresu helpdesku, ze které byl vytvořen ticket
Operátor - tímto pojmem označujeme pracovníky zákaznické podpory, kteří pracují s tickety

 

1 Rozvržení struktury podporových projektů

Než začnete s konfigurací, je potřeba si nejdříve navrhnout strukturu podporových projektů - a to podle toho, zda chcete vytvořit jen jeden projekt pro všechny tickety nebo rozlišovat více emailových schránek zákaznické podpory, či dokonce mít samostatné projekty pro konkrétní různé zákazníky.

Toto rozvržení ovlivní další následující kroky v následujících návodech. 

Máte tyto možnosti:

1.1 Jeden projekt pro všechny tickety

Pokud budete mít jen jeden projekt, do kterého budou předávány emailové zprávy ze schránky, není potřeba dalšího rozhodování -> z každého příchozího emailu bude vytvořen ticket v jednom stejném projektu.  

Příklad: všichni zákazníci zasílají své požadavky na zákaznickou podporu na adresu podpora@mojefirma.cz.

Nezáleží na úrovni tohoto projektu, v podstatě si žije svým vlastním životem ve všech ohledech a ve všech součástech jeho struktury. Pokud nicméně chcete začít teď s jedním projektem a později plánujete vaši podporu rozšířovat, pak se raději podívejte na další možnosti. 

 

1.2 Jedna schránka, více projektů zákaznické podpory

Příklad: Máte schránku podpora@mojefirma.cz. Všechny doručené emaily jdou do hlavního projektu. Ale máte jednoho zákazníka, který má speciální nároky a jeho řešení si vyžaduje vlastní projekt -> emaily Z DOMÉNY  @zakaznik.cz jsou předávány do tohoto speciálního projektu. 

Tímto způsobem si můžete samozřejmě oddělit více různých zákazníků. V takovém případě může struktura projektu vypadat takto:

Další možností je nastavit si Výchozí podporový projekt na první úrovni (nadřazený) a speciální projekty jako podprojekty.

Další možný způsob, jak můžete nastavit strukturu:

>Klient 1
>>Projekt pro obchod
>>Projekt pro implementaci
>>Projekt pro helpdesk

>Klient t2
>>Projekt pro obchod
>>Projekt pro implementaci
>>Projekt pro helpdesk

Nicméně tento způsob nedoporučujeme, pokud si chcete nechat sbírat a třídit tickety týkající se různých problémů například do různých seznamů, statistik nebo souhrnů. 
 

1.3 Více schránek, bez samostatných projektů pro různé zákazníky

Příklad: Máte schránky podpora@mojefirma.cz, info@mojefirma.cz, it@mojefirma.cz a emaily jsou tříděny na úrovni mailového serveru, ne podle odesílatele. 

V tomto případě můžete vytvořit tři projekty na stejné úrovni a případně je všechny zastřešit jedním projektem nad všemi. 

Tyto projekty nemusí být nijak vzájemně propojeny a mohou spadat do různých firemních oddělení, mohou být zařazeny každý do jiné stromové struktury projektů (patřit pod jiné projekty).

 

1.4 Více schránek, více samostatných projektů pro zákazníky

Současná funkcionalita Easy Project Helpdesku umožňuje třídit si klienty pouze podle adresy odesílatele, ale ne na základě kombinace adresy odesílatele a zároveň adresy příjemce.

Příklad: Máte adresy podpora@mojefirma.cz, info@mojefirma.cz, it@mojefirma.cz. Máte konkrétního zákazníka, který zasílá požadavky z domény @zakaznik.cz.  

Doporučená struktura by měla vypadat takto:

Vrátíme-li se ke struktuře projektů obecně, je potřeba brát v potaz další detaily. Pokud chcete integrovat procesy podpory s dalším jiným oddělením ve firmě (například vývojové oddělení), zvažte hlubší začlenění a větší propojení podporových projektů navzájem v celé projektové struktuře. 

Správně navržená projektová struktura vám pak do budoucna umožní například generovat různé reporty, seznamy, statistiky napříč různými fázemi vašeho byznysu. 

 

2 Napojení emailové schránky do Easy Projectu

Nyní se můžeme pustit do nastavení jednotlivých součástí Helpdesku. Aby se v Easy Projectu zpracovávaly příchozí emaily, je potřeba je správně napojit.

2.1 Administrace -> Helpdesk -> Všechny schránky -> Přidej schránku

2.2 Zadejte platné přihlašovací údaje k vaší schránce - klikněte na Test - pro ujištění a ověření, že se Easy Project dokáže spojit s emailovou schránkou. 

Detaily nastavení:

• Aktivní - nepřečtené zprávy jsou z emailové schránky Easy Projectem vybírány pravidelně. Pokud tuto volbu nezaškrtnete, schránka nebude vybírána. Můžete si ale nastavenou schránku nechat v Easy Projectu pro případné budoucí využití. 
• Použij jiného odesílatele - pokud uživatel není na serveru stejný, jako název schránky (například podpora-email-uživatel). Zadejte zde platnou emailovou adresu uživatele. 
• SSL - Použij SSL autentizaci - pokud váš mailový server používá SSL certifikát
• Povolit OAuth - Protokol OAuth 2.0 používají stovky známých služeb jako alternativní způsob ověřování. Pokud jde o poštovní schránku Help desku, lze jej použít k ověření přihlašovacích údajů odesílatele pomocí externí aplikace, aktuálně podporované jsou účty Google Workspace (dříve G Suite) a Microsoft Exchange. Pro správné vyplnění jednotlivých polí si prosím podrobně přečtěte OAuth 2.0 dokumentaci dané aplikace. Samozřejmě potřebujete administrátorský přístup v dané aplikaci pro zjištění nezbytných informací, které se vkládají do Easy Projectu, např. site URL, client ID, client secret, authorize URL, token URL, scope apod.
  
• Složky ke čtení - pokud chcete vybírat nepřečtené zprávy pouze z vybraných složek pošty
• Složka pro úspěch - do této složky bude přesunuta korektně zpracovaná zpráva (vytvořil se ticket)
• Složka pro chyby - do této složky bude přesunuta zpráva, která se nemohla korektně zpracovat (nebyl vytvořen ticket)

Po otestování nastavení klikněte na Uložit.

2.2.1 Kde najít pověření OAuth 2.0 pro účty Microsoft a Google

Chcete-li propojit Easy Project s účtem Google Workspace pomocí protokolu OAuth 2.0, musíte si vytvořit účet na Google Cloud Platform, získat zde uvedená potřebná pověření a zkopírovat je do nastavení poštovní schránky v naší aplikaci. Několik užitečných pokynů naleznete zde.

Chcete-li propojit Easy Project s účtem Microsoft Exchange pomocí protokolu OAuth 2.0, musíte si vytvořit účet na portálu Microsoft Azure, získat zde uvedená potřebná pověření a zkopírovat je do nastavení poštovní schránky v naší aplikaci. Několik užitečných pokynů naleznete zde.

Přístupové tokeny mají omezenou životnost (maximum je 6 měsíců), nelze vytvořit neomezené. Po uplynutí této doby schránka přestane fungovat a bude třeba vygenerovat nový token nový a zadat jej znovu do aplikace.

Přístupová URL OAuth 2.0 ve tvaru "/organizations/oauth2/v2.0/authorize" platí pouze tehdy, pokud je přístup do aplikace povolený v rámci organizace. V opačném případě musí přístupová URL odpovídat tvaru "/[TENANT_ID]/organizations/oauth2/v2.0/authorize". Správné nastavení naleznete v sekci Endpoints.

Při nastavení dvoufaktorového ověřování (2FA) v Microsoft Azure je třeba obnovit všechny připojené poštovní schránky.

2.2.1.1 Chyba "User is authenticated but not connected"

Příčinou je, že zvolený Azure uživatel, prostřednictvím kterého je schránka zaregistrována, nemá oprávění do dané schránky přistupovat. V tomto případě nestačí, je-li uživatel administrátorem, neboť je třeba, aby byl licencovaný pro použití Office 365. Má-li uživatel delegované oprávnění (není oprávěn si přidat přístup do schránky, ale schvaluje mu to např. administrátor), je třeba mu příslušné scope oprávnění přidat v Azure a současně vypnout tuto volbu

Řešení:

• Uživatel musí být buď přímo vlastníkem schránky, do které přistupuje (což mu dává potřebné oprávnění).
• Případně to může být jiný (licencovaný) uživatel, kterému byl do této schránky udělen přístup.

Dalším možným problémem je, že účet je vytvořen jako POP3 místo IMAP. POP3 v systému nepodporuje OAUTH.

Řešení:

• Ujistěte se, že je účet nastaven jako IMAP v azure i v Easy Projectu.

2.2.1.2 Chyba: Microsoft Help Desk se mi sice úspěšně připojí, ale po nějakém čase přestane fungovat

Zapoměli jste povolit právo pro offline přístup.

2.2.1.3 Případ použití: Mnoho schránek, jeden super Help Desk uživatel

Máte-li v rámci Microsoft Exchange zřízen větší počet Help Desk schránek a chcete delegovat přístupová práva ke všem těmto schránkám na jednoho uživatele, můžete tak učinit prostřednictvím Microsoft 365 admin center » Admin centers » Exchange.

Budete přesměrováni do sekce Exchange admin center. Zde klikněte na záložku Recipients » Mailboxes a vyberte schránku, jejíž přístupové právo chcete delegovat. Otevře se pravý pop-up sidebar, kde klikněte na položku Delegation.

Níže si povšimněte nápisu Read and manage (Full Access) s tlačítkem Edit, na které klikněte.

Vzápětí můžete vyhledávat a přidávat uživatele, kteří se stanou členy této schránky se stejnými právy jako vlastník schránky.

Vámi vybraný uživatel musí mít práva administrátora Help Desku na straně Easy Projectu.

2.2.2 Povolení ověřování OAuth 2.0 pomocí služby Azure Active Directory

Při použití ověřování OAuth 2.0 získáte přístup k webové službě z klientské aplikace. Způsob, jakým to provedete, závisí na použitém grantu. V tomto návodu se dozvíte, jak nakonfigurovat typ udělení přihlašovacích údajů klienta pro aplikace v Azure Active Directory.

2.3 Nastavení frekvence vybírání schránky

Klikněte pravým tlačítkem myši na danou schránku a vyberte volbu Nastavení.

Otevře se vám opět nastavení schránky, ale s podrobnějšími detaily. Ve výchozím stavu je schránka vybírána systémem po pěti minutách. Ale obecně doporučujeme nastavit tento limit zhruba po deseti minutách. Pokud máte v Easy Projectu napojeno více schránek, tato automaticky probíhající kontrola může zabrat více času a přetížit server příliš mnoha častými požadavky, což znatelně zpomalí celou aplikaci.  

Detaily:

• Spustit - ručně spustit výběr schránky
• Historie - zobrazit poslední proběhlou kontrolu schránky
• Smazat - odebrat schránku z Easy Projectem vybíraných schránek
• Deaktivovat - deaktivovat automatickou kontrolu schránky

Certainly! Here’s the translation in Czech, keeping all HTML formatting intact: ---

2.3.1 Interval serveru vs interval aplikace

V nastavení najdete možnost nastavit interval pro schránku. Tento interval lze nastavit na jakékoli číslo. Nejnižší možný interval je však určen nastavením cronu na serveru. Cron určuje nejnižší možný interval.

Příklad:

• Nastavení je na 5 minut, cron je nastaven na 10, bude se spouštět každých 10 minut.
• Nastavení je na 15 minut, cron je nastaven na 10, bude se spouštět každých 15 minut.

1. U Cloudového řešení je interval nastaven na 10 minut a nelze jej snížit. Je to proto, že na jednom cloudovém serveru běží více aplikací a toto nastavení se aplikuje na všechny. Kratší interval by mohl potenciálně způsobit problémy s výkonem.
2. U řešení Privátního serveru, kde je na jednom serveru pouze jedna aplikace, je možnost toto nastavení upravit. Privátní server je placená služba, více informací najdete zde. Výhodou je, že na serveru jste sami, takže není takové zatížení cronu, a nastavení se také týká pouze vaší aplikace.
3. To stejné platí pro řešení na vlastním serveru jako u privátního serveru. Vaše aplikace bude na serveru jediná. Server si spravujete sami, takže můžete nastavení přizpůsobit. Doporučený interval je 10 minut ve všech případech. Je však možné mít interval dokonce 1 minutu.

Doporučujeme opatrnost; sledujte, jak se aplikace chová při nižším nastavení, a podle toho interval upravte.

2.4 Automatická deaktivace

Zpracovávání emailových schránek v pravidelních intervalech vyžaduje výpočetní výkon, zejména při vyšším počtu schránek. Z tohoto důvodu jsme implementovali mechanizmus, který deaktivuje zpracovávání schránky, kde 7 krát po sobě selhalo přihlášení nebo stažení emailů. Deaktivace znamená, že se v nastavení schránky vypne volba Aktivní. Administrátor pak má možnost zkontrolovat nastavení schránky, otestovat a znovu aktivovat.

Proč? Pro ušetření vašich zdrojů. Proč by měl server opakovaně pingat do nefunkčně nastavené schránky?

3 Nastavení projektu

Máme v Easy Projectu napojenou schránku, ale zatím jsme nenastavili cíl, kde se mají vytvářet tickety. Dokud nepropojíme projekt s helpdeskem, nelze vytvářet tickety, protože obecně je každý ticket potřeba vytvořit v konkrétním projektu. 

Zde se návod rozděluje na několik různých postupů, podle záměru a typu projektu.

3.1 Výchozí projekt pro schránku

Vezměme si opět příklady z předchozí kapitoly - máme projekty Výchozí Helpdesk, INFO - obecné, IT - obecné, PODPORA - obecné, to znamená nelimitujeme a netřídíme podle konkrétní domény odesílatele. 

1. Klikněte na možnost „Přidat do Help desk“ na stránce Přehled projektu u zvoleného projektu.
   
2. Vyberte schránku, která bude pro projekt výchozí
   
3. Dole klikněte na Uložit

Podrobné vysvětlení jednotlivých položek nastavení podporového projektu najdete v další kapitole. 

3.2 Speciální projekt pro konkrétního zákazníka

Podle nastíněných příkladů z první kapitoly máme projekty: Bohemia Sun, Trains Francais, Klient 123, Klient ABC, Klient XYZ, Client 1 -> Podporový projekt, Klient 2 -> Podporový projekt. 

1. Vyberte z menu projekt
2. Vyplňte pole zvýrazněná na obrázku. Vysvětlivky jsou pod obrázkem. 
   
3. Dole klikněte na Uložit. 

Detaily nastavení:

• Výchozí pro schránku - pokud nastavujete speciální zákaznický projekt, NEVYBÍREJTE žádnou schránku
• Nastavení emailu nebo domény - nastavení v této části se navzájem nevylučují, takže platí, že pokud je splněna alespoň jedna podmínka, vytvoří se ticket v tomto projektu 
• Klíčové slovo - pokud doručená zpráva v jakékoliv z podporových schránek obsahuje klíčové slovo nebo slovní řetezec Jsem z firmy Zákazník ABC, bude ticket vytvořen v tomto projektu. Nepoužívejte stejná klíčová slova ve více projektech, pro hledání bude použit pouze první nalezený výsledek. 
• Email nebo doména - příchozí zprávy jsou hodnoceny podle těchto dvou hodnot v poli "OD". Například odesílatel může být kdokoliv s adresou domény zakaznikABC.cz nebo jím také může být konkrétní osoba, ale s jinou emailovou adresou, kterou přesto chceme také zařadit k tomuto projektu

Detailnější vysvětlení celého nastavení podporového projektu bude blíže vysvětleno v následující kapitole. 

DŮLEŽITÉ: Souběžné nastavení voleb Výchozí pro schránku a zároveň zadání konkrétní emailové adresy nebo domény není úplně vhodné řešení. Z každé příchozí zprávy bude vytvořen ticket bez ohledu na odesílatele, takže nepotřebujete jmenovitě uvádět adresy. Takové nastavení způsobí spíše zmatky. 

3.2.1 Uzavření a archivace speciálního projektu klienta

Pokud uzavřeme tento speciální projekt (bude dostupný pouze ke čtení), nebude možné v něm dále vytvářet tickety. Zprávy, přicházející z uvedených domén (v nastavení uzavřeného speciálního projektu), budou zpracovány systémem jako neznámé a tickety se vytvoří v obecném podporovém projektu.

Stejný postup se uplatňuje pro archivované projekty.

 

4 Konfigurace projektu - detaily

Nyní, když jsme si rozlišili, jaké typy projektů můžete pro podporu použít, můžeme pokračovat s vysvětlením dalšího nastavení projektu. Jakmile máme projekt propojen s podporou, jsou dva způsoby, jak se dostat na stránku nastavení podporového projektu. 

• 1. Administrace -> Helpdesk -> Všechny podporové projekty -> Upravit
  
• 2. Nastavení projektu -> Helpdesk
  

4.1 Základní nastavení

Detaily nastavení:

• Typ úkolu - nové tickety v tomto projektu budou vytvářeny jako tento vybraný typ úkolu
• Přiřazeno - nové tickety v tomto projektu se budou přiřazovat vybranému uživateli
• Spolupracují - nové tickety v tomto projektu budou mít tyto vybrané spolupracující (možno vybrat více položek)
• Vyplnit e-mail od - Když je tato možnost vybrána, e-mail autora bude automaticky vyplněn v novém tiketu. Tato možnost je užitečná, když máte projekty, kde jsou tikety vytvářeny skutečnými uživateli, namísto zpracování příchozích e-mailů.
• Automaticky aktualizuje úkoly, které - v závislosti na vašich pracovních postupech mohou existovat tickety, které už jsou ve skutečnosti vyřešené, ale zůstávají otevřené. V takových případech můžete nastavit automatické uzavření podle jejich stavu a doby nečinnosti. S uzavřením ticketu může být  automaticky zaslána zpráva podle připravené šablony, například s informací odesílateli (o uzavření ticketu) a se žádostí o jeho zpětnou vazbu k řešení ticketu. 
• Předplacené hodiny na měsíc - toto nastavení by mělo být použito pouze pro speciální klientské projekty, kde jsou pro zákazníky k dispozici určené předplacené hodiny podpory na měsíc.
• Agregované hodiny - smlouva se zákazníkem může obsahovat možnost přesunu nevyužitých hodin z předchozího měsíce. Pokud si například předplatil 10 hodin podpory, ale v květnu jich využil jen 7, zbylé 3 hodiny budou přesunuty do června.
• Zbývající hodiny - počet zbývajícíh hodin. Ikonkou tužky můžete ručně smazat hodiny - nastavit počet na 0.
• Agregovaný začátek - den, kdy začíná předplacené období; musí být vybráno datum dostupné ve všech měsících v kalendáři - tedy v rozmezí 1 - 28
• Agregované období - po jaké období platí agregované hodiny, než bude resetován počet na původní dohodnutý počet podle smlouvy. Pokud stále zbývá 13 hodin před koncem čtvrtletí (konec čtvrtletí je určen datem "Agregovaný začátek"), nebudou už převedeny do dalšího čtvrtletí. Počet dostupných hodin bude resetován na 10. 

Počty hodin k dispozici jsou počítány podle zadaných hodnot u projektu. O jaké se jedná přesně zadané hodnoty najdete dále v návodu. 
 

4.2 SLA

SLA (Service Level Agreements) jsou klíčové ukazatele výkonnosti v každém HelpDesk projektu, zejména v rámci smluv se zákazníky, které stanovují sankce za jejich porušení. Tikety mohou vznikat z e-mailu nebo být vytvářeny přímo v systému uživateli s omezeným přístupem. Způsob vytvoření mírně ovlivňuje nastavení SLA.

4.2.1 SLA pro tikety vytvořené z e-mailu

Poznámky k nastavení:

• Název – Interní název SLA (pro snazší administraci).
• Klíčové slovo – Stále vyžadováno pro tikety vytvořené z e-mailu. Pokud předmět příchozího e-mailu obsahuje toto klíčové slovo, použije se odpovídající SLA (s definovanými hodinami, prioritou, trackerem).
• Hodiny pro reakci – Definuje termín pro první změnu stavu tiketu.
• Hodiny pro vyřešení – Termín pro nastavení tiketu na uzavřený stav.
• Priorita – Automaticky se použije na tikety vygenerované e-mailem s klíčovým slovem.
• Tracker – Pomáhá automaticky klasifikovat příchozí tikety (např. „Defekt“).
• Počítat SLA podle pracovní doby – SLA může být počítáno buď podle pracovní doby, nebo 24/7.
• Pracovní hodiny & pracovní dny SLA – Definuje provozní kalendář (např. bez víkendů a svátků).

4.2.2 Pořadí SLA pravidel

Pokud existuje více SLA pravidel, systém kontroluje klíčová slova v příchozích e-mailech podle pořadí nastaveného v HelpDesk. Specifičtější klíčová slova musí být výše v seznamu.

Příklad:

• SLA „Kritická chyba“ musí být uvedena výše než SLA „Kritická“, aby odpovídala správně.
• Použijte * jako záchytné pravidlo pro obecné, neodpovídající předměty.

4.2.3 Znovuotevření tiketu & reset SLA

Při znovuotevření tiketu se nyní chování SLA řídí vylepšenou logikou:

• Pokud je SLA již splněno nebo nesplněno, znovuotevření tiketu neovlivní stav SLA, termín, zbývající čas ani čas splnění – pokud nastavení výslovně nepovolují výjimky.
• Pozastavené stavy jako „Čeká na odpověď zákazníka“ pozastaví odpočet SLA. Pokud je tiket následně uzavřen přímo z tohoto stavu, je SLA pro vyřešení označeno jako splněné s časem vstupu do pozastaveného stavu.

Chování resetu SLA lze upravit v sekci projekt HelpDesk >> SLA:

• Povoleno – SLA se restartuje od momentu znovuotevření.
• Zakázáno – SLA pokračuje od původního času vytvoření.

4.2.4 SLA pro interně vytvořené tikety

Interně vytvořené tikety (přes UI) nepoužívají klíčová slova. SLA se přiřazuje na základě kombinace Priority a Trackeru.

• Ponechte Klíčové slovo prázdné pro tyto SLA.
• Pokud je Tracker vynechán, uplatní se pouze pravidla založená na klíčových slovech.

Pomocí workflow lze omezit klienty, aby používali pouze specifické trackery, např. „HelpDesk Ticket“ nebo „Chyba“.

4.2.5 SLA reportování

Zásadní změna od verze 14.9.0

Až do verze 14.8.x bylo SLA reportování založeno na entitě zvané SLA události. Reporty byly vytvářeny nad SLA událostmi, nikoli nad samotnými tickety, a proto chyběly některé důležité běžně používané metriky helpdesku. SLA události zůstávají v systému a nové SLA reportování je na nich stále postaveno. Od verze 14.9 a výše se však kritické atributy zrcadlí přímo do ticketů, což umožňuje reporty založené na ticketech.

Jak to funguje

Každý ticket má v hlavičce vlastní sekci s informacemi o SLA, zobrazující zvlášť údaje pro SLA první odpovědi a SLA vyřešení. Pro každé z nich vidíte stav SLA, zbývající čas, trvání, termín a čas splnění. SLA stavy v rámci každého ticketu:

• Probíhá
• Pozdrženo
• Splněno
• Nesplněno

Každý stav má vlastní barvu pro snadné rozpoznání. Zbývající čas a trvání se zobrazují ve formátu hh:mm. Zbývající čas je zelený, dokud je kladný, a přechází na červený se známénkem mínus, jakmile je termín nesplněn— v tomto bodě se stav SLA mění na Nesplněno. Odpověď nebo vyřešení v rámci pozitivního/zeleného zbývajícího času vede ke splnění SLA. Termín a čas splnění jsou ve formátu datum a čas. Zbývající čas, Trvání a Termín respektují vaše pracovní dny a hodiny, pokud jsou takto nastaveny v projektu Helpdesku. Při pozastavení SLA, např. ve stavu „Čeká se na info od zákazníka“, se čas zastaví. Po obnovení ticketu a jeho návratu do aktivního stavu, zbývající čas a trvání se znovu spustí a termín se posune o dobu, po kterou byl pozastaven.

Všechny tyto SLA údaje jsou také dostupné v Dashboardech a přes API. Tento podrobnější a intuitivnější rozklad dat umožňuje rychlé, snadné, dynamické a přesné SLA reportování. Dříve tyto informace obsahovala entita SLA událostí, ale nyní již není nutné ji dotazovat, protože vše je dostupné na entitě Úkoly. 

SLA události zůstávají zajímavé pro čistě záznamové účely, protože umožňují rychlý a jednoduchý přehled o tom, kdo a kdy provedl jakou SLA-relevantní změnu v ticketu. SLA události se nachází ve spodní části ticketu v samostatné záložce.

Shrnutí změn od verze 14.9.0:

• SLA události již nejsou primárním sledovacím mechanismem. Nadále však fungují jako historické záznamy a podpůrná entita.
• SLA události se vytvářejí při změně stavu ticketu nebo přepočtu SLA.
• Globální nastavení „Vytvářet SLA události ze všech stavů“ bylo odstraněno.
• Pole SLA událostí jako Sla response, Sla resolve atd. budou ve verzi 15 zrušena. Během přechodného období, před verzí 15 se stále zobrazují i tyto hodnoty SLA.
• Na záložce SLA událostí v detailu ticketu byla přidána nová sloupec Stav SLA.

4.2.6 Práce s SLA

Tato kapitola je lépe vysvětlena v tomto videu (EN, 6 minut, lze zrychlit).

Od verze 14.9 má změna stavu ticketu automatický dopad na SLA a vytvoří SLA událost. Práce s SLA je nyní výhradně vázaná na stav ticketu, čímž odpadá nutnost posílat e-mail (platilo do verze 14.8).

Pokud máte k určitým stavům ticketů přiřazené e-mailové šablony a v nastavení šablony je aktivní volba „Odeslat okamžitě“, pak změna stavu ticketu automaticky odešle příslušný e-mail. SLA řízení se tak redukuje na jednoduchou změnu stavu. Samozřejmě, možnost ručně odeslat e-mail klientovi zůstává, pokud tak máte nastavený proces. Viz 5.1.2 pro více informací o ručních e-mailech.

Pokud má SLA stav nesplněno nebo úspěšně splněno, pak další opětovné otevření nebo uzavření ticketu nezmění SLA stav, čas splnění, termín, zbývající čas ani trvání — ledaže je v nastavení určeno jinak, např. možnost „Reset SLA při znovuotevření“, která resetuje a spustí SLA od času znovuotevření.

Pokud se změní priorita ticketu nebo typ úkolu, systém automaticky přepne na odpovídající SLA, přepočítá jej a zároveň zachová již uplynulý čas, včetně stavu splněno/nesplněno, a změnu zaznamená jako SLA událost. Když je ticket přesunut mezi projekty, SLA se nepřepočítá. SLA ticketu zůstává z původního projektu, ve kterém byl ticket vytvořen. Přepočet SLA se spouští změnou typu úkolu a/nebo priority.

Od verze 14.9 se SLA události nově vytvářejí při klíčových akcích jako změny stavů nebo přepočty, zaznamenávající čas a typ změny. Pole SLA událostí byla vylepšena, včetně nového sloupce Stav SLA pro přehlednější sledování.

Každý ticket nyní obsahuje dedikovanou sekci SLA zobrazující:

• Stav SLA – Probíhá, Pozdrženo, Splněno, Nesplněno.
• Zbývající čas – Odpočet do termínu SLA (pozastaví se při přerušení ticketu, může být záporný při překročení termínu).
• Trvání – Čas od začátku SLA (roste, nikdy není záporný).
• Termín – Časové hranice pro splnění SLA; při znovuaktivaci se přepočítá.
• Čas splnění – Přesný okamžik, kdy byla SLA podmínka splněna (např. první změna stavu pro první odpověď).

Tuto SLA sekci lze skrýt pro vybrané typy uživatelů, role nebo konkrétní uživatele prostřednictvím:

• Administrace >> Typy uživatelů >> Upravit
• Administrace >> Uživatelé >> Upravit
• Administrace >> Role a oprávnění >> [Vyberte roli] – Zobrazit SLA události

Pokud je omezení aktivní, uživatel neuvidí SLA data u ticketů.

4.2.7 Přepočty SLA

Pokud se změní priorita nebo typ úkolu, systém kontroluje, zda odpovídá novému SLA:

• Pokud ano, SLA se přepočítá — zachová se uplynulý čas a původní stav.
• Pokud ne, aktuální SLA zůstává zachována.
• Všechny přepočty generují novou SLA událost.

4.2.8 Dashboardy a reporty

SLA data jsou nyní plně dostupná prostřednictvím dashboardů založených na ticketech pomocí dynamických filtrů:

• SLA pole (stav, zbývající čas, trvání, termín, čas splnění) jsou dostupná jak pro SLA první odpovědi, tak SLA vyřešení.
• Starší pole jako Hodiny do odpovědi a Hodiny do vyřešení jsou také zahrnuta.

Poznámka: Zbývající čas a Trvání se zobrazují až po splnění SLA a pouze u uzavřených ticketů.

4.2.9 API a Automatizace

Aktualizované Tasks API nyní obsahuje všechna SLA pole dostupná v dashboardech, za stejných podmínek.

• Hodnoty SLA jsou dostupné až po splnění.
• Integrace přes n8n konektor umožňuje automatizovaný přístup k SLA datům ticketů. Hledejte Easy Redmine na n8n marketplace.

4.3 Úprava hlavičky a patičky

Tato část nastavení je zaměřena na emailovou komunikaci zákaznické podpory, respektive na komunikaci pomocí automaticky generovaných ticketů z emailových zpráv. Můžete si tak odlišit zprávy od jiných zpráv z jiných projektů, ať už podle firemní politiky, podle vyhrazených předepsaných pojmů nebo pravidel týkajících se citlivých (neveřejných) údajů. 

Globálně nastavené záhlaví a zápatí e-mailových oznámení (Administrace >> Nastavení >> E-mailová oznámení) již nebudou součástí e-mailů odesílaných z HelpDesku.

4.4 Výstrahy

Aby se lépe předešlo porušování nastavených SLA lhůt, v nastavení máte možnost využít zasílání automatických upozornění (výstrah), které upozorní operátory na tickety, u kterých hrozí nedodržení lhůty.

Další možná výstraha může sledovat odpracovaný čas na projektech, u kterých mají zákazníci předplacené hodiny podpory (více detailů najdete v kapitole 4.1). 

Detaily nastavení:

• Kontroluj datum a čas dokončení - přesněji Čas dokončení vzhledem k nastavené SLA lhůtě. Pokud zvolíte, výstrahy budou zasílány v případě, že se blíží vypršení lhůty. Další detaily najdete níže.
• Kontroluj celkové čerpání hodin - počítá odpracovaný čas na projektech podle konkrétních předplacených hodin na měsíc
• Seznam výstrah, které potřebují nastavit notifikační email - přednastavené výstrahy, u kterých jen doplníte emailovou adresu příjemce, na kterou má být upozornění zasláno
• Seznam výstrah - nastavené výstrahy, kde už jsou nastavené všechny detaily
• Kliknutím na každou z výstrah se zobrazí přednastavené detaily s možností jejich úprav
• Varování/Upozornění: důležitost oznámení
• Čas dokončení úkolů - sleduje nastavení SLA lhůty vyřešení ticketu (uzavření ticketu)
• Čas první odpovědi - sleduje SLA lhůtu pro první reakci (první změnu stavu úkolu)
• Předplacené hodiny podpory - sleduje odpracovaný čas v projektu z předplacených hodin na měsíc

Počet hodin v posledním zmíněném upozornění jsou zaznamenané hodiny odpracovaného času u ticketu, které jsou nastaveny u typů úkolů podporového projektu. 

Příklad: výchozí typ úkolu pro projekt je Podporový ticket. Máme nastaveny SLA lhůty pro typ úkolů Bug (chyba). V projektu mohou být i úkoly jiného typu (například Úkoly nebo Vývoj doplňku), které ale nejsou vytvářeny jako tickety. V takovém případě se předplacené hodiny počítají jen pro typy úkolů Podporový ticket a Bug (chyba). Odpracovaný čas na jiných typech úkolů se nepočítá do souhrnu pro tuto výstrahu.

4.5 Uložit/Smazat

Uložit/Aktualizovat - uloží provedené změny v nastavení podporového projektu
Smazat - odebere projekt z podpory. Neznamená to smazání projektu jako takového, pouze bude zrušeno propojení projektu na helpdesk.

 

5 Zpracování ticketů

Než se vrátíme k dalším detailům konkrétního nastavení, je nyní čas podívat se na pár praktických důsledků už zmíněných návodů. Začneme s jednoduchým příkladem, na kterém si ukážeme, jak fungují tickety. Sice přeskočíme pár funkcí, ale později se k nim ještě vrátíme.

5.1 Tickety vytvořené z příchozích emailů

Pro správné zacházení s tickety vytvořenými z příchozích zpráv je potřeba zkontrolovat, zda jsou pole "Email (komu)" a  "Email (kopie)" aktivována. Jděte do Menu Další -> Typy úkolů -> Help desk ticket -> Standardní sloupce. Pokud zde tato pole nevidíte, musely být odebrány správcem.

5.1.1 Email je zpracován Easy Projectem a vytvořil se ticket v příslušném projektu

Detaily:

• Email komu: Odesílatel emailové zprávy, ze které byl vytvořen ticket 
• Upřesnění emailové schránky, ze které byl vytvořen úkol
• SLA lhůty - pokud nejsou dodrženy, jsou zvýrazněny červeně
• Detail zprávy - jedná se o textový obsah e-mailu včetně všech obrázků, které byly součástí původního e-mailu. Obrázky se nyní zobrazují inline v popisu tiketu nebo v komentářích, což agentům usnadňuje zobrazení celého kontextu požadavku zákazníka.
• Celý původní e-mail je v případě potřeby k dispozici také jako příloha.
  

5.1.2 Napište odpověď a aktualizujte ticket

Pro splnění SLA na odpověď stačí pouze změnit stav ticketu. Doporučujeme však také odeslat klientovi potvrzovací odpověď pomocí e-mailové šablony. Uváděné příklady berte prosím s rezervou, odpovědi jsou jen na ukázku toho, jak funguje komunikace z technického hlediska systému.

Manažer podpory napsal zákazníkovi info o obdržení jeho požadavku, přiřadil ho operátorovi a aktualizoval stav. Odpověď je zaslána na zadanou adresu Email (komu), pokud je pole zaškrtnuto.

Pošlete rychlou odpověď ze šablony

Zákazníkovi můžete odepsat dvěma způsoby. Při aktualizaci helpdeskového ticketu máte možnost "Poslat rychlou odpověď ze šablony" - můžete si vybrat z připravených šablon odpovědí. Po vybrání šablony je odpověď odeslána obratem, takže nemusíte udělat nic dalšího. I když nevyberete žádnou šablonu pro rychlou odpověď v tomto kroku, i nadále je volba šablony dostupná a můžete potvrdit odeslání zprávy v dalším kroku (zaškrtněte volbu "Poslat email zákazníkovi (s náhledem)" v dolním menu a uložte). Odpovědi ze šablony vám ušetří spoustu času.

5.1.3 Pošlete aktualizaci na externí emailovou adresu (Email komu)

Kliknutím na Uložit si uložíte všechny aktualizace úkolu (ticketu) a otevře se vám dialog pro odeslání odpovědi zákazníkovi. 

Detaily:

• Emailová šablona - pokud máte připravené šablony pro emaily, vyberte si jednu z nich. Nebo může být přednastavena šablona podle stavu ticketu. Tento detail si ještě vysvětlíme v další kapitole. 
• Odesílatel - tato adresa bude zobrazena příjemci v poli "Od". Nastavení detailu této adresy si také upřesníme v dalších kapitolách. 
• Předmět - vepište vlastní nebo bude přednastaven podle zvolené šablony.
• Příjemce - odesílatel původní zprávy. Pokud byla původní zpráva zaslána na více příjemců v kopii, tyto adresy také budou přidány do tohoto pole
• Odpověď na - zde je vždy uvedena adresa podpory, na kterou byla zaslána původní zpráva
• Kopie na - můžete přidat adresy dalších příjemců
• Tělo zprávy - pokud nebyla vybrána šablona, v těle bude původní text zprávy a poslední komentář. Obsah lze upravovat
• Přílohy - vyberte přílohy, které chcete ke zprávě přiložit. Mohou to být poslední zprávy nebo nové soubory, které nahrajete při aktualizaci ticketu
• Odeslat email - zpráva bude zaslána všem příjemcům
• Neodeslat email - vrátíte se k detailu ticketu

Pokud se podíváte zpět na detail ticketu, vidíte, že zmizela lhůta pro SLA první reakci, protože jsme právě už odpověděli.  

5.1.4 Zákazník odpovídá zpět - jak se spárují emaily s ticketem

Zákazníkovi dorazila vaše odpověď a odpovídá vám zpět. Jeho odpověď bude přidána jako komentář od anonymního uživatele (neregistrovaný uživatel).  

Pojďme si vysvětlit jak si zákazníkova odpověď najde cestu ke správnému ticketu. 

Když mananažer, v předchozím kroku, odpovídal zákazníkovi, emailová zpráva obsahovala skrytou hlavičku (tak, jak ji obsahují všechny emaily), kde je uloženo ID daného ticketu. V další odpovědi zákazníka je tedy také součástí zmíněná hlavička, která v sobě má zmíněné ID, a proto helpdesk systém dokáže identifikovat správný ticket a přidat k němu novou odpověď.

Doručené emailové zprávy jsou k ticketům systémem párovány takto:

1. Hlavička emailu, kde je uloženo ID úkolu
2. Předmět emailové zprávy, kde je hledána kombinace "#" (číslo) a ID úkolu
3. Pokud není nalezeno ID, systém hledá v předmětech pouze samotné číslo

Takže i když zákazník napíše novou zprávu na adresu podpory, a přidá číslo ticketu (ID úkolu) do předmětu, jeho zpráva se spáruje s původním ticketem. Jako v následujícím příkladu. 

Nová zpráva na adresu podpory:

Následná poznámka u ticketu:

5.1.5 Poslední odpověď - uzavření ticketu

Pokud dojde na poslední odpověď operátora, ticket se může uzavřít. Pokud zákazník znovu ještě odpoví, ticket bude znovu otevřen a bude u něj nastaven připravený stav (toto nastavení si upřesníme později).

5.1.6 Pole Vlastník ticketu

Pole Vlastník ticketu je volitelné standardní pole pro práci s podporovými tickety. V rozbalovacím menu můžete vybrat vhodného operátora ze seznamu všech vytvořených uživatelů, tento uživatel je pak považován za vlastníka ticketu. Dostupnost tohoto pole si můžete povolit nebo odebrat pro jakýkoliv typ úkolů, u kterých to můžete potřebovat. Jděte do Administrace -> Typy úkolů -> Helpdesk ticket -> zaškrtněte příslušné pole a uložte nastavení. Ve výchozím nastavení pole Vlastník ticketu není povoleno, takže manažer podpory ho musí v administraci povolit pro konkrétní typ úkolů. Podle tohoto pole u podporových ticketů následně má manažer podpory pěkný přehled o počtu přijatých ticketů, počtu uzavřených/vyřešených ticketů a o jejich aktualizacích - vše lze vytřídit právě podle vlastníků ticketů. Tím se výrazně zjednoduší a zlepší přehledy podporového provozu (dashboardy, statistiky) a reporty pro vybrané časové období. Pro toto pole Vlastníka ticketu můžete také aplikovat Nastavení pracovních postupů, stejně jako Action buttons - stejně jako jakákoliv jiná uživatelská pole. 

5.1.7 Vyplnění polí Email to, cc z různých zdrojů

Do polí Email to a Email cc byla přidána možnost vyhledávat e-maily ze zdrojů dat:

• Osoby (CRM)
  
• Stakeholdeři
• Klienti (CRM)
  
• Help desk uživatelé (Help desk)
  

Tato funkce je ve výchozím nastavení vypnutá. Chcete-li ji povolit, přejděte do Administrace >> Moduly >> Email field autocomplete - Upravit a aktivujte funkci Email field autocomplete a potřebné zdroje dat.

Funkce nativně vyhledává v uživatelích, i když neoznačíte žádný datový zdroj. Zobrazené e-maily uživatelů jsou určeny typem uživatele aktuálního uživatele a nastavením viditelnosti.

Jak to funguje

Pokud je funkce zapnutá, pole Email to a cc se chovají jako vyhledávač.

5.2 Interně vytvářené tickety

Pokud zákazník zadá ticket přímo do systému, můžete nastavit pracovní proces stejně jako u jiných úkolů. Můžete zákazníkům umožnit vytvářet typ ticketů Chyba (Bug). Budou zadány ve výchozím stavu - nejčastěji jsou označovány jako Nové. Další komunikace probíhá mezi zákazníkem a operátorem formou aktualizací ticketu a změnou přiděleného operátora, protože je potřeba, aby vždy komunikovali aktivní operátoři. SLA lhůty jsou monitorovány v závislosti na parametrech Odpověd - změna stavu nebo Stav vyřešeno - uzavřený ticket.

5.3 Tickety vytvořené přes REST API

tickety (úkoly) lze také vytvořit přes REST API (například z webového formuláře), budou vypadat jako tickety vytvořené klasickým způsobem z emailových zpráv. Přes API stačí poslat parametr "easy_helpdesk_mailbox_username", tedy například  ssue[easy_helpdesk_mailbox_username] = 'support@company.com" . Takto založíte nový ticket se zadanou emailovou adresou, stejný jako vytvořený systémem. Lhůta SLA bude počítána podle příslušného nastavení (jako u ostatních ticketů), a odesílateli bude zaslána děkovací zpráva. 

 

6 Emailové šablony

Už jsme to nastínili v předchozí kapitole, ale bez patřičného vysvětlení celého procesu nebude snadné mu porozumět. Zatím jsme si nepředstavili poslední položku v helpdesk menu. 

Emailové šablony přináší jistou úroveň automatizace a formálnost komunikace se zákazníky, díky které zákazníci mohou považovat vaši firmu za profesionály. 

Důležitou vlastností emailových šablon je konfigurovatelnost na konkrétní schránku, není možné použít šablonu nastavenou pro schránku IT@mojefirma.cz pro zprávy zasílané ze schránky podpora@mojefirma.cz.

6.1 Vytvoření emailové šablony

K dispozici jsou dva typy emailových šablon: automatická odpověď a standardní šablona. Nastavení obou je stejné, takže si ho vysvětlíme jen jednou.

6.1.1 Přidání nové šablony

Pro vytvoření šablony, klikněte na tlačítko v pravo:

6.1.2 Základní vlastnosti

Zde vidíte, jak vypadá stránka pro vytvoření nové šablony. Budete si moci vybrat, do jaké schránky bude šablona patřit a pro jaký stav se bude zobrazovat.

Detaily nastavení:

• Odeslat okamžitě - e-mailové oznámení bude odesláno pokaždé, když se změní stav úkolu.
• Aby se zabránilo zbytečným oznámením, doporučuje se nastavit workflow tak, aby úkoly nemohly opakovaně přecházet do stejného stavu.
• Tato funkce zajišťuje okamžité spuštění e-mailových oznámení při vytvoření nebo aktualizaci požadavku, čímž obchází obvyklé zpoždění způsobené čekáním na další cron úlohu. Přesto může vést k duplicitním e-mailům, pokud je povoleno vytváření požadavků prostřednictvím e-mailu.
• Vyhněte se používání možnosti "Odeslat okamžitě" pro všechny typy oznámení, pokud jsou nastavena pravidla SLA. Tato funkce by měla být omezena pouze na změny stavu, aby byla oznámení relevantní a zabránilo se nadměrnému nebo redundantnímu zasílání zpráv.
• Použij pro schránku - pro kterou schránku bude tato šablona dostupná
• Stav úkolu - podle uvedeného stavu bude předvyplněn dialog šablony při odesílání emailu na externí emailovou adresu (vizte kapitolu 5.1.3.)
  • Pro použití šablony pro automatickou odpoveď na nově vytvořené tickety z emailové zprávy nastavte stav na výchozí hodnotu (tak jak je nastaveno v Administraci -> Stavy úkolů). Tak bude odeslána automatická odpověď s touto šablonou ihned po vytvoření ticketu z doručené emailové zprávy. Můžete tak posílat potvrzení o přijetí zprávy a informovat zákazníka o dalším postupu.
  • Stav nemusíte zadávat, v takovém případě se pak automaticky text nepředvyplní, ale uživatelé ho mohou manuálně vybrat
• Předmět - obsah předmětu emailové zprávy
• Doporučujeme do předmětu automatické odpovědi vyplňovat ID úkolu - pokud si s jedním zákazníkem posíláte více emailových zpráv zároveň, snáze jeho odpovědi rozlišíte a zařadíte
• Můžete také použít vždy aktuální předmět ze zákazníkovy původní zprávy

6.1.3 Proměnné a tělo emailu

Proměnné můžete využít pro poskytnutí konkrétní informace o ticketu zákazníkovi. Na obrázku vidíte, jak je lze v šabloně zadat, ve zprávě odeslané zákazníkovi budou pak nahrazeny aktuální hodnotou z daného ticketu. 

Jednoduchá ukázka automatické odpovědi.

6.1.4 Důležité proměnné

Chcete-li efektivně využívat emailové šablony, je potřeba aby v šabloně byla zadána proměnná  %task_note%. Tak do připraveného textu šablony bude zahrnut poslední komentář od ticketu.

Pro přidání firemního podpisu do odesílaných emailů použijte proměnnou %user_signature%. Načte se HTML podpis aktuálního uživatele (který aktualizuje ticket), tento podpis lze nastavit v uživatelském účtu. 

Příklad: Ukážeme si jednoduchý návrh šablony, obsahující komentář operátora podpory, celkový odpracovaný čas na ticketu a firemní podpis uživatele. 

Šablona bude vypadat takto.

Takto operátor přidá komentář.

A toto bude odeslaný email podle šablony.

Poznámka: Pokud použijete emailovou šablonu společně se záhlavím a zápatím emailu v konkrétním projektu (kapitola 4.3.), projektové záhlaví a zápatí bude na začátku a na konci celé zprávy, nikoliv jen před/za textem ze šablony nebo za textem posledního komentáře.

6.1 Výchozí emailová šablona

Jednu z připravených podporových šablon si můžete nastavit jako výchozí. Při odepisování zákazníkovi je tak vyšší pravděpodobnost využití šablony (čímž se usnadní práce operátorům podpory). 

Chování je následující:

Podmínky

• jedna šablona může být nastavena jako výchozí
• každá šablona musí být přidělena k emailové schránce
• v systému můžete mít více emailových schránek
• emailová šablona může být (ale není to nutné) navázána na konkrétní stav

Možné situace

• ticket je zadán ručně (ne z příchozí zprávy) - šablona je přednastavena podle stavu; pokud není dostupná, přednastaví se výchozí šablona
• ticket je vytvořen z jiné emailové schránky, než pro kterou lze použít výchozí šablonu - bude přednastavena šablona podle stavu ticketu -> pokud k danému stavu není určena žádná šablona na výběr, pak nebude automaticky žádná přednastavena
• ticket je vytvořen ze schránky, pro kterou je nastavena výchozí šablona - bude přednastavena šablona podle stavu - pokud nebude taková nalezena, pak bude použita šablona výchozí

7 Obecné nastavení

Když jsme si prošli celou funkčnost, můžeme si dovysvětlit zbývající nastavení. 

Detaily nastavení:

• Odesílatel - jaká emailová adresa bude uváděna v poli OD v odpovědích na ticket (souvisí s kapitolou 5.1.3.)
  • Přihlášený uživatel - uživatel, který aktualizuje ticket
  • Výchozí z emailové notifikace - emailová adresa, ze které se posílají standardní systémové hlášky. Je nastavena v Administraci -> Nastavení -> Emailová oznámení
  • Adresa emailové schránky - emailová adresa, na kterou byla doručena původní zpráva od zákazníka
  • Toto nastavení lehce souvisí s předchozí položkou - Povolit vlastního odesílatele - je-li povoleno (zaškrtnuto), lze nastavit vlastní emailovou adresu odesílatele v nastavení podporového projektu. Pokud je u projektu v nastavení uvedena adresa, přepíše se adresa odesílatele. 
• Povolit přepsání hodnot - v případě zvolení tohoto checkboxu bude možné měnit některé vlastnosti ticketů vytvořených z příchozích emailů. Například vepsáním detailu priorita: Vysoká do těla zprávy můžete upravit jeho prioritu. Jedná se spíše o pokročilou funkci a nedoporučujeme nechat ji využívat i zákazníky.
• Přijímat automatické zprávy - například newslettery
• Ignorovat CC přijatých emailů - pokud zaškrtnete, adresy zadané v kopii nejsou zpracovány a nebudou u ticketu použity v poli "Email komu" (kapitola 5.1.3. - detail o adrese příjemce). 
• Změnit stav po odpovědi klienta na - každá nová odpověd od zákazníka automaticky aktualizuje stav ticketu. Toto je užitečné především pro tickety uzavírané po odeslání odpovědi operátorem. ticket zůstane uzavřený, dokud zákazník nenapíše zpět například doplňující otázku. Po jeho odpovědi je ticket znovu označen jako otevřený - aktivní - a je zařazen zpět do fronty mezi ostatní otevřené tickety
• Pozastavit SLA úkolu ve stavech - vyberte stavy, kdy se nebude počítat lhůta SLA, protože ticket čeká na doplňující info od zákazníka, bez kterého nelze problém vyřešit
• Počítat SLA úkolu ve stavech - nastavte stavy, kde bude SLA normálně počítáno. Takto můžete upravovat a definovat životní cykly ticketů. Například operátor se zeptá zákazníka na doplňující info, nastaví stav na pasivní a pozastaví počítání SLA. Jakmile zákazník odpoví, status se opět změní a SLA je znovu počítána podle nastavené lhůty. 

Ve verzi 12, přibyla v Help desku nová metrika - Tikety vyřešené podporou. Ukazuje množství nebo poměr tiketů, které nikdy neopustili tým podpory.

Jak to funguje

1. Nejdřív je třeba vyjmenovat uživatele, kteří jsou patří do týmu podpory (v globálním nastavení Help desku)
   
   
   
2. Nastavení pro podúkoly a související úkoly vyloučí nebo zahrnou tikety, které je obsahují
3. Teď doporučujeme použít tlačítko na rekalkulaci
   
   Tímto se vyhodnotí tikety za posledních 90 dní
4. Konečně, na seznamu úkolů naleznete nový filtr.
   
   

Tento filtr zobrazí pouze tikety, které byly přiřazeny pouze členům týmu podpory (dle nastavené v bodu 1). Dle nastavení v bodu 2 se pak zobrazí nebo nikoliv tikety obsahující podúkoly nebo související úkoly.

 

8 Filtr "Reagovat?"

"Reagovat?" je parametr podporových ticketů a CRM případů. Jako výchozí je nastaven stav "Ne". Ke změně na "Ano" dojde v případě, kdy je ticket/případ přiřazen operátorovi, který na ticket odpoví (odešle emailovou zprávu), místo toho, aby ho přiřadil zpět odesílateli v Zákaznické zóně nebo v Easy Projectu. V takovém případě totiž přiřazený uživatel zůstává nezměněn, takže zamýšlený příjemce se nemusí o provedené aktualizaci dozvědět. Jak tomu předejít? Příjemce by měl pravidelně kontrolovat všechny položky označené příznakem "Reagovat?" se stavem "Ano", takže snadno najde ty tickety/případy, kde došlo k aktualizacím a kde je potřeba odpovědi, i ty, které nemá přiřazené u sebe. Nebo tuto možnost můžete využít, když si pro sebe potřebujete "označit" nějaký zákaznický ticket, na který už jste odpověděli, ale ještě je potřeba něco dořešit a potřebujete zákazníka později znovu informovat. Použijte modul "Úkoly podle filtru", můžete tak snadno vytvořit prostor na své homepage, kam si přidáte přehled CRM příadů nebo třeba přehled provozu na podpoře. 

 

9 Uživatelé služby HelpDesk

Mezi nejvýznamnější nově přidané prvky HelpDesku v posledních letech patří tzv. uživatelé HelpDesku. Jejich účelem je zjednodušit správu přístupu klientů k vašemu Easy Projectu. Také samotným klientům výrazně usnadňují zadávání ticketů a komunikaci s vašimi operátory přímo v aplikaci.

9.1 Předpoklady

Správa uživatelů HelpDesku se nachází pod oprávněním Zobrazení/Správa uživatelů HelpDesku v sekci HelpDesk v části Admin >> Role a oprávnění.

Další nastavení, které je třeba zkontrolovat před zahájením vytváření uživatelů HelpDesku, je Admin >> Přizpůsobení stránek >> Uživatelé HelpDesku >> Přehled šablon. Měla by zde být existující šablona stránky v základní „startovací“ konfiguraci. Je důležité, aby existovala šablona, která je nastavena jako výchozí - tato šablona bude automaticky použita pro nové uživatele HelpDesku. Jinak by vaši uživatelé HelpDesku měli po přihlášení prázdnou stránku.

Uživatelská stránka HelpDesk obsahuje 3 typy modulů:

• Formulář pro nový ticket - Nemá žádné nastavení, stačí jej umístit pro maximální pohodlí vašich klientů.
• Tickety HelpDesku - seznam ticketů vytvořených uživatelem HelpDesku. Každý uživatel může vidět pouze tickety, které sám vytvořil. Tento modul je konfigurovatelný, stejně jako všechny ostatní moduly „seznamů“ v aplikaci. Obsahuje pole viditelná pro uživatele HelpDesku v ticketech. Pokud máte v úmyslu zobrazovat uživatelům HelpDesku otevřené i uzavřené tickety, doporučujeme je zobrazovat v samostatných modulech.
• Dashboard - pro případ, že chcete klientům sdělit nějaké vlastní informace.

9.2 Správa uživatelů HelpDesku

Seznam uživatelů služby HelpDesk je k dispozici jako samostatná položka v ovládacích tlačítkách na panelu nástrojů služby HelpDesk.

Všechny atributy jsou povinné:

• Křestní jméno
• Příjmení
• E-mail = přihlášení
• Jazyk
• Projekt - jedná se o projekt, ve kterém budou vytvořeny tipy tohoto uživatele. Zde lze vybrat pouze otevřené projekty, které jsou připojeny k HelpDesku.
• Heslo - při vytváření uživatele je nutné zadat heslo s možností vygenerovat token hesla, aby si uživatel mohl nastavit vlastní heslo prostřednictvím odkazu v e-mailu. Při úpravě uživatele není změna hesla samozřejmě vyžadována.

Další oprávnění:

Každému uživateli lze udělit další oprávnění k prohlížení a správě všech úkolů.

Zobrazit všechny úkoly = Umožňuje uživateli helpdesku vidět všechny vytvořené tickety ve stejném projektu (vytvořené/přiřazené jiným uživatelům helpdesku), ale neumožní vám přístup ke všem úkolům, které se netýkají helpdesku.

Spravovat všechny úkoly = Umožňuje uživateli helpdesku upravovat určitá pole již vytvořených ticketů (Název, Popis, a také přidat novou přílohu; ale neupravovat starou).

Příklad využití

Klient má speciální projekt pro své tickety v rámci Helpdesku. Do portálu helpdesku se přihlašuje více uživatelů a podává žádosti jménem tohoto klienta. Jeden z těchto uživatelů potřebuje vidět všechny odeslané tikety, protože jeho role vyžaduje, aby hodnotil vámi poskytované služby.

9.2.1 Import CSV

Od verze 11plus.2.0 je možné importovat uživatele HelpDesku prostřednictvím CSV. Ohledně této možnosti se prosím obraťte na svého konzultanta.

9.3 Přihlášení jako uživatel služby HelpDesk

Uživatelé HelpDesku se přihlašují přes jiný vstupní bod než běžní uživatelé. Na přihlašovací obrazovce pod tlačítkem pro přihlášení najdete přepínač. Chcete-li své klienty nasměrovat na přihlášení do služby HelpDesk, použijte adresu URL /helpdesk/login. Jak bylo uvedeno výše, jako přihlašovací jméno se používá e-mail.

DŮLEŽITÉ: Uživatelé služby HelpDesk jsou technicky nezávislí na běžných uživatelích. Pro jednoho běžného uživatele a jednoho uživatele HelpDesku můžete používat stejný e-mail.

Ačkoli praxe naznačuje, že byste to tak dělat neměli. Buď zřídíte účet uživatele HelpDesk, nebo se rozhodnete, že uživatel potřebuje plnohodnotný účet. Oba typy účtů pro jednu osobu by se měly používat pouze pro testovací účely.

Pokud nastavíte stejnou e-mailovou adresu pro běžného uživatele i uživatele HelpDesku, chování závisí na obecném nastavení HelpDesku:

• Pokud je vybrána možnost "Aktuálně přihlášený uživatel" - autor HelpDesku bude nastaven jako testovací uživatel HelpDesku.
• Pokud je vybrána možnost "Adresa schránky" - autor HelpDesku zůstane prázdný.

Samotný portál se po přihlášení skládá z domovské stránky, která byla nakonfigurována správcem, ale uživatelé HelpDesku ji nemohou sami konfigurovat. V pravém horním rohu je přístupný profil včetně režimu úprav. Vedle něj se nachází tlačítko pro odhlášení. Kliknutím na existující ticket nebo vytvořením nového ticketu bude uživatel přesměrován na detail ticketu, kde může přidat komentáře nebo přílohy. Pro návrat na domovskou stránku stačí kliknout na logo v levém horním rohu.

Uživatel HelpDesku nemá nastavené role a oprávnění a nelze mu poskytnout další přístup do určitých oblastí. Výše uvedený výpis je vše, k čemu mají přístup. Neměli byste jim posílat žádné odkazy na položky v aplikaci. Vedlo by to pouze ke zprávě o odepření přístupu.

9.3.1 Ověření LDAP pro uživatele HelpDesku

Od verze 11plus.2.0 mohou být uživatelé HelpDesku autentizováni prostřednictvím LDAP.

Konfigurace je v Administraci >> Pluginy >> Help desk >> Help desk uživatelé >> Upravit - Nový mód autentifikace.

Formulář je identický s běžnou konfigurací LDAP, pouze s tím rozdílem, že se vztahuje na uživatele HelpDesku => na stránce /helpdesk/login

9.4 Práce s tickety

Z pohledu klienta

Uživatel služby HelpDesk vytvoří ticket prostřednictvím formuláře Nový ticket na své domovské stránce. Jediné dostupné atributy jsou Předmět, Popis a přílohy. Filozofií je, že klienti by se neměli starat o organizační záležitosti, když potřebují pomoc od vaší zákaznické péče. Jednoduše uvedou svůj problém a očekávají jeho řešení. Žádný výběr projektu, žádné kategorie - to vše je v kompetenci vašeho týmu podpory.

ticket bude vytvořen v projektu, který je nastaven přímo na uživatele HelpDesku. Pole Email to v ticketu je vyplněno e-mailem uživatele HelpDesku. Tento uživatel bude také nastaven jako autor ticketu HelpDesk, což je skrytý atribut (nesouvisí s atributem Autor, který je obecným atributem všech úloh v Easy Projectu). Tím je zajištěno, že ticket uvidí vždy, i když jej přesunete do jiného projektu.

Podrobnosti ticketu viditelné pro uživatele služby HelpDesk:

• Předmět
• Popis
• Přílohy
• Stav
• ID
• Poslední aktualizace (čas a datum)
• Vytvořeno (čas a datum)
• Nesoukromé komentáře v historii

DŮLEŽITÉ: Omezené zobrazení ticketu pro uživatele HelpDesku je pod jinou adresou URL než běžné zobrazení ticketu. Například ticket č. 123 se uživateli HelpDesk zobrazí pod adresou URL /easy_helpdesk_issues/123. Běžný odkaz /issues/123 není uživatelům HelpDesku přístupný.

Aktualizace ticketu ze strany uživatele HelpDesku spočívá opět ve velmi jednoduchém přidání komentáře a/nebo přílohy.

Co se stane s tipem, když klient přidá komentář?

• Stav se automaticky mění podle nastavení v HelpDesk >> Nastavení HelpDesk - Změna stavu po odpovědi klienta na (vysvětleno v kapitole 7).
• Příznak Need reaction (Vyžaduje reakci) se nastaví automaticky (vysvětleno v kapitole 8)

Tato logika vycházela ze stávajícího chování komunikace ticket <--> e-mail, kdy klient pouze napíše e-mail a nestará se o to, jak je zpracován na straně systému HelpDesk. Pouze nyní má Klient přístup k ticketu a může si jej prohlédnout v čitelnější struktuře, místo aby jej dešifroval ve své e-mailové schránce.

Z pohledu provozovatele

S trochou zjednodušení bychom mohli říci, že pro operátora se při práci s tickety vlastně nic nemění. Měli bychom však nastínit, čeho by si měl být vědom.

Nejdůležitější je mít na paměti, že uživatelé služby HelpDesk mají omezený pohled na každý ticket. Tento omezený pohled se nachází pod adresou URL /easy_helpdesk_issues/123 => pro sdílení odkazu na ticket s uživateli služby HelpDesk nelze použít běžnou adresu URL (/issues). Tlačítko pro zkopírování odkazu na ticket HelpDesk je k dispozici v pravém horním rohu detailu ticketu (zvýrazněno na obrázku výše).

Nezapomeňte, že uživatel služby HelpDesk může vidět pouze nesoukromé komentáře. Pokud píšete komentář pro uživatele HelpDesku, nezapomeňte zrušit zaškrtnutí políčka soukromý.

Klient vidí všechny přílohy v ticketu, pokud potřebujete sdílet některé citlivé soubory se svými kolegy, nenahrávejte je do ticketu HelpDesk.

Jak upozornit klienta na vaši zprávu? Pro uživatele služby HelpDesk neexistují žádná pevně nastavená e-mailová oznámení. Chcete-li posílat e-maily uživatelům HelpDesku, stačí pokračovat v práci jako s tickety generovanými čistě e-mailem (kapitoly 5.1.2 a 5.1.3).

Jak sledovat tickety, na které reagovali uživatelé služby HelpDesk? Opět žádná změna, tickety jsou automaticky nastaveny do stavu na základě již existujícího nastavení. Současně je zapnuta funkce Need reaction (Vyžaduje reakci), takže by vám ticket rozhodně neměl uniknout.

A co právní příjemce? Příjemcem by měl být ten, kdo ticket aktuálně vyřizuje. ticket nelze přiřadit uživateli HelpDesku, protože, jak již bylo zmíněno, není běžným uživatelem. V podstatě se to neliší od běžných e-mailových ticketů, kde je autor anonymní a nepřiřazujete je zpět ke klientovi. Chcete-li informovat uživatele HelpDesku o ticketech, které byly zodpovězeny a případně potřebují nějaký vstup od Klienta, použijte jasně srozumitelný status.

9.4.1 Přiřaďte stávající tickety uživatelům HelpDesku

Příběh je velmi obvyklý: Už nějakou dobu používáte HelpDesk. Nyní upgradujete na verzi 11+ a rozhodnete se poskytnout svým klientům přístup coby uživatelům HelpDesku. Velkou otázkou je, jak jim umožnit přístup k jejich stávajícím ticketům?

Odpověď přichází s jednoduchým nástrojem, který propojí uživatele HelpDesku s již existujícími tickety. Funguje jednoduše:

1. Přejděte na seznam uživatelů HelpDesku
2. Klikněte na "Vyplnit autora HelpDesku"
   
3. Vyberte filtr – které úkoly mají být zpřístupněny
4. Vyberte uživatele HelpDesku
5. Potvrďte

V případě, že jste udělali chybu, je vždy možné odebrat přístup k těmto ticketům výběrem uživatele HelpDesku <<none>>.

9.5 Uživatelská pole na formuláři ticketu

Relevantní typy uživatelských polí (částka, ano/ne, datum, seznam klíč/hodnota, odkaz, seznam, seznam-závislý, text) mohou zobrazit nebo používat uživatelé HelpDesku. Nejprve se ujistěte, že jsou povolena uživatelská pole u projektů a typů úkolů používaných uživateli HelpDesku. V uživatelských polích úkolů jsou dvě možnosti:

• Viditelné pro uživatele HelpDesku – Obsah pole je zobrazen na detailu ticketu na HelpDesk portálu.
• Editovatelné pro uživatele HelpDesku – Uživatel HelpDesku může pole vyplnit při vytváření ticketu. Editace na stávajícím ticketu stále není možná, protože není úkolem zákazníků spravovat atributy ticketu.

9.6 Naše doporučení

Funkcí uživatelů HelpDesku lze nastavit poměrně hodně, proto bychom se s vámi rádi podělili o několik osvědčených postupů, kterými se můžete inspirovat.

Intuitivní pojmenování stavů ticketů

• zejména stav, ve kterém ticket předáváte Klientovi. Mělo by z něj být jasné, že tah je na jejich straně, pokud od nich potřebujete nějakou odpověď, nebo že je ticket předán a bude automaticky uzavřen a není třeba podnikat žádné kroky
• uživatel HelpDesku vidí stav, mělo by mu být jasné, co se s ticketem děje, a to i bez výslovného komentáře operátora

Udržujte domovskou stránku srozumitelnou pro uživatele HelpDesku

• je samozřejmé, že na stránku vložíte pouze jeden modul pro Nový ticket
• oddělte seznamy ticketů podle jejich použití. Příkladem může být oddělení otevřených a uzavřených ticketů do různých modulů. Dalším přístupem je oddělení ticketů, které vyžadují akci ze strany klienta, a ostatních (bez ohledu na stav otevřeno/uzavřeno). Jen to nepřehánějte s počtem různých seznamů-
• seznamy ticketů mají přizpůsobitelné nadpisy - využijte je ve prospěch svých klientů
• seznamy ticketů rozumně roztřiďte.

Přidání odkazu na ticket do e-mailových šablon

• pravděpodobně budete i nadále používat e-mailové šablony pro zasílání oznámení klientům o aktualizacích ticketu. Bude vhodné přidat k ticketu odkaz, pomocí kterého se k němu Klient dostane. Odkaz je ve tvaru: https://[your_application_URL]/easy_helpdesk_issues/%task_id_without_hash%
• pokud Klient na odkaz klikne a není přihlášen, bude přesměrován na stránku /helpdesk/login

Výkazy nad ticketem vytvořené uživateli HelpDesku?

• Na dashboardy (např. dashboard HelpDesku) můžete přidat seznam modulů, report, graf, trendy, obecný ukazatel, časové řady a vybrat entity HelpDesk ticketů pro různé typy reportů.

Nastavte jednu šablonu e-mailu jako výchozí

• jak je vysvětleno v kapitole 6.2.
• protože tickety vytvořené uživateli služby HelpDesk nejsou automaticky spojeny s poštovní schránkou, budou mít operátoři při odesílání e-mailu na výběr potenciálně mnoho šablon. Usnadněte jim to a nastavte jednu šablonu jako výchozí.

 

Okrajové případy

• V těchto případech se může stát, že uživatel, kterému je přiřazen úkol, není členem projektu:
  • uživatel byl odebrán z projektu, ale zůstaly mu přidělené úkoly
  • proces automatické aktualizace ticketů je v Helpdesk modulu nastaven tak, že některé tickety mohou být automaticky přiděleny i bývalým členům projektu.
• Informace o lhůtě SLA pro první odpověď se v detailu úkolu zobrazí pouze pokud je úkol ve výchozím stavu, který je definován v příslušném poli.
• Důrazně doporučujeme, abyste neměnili prioritu ticketu, když má ticket pozastavenou SLA, protože taková akce by nepříznivě ovlivnila správný výpočet SLA na daném tiketu.