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 3 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

Jedná se o důležitou metriku všech podporových projektů, zásadní hlavně pro speciální klientské projekty, kde nedodržení smluvního SLA může být pokutováno. Jak jsme zmínili výše, tickety lze vytvářet z emailu nebo přímým zadáním do systému klienty se speciálním přístupem k podporovému projektu. Pro každý ze způsobů se SLA lehce liší.

4.2.1 SLA pro tickety generované z emailu

Detaily nastavení:

• Název - Název SLA (pro lepší správu SLA v podporovém projektu)
• Klíčové slovo - musí být vyplněno, pokud je SLA nastaveno pro tickety generované z emailů. Je potřeba zadat klíčové slovo, které pokud je obsaženo v předmětu emailu, pak jsou vytvořenému ticketu přiřazeny specifikace daného SLA (hodiny, priorita, typ úkolu). 
• Hodin do převzetí - lhůta, do které musí být provedena první změna stavu ticketu. Změna stavu indikuje, že ticket byl přijat a že o tom byl zákazník informován 
• Hodin do vyřešení - lhůta pro uzavření ticketu -> změna stavu na Uzavřen
• Priorita - nový ticket z emailu obsahující klíčové slovo bude mít nastavenou požadovanou prioritu
• Typ úkolu - novému ticketu z emailu, obsahujícímu nastavené klíčové slovo, bude nastaven zde vybraný typ. To je užitečné například pokud zákazník bude reklamovat vadný produkt a chce hlásit přímo závadu, nikoliv posílat ticket běžnou cestou jako dotaz na podporu. Může do předmětu zprávy zadat například Závada a ticket tak nemusí být označen ručně manažerem podpory.
• Počítat SLA podle pracovního času - SLA lhůty nebudou počítány během nepracovních dnů. Některá pravidla SLA mohou být omezena pouze na pracovní hodiny, některá mohou být nastavena na 24/7 režim. 
• SLA pracovní hodiny - časový rámec pro uplatňování SLA
• Pracovní dny - pracovní kalendář, kde jsou zaznamenány víkendy, svátky a ostatní nepracovní dny

4.2.2 Pořadí SLA podmínek

Čím více máte úrovní klíčových slov a slovních spojení pro klíčová slova, tím je důležitější nastavení jejich pořadí zpracování. Příchozí zprávy jsou zpracovávány a tříděny podle klíčových slov v předmětech a podle nastavení klíčových slov podporového projektu.

Příklad: Smluvně jste si nastavili klíčová slova "Kritická" a "Kritická chyba", každé z nich má vlastní odlišné SLA. Potřebujete zajistit, aby příchozí zprávy s těmito předměty byly od sebe rozlišovány při jejich zpracování.

Je tak potřeba nastavit jako hlavní klíčová slova "Kritická chyba", dát tomuto spojení přednost před samotným slovem "Kritická". Mechanismus zpracování podle předmětu zprávy je pak jednoduchý:

1. Hledej v předmětu zprávy "Kritická chyba"
2. Pokud předchozí spojení v předmětu zprávy není, hledej dál klíčové slovo "Kritická"
3. Pokud předchozí klíčové slovo v předmětu není, hledej další klíčová slova 
4. Poslední SLA musí mít obecné (blíže neurčené) klíčové slovo - použijte hvězdičku * pro ostatní obsah v předmětech zpráv 

Pokud zadáte v pořadí jako první "Kritická" a teprve potom "Kritická chyba", pak zprávy s předmětem "Kritická chyba" budou zpracovány nekorektně, to znamená že nejdříve budou zpracovány podle SLA určených slovem "Kritická". 

Obecně platí, že čím konkrétnější slovní spojení pro klíčová slova zadáte, musí být umístěna na prioritnější pozici pro zpracování. 

U zákaznického ticketu nebyly uplatněny a dodrženy SLA podmínky. Co máte dělat, abyste se ujistili, že máte takové případy pod kontrolou? V takových případech jděte do nastavení projektu -> Helpdesk -> skrolujte dolů na stránce

