Help Desk

Terminologie
Rozvržení struktury podporových projektů
Napojení emailové schránky do Easy8
Nastavení projektu
Konfigurace projektu - detaily
Zpracování ticketů
Emailové šablony
Obecné nastavení
Filtr "Vyžaduje reakci"
Uživatelé služby HelpDesk
Řešení potíží: Nedoručení e-mailu s velkými přílohami
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 Easy8, 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 Easy8, 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 Easy8 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 Easy8 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 Easy8

Nyní se můžeme pustit do nastavení jednotlivých součástí Helpdesku. Aby se v Easy8 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 Easy8 dokáže spojit s emailovou schránkou. 

Detaily nastavení:

• Aktivní - nepřečtené zprávy jsou z emailové schránky Easy8 vybírány pravidelně. Pokud tuto volbu nezaškrtnete, schránka nebude vybírána. Můžete si ale nastavenou schránku nechat v Easy8 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 Easy8, 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 Easy8 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 Easy8 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 Easy8.

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ě Easy8.

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 Easy8 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 Easy8 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 Easy8 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.

Tyto SLA údaje lze zobrazit v seznamu úkolů pro reportování. Doba trvání a Zbývající čas pro Response SLA a Resolution SLA se zobrazí na dashboardech (filtry 1.0) až po splnění SLA pro Response SLA a až po uzavření úkolu pro Resolution SLA.

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 Easy8 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 Easy8 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 Easy8. 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

Uživatelé HelpDesku zjednodušují správu přístupu klientů k vašemu Easy8. Klienti díky nim mohou zadávat tickety a komunikovat s vašimi operátory přímo v aplikaci, bez přístupu ke zbytku Easy8.

9.1 Předpoklady

Správa uživatelů HelpDesku se řídí oprávněními Zobrazit uživatele help desku a Spravovat uživatele help desku v sekci HelpDesk v části Administrace » Role a práva.

Každý uživatel HelpDesku patří do pracovního prostoru (workspace). Pracovní prostor určuje:

• Projekty – projekty HelpDesku, ve kterých mohou uživatelé vytvářet tickety.
• Typy úkolů – typy úkolů, které mohou uživatelé používat.
• Šablonu dashboardu – domovskou stránku, kterou uživatelé uvidí po přihlášení.

Pracovní prostory vytvoříte v Administrace » Helpdesk → Help desk pracovní prostory → Nový pracovní prostor help desku. Šablony dashboardů pro uživatele HelpDesku spravujete v Administrace » Přizpůsobení stránek. Zajistěte, aby každý pracovní prostor měl šablonu – jinak jeho uživatelé uvidí po přihlášení prázdnou stránku.

Domovská stránka uživatele HelpDesku může obsahovat tyto moduly:

• Formulář pro nový ticket – nemá žádné nastavení, stačí ho umístit tam, kde je to pro klienty nejpohodlnější.
• Tickety HelpDesku – seznam ticketů uživatele HelpDesku. Dá se nastavit jako ostatní moduly seznamů a obsahuje pole viditelná pro uživatele HelpDesku. Pokud chcete zobrazovat otevřené i uzavřené tickety, doporučujeme je dát do samostatných modulů.
• Nástěnka – pro sdílení vlastních informací s klienty.
• Trendy, Grafy, Nový úkol ze šablony a Tlačítko workflow.

9.2 Správa uživatelů HelpDesku

Uživatele HelpDesku spravujete v Administrace » Helpdesk, kde v postranním panelu kliknete na Help desk uživatelé. Nového uživatele vytvoříte tlačítkem Nový help desk uživatel.

Informace (všechna pole kromě Jazyka jsou povinná):

• Jméno
• Příjmení
• Workspace – pracovní prostor; určuje projekty, typy úkolů a domovskou stránku uživatele (viz 9.1).
• Email = Login – touto e-mailovou adresou se uživatel přihlašuje.
• Jazyk

Další práva:

• View all tasks – uživatel vidí tickety ve svých projektech vytvořené jinými uživateli HelpDesku. Nedává přístup k úkolům mimo HelpDesk.
• Manage all tasks – uživatel může upravovat tickety ve svých projektech vytvořené jinými uživateli HelpDesku (Předmět, Popis a přidávání nových příloh, ne však úpravu stávajících).

Upozornění: Tato oprávnění používejte jen tehdy, když projekt slouží jedinému klientovi. Jinak by jeden klient mohl vidět nebo upravovat tickety jiného klienta.

Příklad využití: Klient má ve vašem HelpDesku vlastní projekt pro své tickety. Za tohoto klienta zadává tickety na portálu HelpDesku víc uživatelů. Jeden z nich potřebuje vidět všechny odeslané tickety, protože hodnotí služby, které poskytujete.

Autentifikace: Při vytváření uživatele zadejte Password a Password confirmation, nebo zaškrtněte Generovat přístupový kód, aby si uživatel nastavil vlastní heslo přes odkaz v e-mailu. Generování přístupového kódu funguje jen tehdy, když je v nastavení povolené obnovení hesla. Při úpravě existujícího uživatele heslo měnit nemusíte.

9.2.1 Import CSV

Uživatele HelpDesku můžete importovat ze souboru CSV. Ohledně této možnosti se 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 stejnou přihlašovací stránku jako běžní uživatelé (/login). Jako přihlašovací jméno používají svou e-mailovou adresu. Samostatná přihlašovací stránka pro HelpDesk už neexistuje – původní adresa /helpdesk/login přesměruje na hlavní přihlašovací stránku.

DŮLEŽITÉ: Uživatelé HelpDesku a běžní uživatelé jsou oddělené účty. Protože se přihlašují na stejné stránce, Easy8 nedovolí použít stejnou e-mailovou adresu ani přihlašovací jméno pro běžného uživatele a uživatele HelpDesku. U každé osoby se proto rozhodněte, jestli potřebuje účet uživatele HelpDesku, nebo plnohodnotný účet.

Po přihlášení uživatel HelpDesku vidí svou domovskou stránku, kterou nastavuje správce a uživatel ji sám měnit nemůže. V pravém horním rohu může otevřít a upravit svůj profil a odhlásit se. Když otevře existující ticket nebo vytvoří nový, zobrazí se mu detail ticketu, kde může přidávat komentáře a přílohy. Na domovskou stránku se vrátí kliknutím na logo v levém horním rohu.

Uživatelé HelpDesku nemají role ani nastavení oprávnění a nelze jim zpřístupnit další části aplikace. Neposílejte jim odkazy na jiné položky v aplikaci – zobrazila by se jim jen zpráva o odepření přístupu.

9.3.1 Módy autentifikace: dvoufaktorové ověřování a LDAP

Ověřování uživatelů HelpDesku nastavíte v Administrace » Helpdesk → Help desk uživatelé, kde v postranním panelu kliknete na Módy autentifikace.

• Dvoufaktorové ověřování pro help desk uživatele – vyberte Vypnuto, Volitelné nebo Povinné pro všechny uživatele help desku. Při volbě Povinné si uživatelé musí dvoufaktorové ověření nastavit při příštím přihlášení. Při volbě Vypnuto se všechna existující spárování odstraní.
• Nový mód autentifikace – připojení serveru LDAP pro uživatele HelpDesku. Formulář je stejný jako u běžné konfigurace LDAP, platí ale jen pro uživatele HelpDesku. Se zapnutou volbou Automatické vytváření uživatelů se uživatel HelpDesku vytvoří automaticky při prvním přihlášení.

9.4 Práce s tickety

Z pohledu klienta

Uživatel HelpDesku vytvoří ticket přes formulář Nový ticket na své domovské stránce. Formulář obsahuje jen to, co klient potřebuje k popisu problému, například Předmět, Popis a Přílohy. Klienti se nemusí starat o organizační záležitosti – jen popíšou svůj problém a o zbytek se postará váš tým podpory.