4.2.3 Reset SLA pro uzavřené tickety

Možnost nastavení najdete také vpravo nahoře u detailu SLA.

Pokud tuto volbu zaškrtnete, pro už uzavřené a znovu otevřené tickety (například další odpověď od zákazníka) se bude znovu počítat lhůta SLA, jako by byly nové - od doby přijaté odpovědi zákazníka, čímž se ticket znovu otevře.
Příklad: ticket #1234 byl otevřen v pondělí v 16 hodin. SLA je nastaveno na 48 hodin => čas na vyřešení je tak do středy do 16 hodin. ticket byl operátorem uzavřen v úterý v 10 hodin. Zákazník znovu odpověděl v úterý ve 14 hodin. ticketu #1234 nyní běží nová lhůta SLA do čtvrtka do 14 hodin. 

Není-li možnost zvolena, pak bude lhůta SLA vždy počítána od prvního času doručení, od založení ticketu. 

Příklad: Podle stejného scénáře z prvního příkladu - po odpovědi zákazníka v úterý ve 14 hodin nebude SLA počítána od znovuotevření ticketu, ale od původního času od středy 16 hodin. To samé se stane pokud zákazník znovu otevře ticket ve čtvrtek. ticket tak bude označen, že je po termínu.

Na posledním uvedeném příkladu je vidět, že tento způsob nastavení by měl být spíše jen pro takové projekty, kde jsou spíše jednoduché tickety a řešení je jasné a konečné, takže je zákazníci nemusí znovu otevírat.

4.2.4 SLA pro interně zadané tickety

Jak už jsme zmínili, tickety nemusí být vytvářeny jen na základě příchozích emailů. Easy Project má pokročilé úrovně přístupů, díky kterým mohou zákazníci získat přímý přístup do systému a vytvářet nové tickety, upravovat je, číst si novinky a podobně. 

tickety vytvořené přihlášenými uživateli  jako běžné úkoly mají trochu jiný způsob nastavení SLA podmínek. Vzhledem k tomu, že nejsou zpracovávány systémem jako emailové zprávy, nelze podmínit nastavení SLA podle klíčových slov. Pojďme si to vysvětlit na obrázku.

Při tvorbě SLA pro interně vytvořené tickety ponechte pole pro klíčová slova prázdné. SLA podmínky budou určeny na základě kombinace Priority a Typu úkolu. Po uložení nastavení se položka pro klíčová slova už nezobrazí, což určuje právě použití těchto SLA pro interně zadávané tickety. Pokud ponecháte volné pole pro Typ úkolu, budou brány v potaz jen klíčová slova. 

Efektivním nastavením pracovního procesu můžete nasměrovat zákazníky k tomu, aby zadávali interně jen určené typy úkolů, i když v projektu je povoleno více typů. Můžete například povolit zadání pouze typů Helpdesk úkol a chyba, takže si můžete nastavit SLA jen pro tyto typy. U všech ostatních typů úkolů nebude požadováno SLA nastavení, protože je nelze zadat interně zákazníkem.

4.2.5 SLA Events a Reporty

SLA Reporty jsou založeny na individuálních SLA eventech (událostech). Tyto události si můžete zobrazit pro každý podporový ticket, jednoduše se podívejte do záložky SLA Event v dolním menu u každého ticketu. Pokud je ticket zodpovězen nebo vyřešen, můžete u něj vidět SLA Event, kde je kromě ostatních detailů vidět, za jak dlouho bylo odpovězeno (v hodinách), a tento údaj porovnat s hodnotou SLA - tedy zda byla předepsaná lhůta dodržena. Dále vždy vidíte, kdo a kdy odpovídal nebo ticket řešil a do kterého projektu ticket patří. Časové záznamy jsou zobrazovány se symboly + nebo - (plus, mínus), respektive zelenou a červenou barvou (podle toho, zda byla lhůta SLA dodržena). 

SLA event je založen jen pokud bylo na podporový ticket odpovězeno zákazníkovi, před odpovědí je záznam prázdný. Přidání komentáře k ticketu není v SLA Event zobrazeno, protože nelze rozlišit, zda je komentář pouze interní poznámkou nebo odpovědí zákazníkovi.

Když je ticket podpory přesunut z jednoho projektu do druhého, SLA event se nepřepočítá. SLA ticketu zůstává z původního projektu, kde byl tento ticket vytvořen. Přepočet SLA je spuštěn pouze změnou typu úkolu nebo priority.

Pro zobrazení seznamu (přehledu) všech SLA Events najdete na adrese /easy_sla_events nebo klikněte na volbu SLA Report v nabídce bočního menu na hlavní stránce Helpdesku (/easy_helpdesk).

SLA Events lze také jednoduše filtrovat podle konkrétních nastavených SLA, podle uživatelských polí a jiných kritérií.

Všechny SLA Eventy zařazené v celkových statistikách najdete na dashboardu SLA reportů. Ve výchozím nastavení je tento dashboard dostupný v horním menu hlavní stránky Helpdesku. Na tomto dashboardu vždy najdete celkové procento nedodržených SLA lhůt odpovědí, řešení a průměrnou dobu první reakce na tickety. Dashboard lze personalizovat jako mnoho ostatních stránek, takže si podle vlastních potřeb můžete nechat zobrazovat všechny dostupné moduly, jak vám bude vyhovovat. 

4.2.6 SLA reporty nad tickety

Kromě výše uvedeného je též možné dělat SLA reporty nad tickety.

Od verze 11plus.2.0 mají tickety dvě nová pole:

• Plnění doby první reakce - bráno podle prvního SLA eventu na ticketu
• Plnění doby vyřešení - bráno podle posledního SLA eventu na ticketu

Jak to funguje

Ticket je vytvořen -> Operátor HelpDesku odpovídá-> SLA event je vytvořen -> hodnoty z tohoto SLA eventu se zkopírují do výše uvedených atributů ticketu -> klient odpoví zpět -> operátor odpovídá klientovi -> je vytvořen nový SLA event -> hodnota plnění vyřešení dle SLA je zkopírovaná do atributu ticketu.

Co je přínosem této funkce

Vzhledem k tomu, že ticket sám o sobě obsahuje nejdůležitější data pro SLA reporting, můžete vytvářet reporty o spokojenosti s SLA přímo nad tickety.
Některé příklady:

• Úspěšnost plnění SLA vyřešených tiketů
• Spojnicový graf absolutního počtu ticketů s neúspěšnou odpovědí/vyřešením ve lhůtě SLA

 

4.2.7 Skrytí SLA detailů

Informace o lhůtách SLA pro první reakci a pro vyřešení v detailu úkolu lze skrýt pro vybrané typy uživatelů (Administrace -> Typy uživatelů -> Aktualizovat).

Tyto údaje také mohou být skryty jen konkrétním vybraným uživatelům (Administrace >> Uživatelé >> Aktualizovat).

V takovém případě daný uživatel hodnoty SLA neuvidí, dokud mu nebude povoleno jedno ze zmíněných nastavení. 

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 - Obsah zprávy, pouze text. Obrázky se nezobrazují přímo v tomto přehledu, kvůli optimalizaci výkonu (zejména pokud je historie zprávy obsáhlá, a každá zpráva obsahuje znovu logo v podpisu, ticket by se zbytečně dlouho načítal)
• Kompletní zpráva je dostupná v příloze - pokud původní zpráva obsahuje obrázky, vidíte je jako samostatné přílohy.  
  

5.1.2 Napište odpověď a aktualizujte ticket

Pro dodržení lhůty SLA pro první odpověď je potřeba změnit stav ticketu a poslat zákazníkovi první reakci. 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. Po uzavření ticketu už nebude dostupná možnost resetu SLA lhůty. 

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.

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.

Pokud zaškrtnete políčko „Odeslat okamžitě“, bude při každé změně stavu úkolu odesláno e-mailové oznámení. Doporučujeme nastavit pracovní postup tak, aby se úkol nemohl vrátit do stavu dvakrát.

Detaily nastavení:

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

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.