Ticket se vytvoří v projektu z pracovního prostoru uživatele. Pole Email to v ticketu se vyplní e-mailem uživatele HelpDesku. Tento uživatel se zároveň nastaví jako autor HelpDesku, což je jiné pole než obecný Autor úkolu. Díky tomu ticket uvidí vždy, i když ho přesunete do jiného projektu.

Podrobnosti ticketu viditelné pro uživatele HelpDesku:

• 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 HelpDesku zobrazí pod adresou /easy_helpdesk_issues/123. Běžný odkaz /issues/123 není uživatelům HelpDesku přístupný.

Uživatel HelpDesku ticket aktualizuje jednoduše – přidá komentář nebo přílohu.

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

• Stav se automaticky změní podle nastavení Změna stavu po odpovědi klienta na v nastavení HelpDesku (viz kapitola 7).
• Automaticky se nastaví příznak Need reaction (Vyžaduje reakci) (viz kapitola 8).

Funguje to stejně jako komunikace mezi ticketem a e-mailem, kdy klient jen pošle e-mail a nestará se o to, jak ho HelpDesk zpracuje. Rozdíl je v tom, že klient vidí ticket v přehledné podobě a nemusí si ho skládat ze zpráv ve své schránce.

Z pohledu operátora

Pro operátora se při práci s tickety mnoho nemění. Mějte ale na paměti tyto body:

• Uživatelé HelpDesku mají omezený pohled na ticket pod adresou /easy_helpdesk_issues/123, takže jim nemůžete posílat běžný odkaz /issues. Použijte tlačítko pro zkopírování odkazu na ticket HelpDesku v pravém horním rohu detailu ticketu (zvýrazněné na obrázku výše).
• Uživatelé HelpDesku vidí jen nesoukromé komentáře. Když píšete komentář pro uživatele HelpDesku, zkontrolujte, že není zaškrtnuté políčko Soukromý.
• Klient vidí všechny přílohy v ticketu. Citlivé soubory určené jen kolegům do ticketu HelpDesku nenahrávejte.
• Pro uživatele HelpDesku neexistují automatická e-mailová oznámení. E-maily jim posílejte stejně jako u ticketů vytvořených e-mailem (kapitoly 5.1.2 a 5.1.3).
• Tickety, na které uživatelé HelpDesku reagovali, se nastaví do stavu podle existujícího nastavení a zapne se Need reaction, takže vám neuniknou.
• Ticket nelze přiřadit uživateli HelpDesku, protože to není běžný uživatel. Řešitelem by měl být ten, kdo ticket právě vyřizuje. Uživatelům HelpDesku dávejte najevo, které tickety jsou vyřešené nebo čekají na jejich vstup, pomocí srozumitelných stavů.

9.4.1 Přiřazení stávajících ticketů uživatelům HelpDesku

Pokud HelpDesk už nějakou dobu používáte a teď chcete klientům dát přístup jako uživatelům HelpDesku, můžete je propojit s jejich stávajícími tickety:

1. Přejděte do Administrace » Helpdesk → Help desk uživatelé.
2. V postranním panelu klikněte na Vyplnit autory tiketů.
3. Nastavte filtr pro tickety, které chcete zpřístupnit. Pokud nefiltrujete podle stavu, aktualizují se jen otevřené tickety.
4. Vyberte uživatele HelpDesku.
5. Potvrďte.

Upozornění: V autorizovaném projektu uživatel HelpDesku uvidí všechny tickety z filtru včetně jejich obsahu. Pokud už ticket autora HelpDesku má, bude nahrazen.

Pokud uděláte chybu, můžete přístup k těmto ticketům odebrat 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, závislý seznam, text) mohou uživatelé HelpDesku vidět nebo používat. Nejprve zkontrolujte, že jsou uživatelská pole povolená u projektů a typů úkolů, které uživatelé HelpDesku používají. Uživatelská pole úkolů mají dvě možnosti:

• Viditelné pro uživatele HelpDesku – obsah pole se zobrazí v detailu ticketu na portálu HelpDesku.
• Editovatelné pro uživatele HelpDesku – uživatel HelpDesku může pole vyplnit při vytváření ticketu. Úprava existujících ticketů možná není, protože správa atributů ticketu není úkolem zákazníka.

9.6 Naše doporučení

Uživatele HelpDesku lze hodně přizpůsobit. Tady je několik osvědčených postupů pro inspiraci.

Pojmenujte stavy ticketů srozumitelně

• Zejména stav, ve kterém ticket předáváte zpět klientovi. Mělo by být jasné, jestli je tah na jeho straně, nebo je ticket vyřešený a automaticky se uzavře.
• Uživatel HelpDesku vidí stav, takže by mělo být jasné, co se s ticketem děje, i bez komentáře operátora.

Udržujte domovskou stránku uživatelů HelpDesku jednoduchou

• Na stránku dejte jen jeden modul Nový ticket.
• Oddělte seznamy ticketů podle účelu – například otevřené a uzavřené tickety, nebo tickety, které vyžadují akci klienta, a ostatní. Nepřehánějte to s počtem seznamů.
• Využijte přizpůsobitelné nadpisy seznamů ticketů ve prospěch klientů.
• Seznamy ticketů rozumně uspořádejte.

Přidejte odkaz na ticket do e-mailových šablon

• Pro oznámení klientům o aktualizacích ticketu budete pravděpodobně dál používat e-mailové šablony. Odkaz na ticket jim usnadní ho otevřít. Odkaz má tvar https://[your_application_URL]/easy_helpdesk_issues/%task_id_without_hash%.
• Pokud klient na odkaz klikne a není přihlášený, nejdřív se mu zobrazí přihlašovací stránka.

Výkazy nad tickety vytvořenými uživateli HelpDesku

• Na nástěnky (například nástěnku HelpDesku) můžete přidat seznamy, reporty, grafy, trendy, obecné ukazatele a časové řady a vybrat pro ně entity ticketů HelpDesku.

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

• Viz kapitola 6.2.
• Tickety vytvořené uživateli HelpDesku nejsou automaticky propojené s poštovní schránkou, takže operátoři mohou mít při odesílání e-mailu na výběr mnoho šablon. Usnadněte jim práci a nastavte jednu šablonu jako výchozí.

Řešení potíží: Nedoručení e-mailu s velkými přílohami

K tomuto problému dochází, když odchozí e-maily s velkými přílohami (např. 20 MB) nejsou doručeny. Obvykle je to způsobeno limity na straně serveru (Nginx, Postfix nebo poštovní server příjemce), nikoli aplikací Easy8. Tyto limity mohou zabránit přijetí e-mailu, i když se v aplikaci nezobrazí žádná chyba.

Časté příčiny

– Příloha překračuje limity aplikace
– Příliš malý limit požadavku v Nginx (client_max_body_size)
– Nízký limit velikosti zprávy v Postfixu (message_size_limit)
– Poštovní server příjemce odmítá velké zprávy
– Limity infrastruktury u spravovaných serverů

Jak postupovat

Zkontrolujte nastavení příloh v aplikaci
Ujistěte se, že maximální povolená velikost přílohy je dostatečná.

Ověřte konfiguraci Nginx
Zvyšte hodnotu client_max_body_size (např. na 50M).

Zkontrolujte konfiguraci Postfix
Upravte message_size_limit (výchozí cca 10 MB) na vyšší hodnotu.
Příklad: message_size_limit = 52428800 (50 MB).

Zkontrolujte logy poštovního serveru
Hledejte chyby jako queue file size limit exceeded nebo message size exceeds limit.

Ověřte limity na straně příjemce
I když váš server velké zprávy povoluje, příjemcův server je může odmítnout.

Doporučení

– Informujte uživatele o maximální velikosti příloh
– Pro velmi velké soubory použijte cloudové úložiště (Google Drive, OneDrive, Dropbox)
– Komprimujte nebo rozdělte soubory před odesláním
– Dokumentujte všechny provedené změny konfigurace

 

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.