Klíčové metriky helpdesku pro manažery podpory

Nejužitečnější reporty helpdesku propojují poptávku, rychlost, kvalitu a spolehlivost. Začněte s objemem tiketů, dobou do první odpovědi, dobou řešení, vyřešením při prvním kontaktu, plněním SLA, stářím nevyřízených tiketů, mírou znovuotevření, mírou eskalací, vytížením podle User, poměrem kanálů a náklady na tiket. Metriky spokojenosti zákazníků přidejte pouze tehdy, pokud máte spolehlivý proces průzkumu a dostatek odpovědí, které lze zodpovědně interpretovat.

Praktická frekvence reportování může vypadat takto:

Objem tiketů: denní přehled a týdenní trend
Doba do první odpovědi: denní trend a případně živé monitorování SLA
Doba řešení: denní trend a týdenní kontrola
Vyřešení při prvním kontaktu: týdně
Plnění SLA: denní provozní přehled a týdenní souhrn
Stáří nevyřízených tiketů: denně
Míra znovuotevření a eskalací: týdně
Vytížení podle User: denně pro vyrovnávání front
Poměr kanálů: týdně
Náklady na tiket: měsíčně

Nezačínejte tím, že budete sledovat všechno. Vyberte si malý soubor klíčových ukazatelů, ověřte, že podkladová časová razítka a pole jsou důvěryhodná, a podrobnosti přidávejte pouze tehdy, když někomu pomohou učinit rozhodnutí.

Klíčové závěry

Spolehlivé reportování helpdesku začíná čistými údaji o událostech, jasně definovanými vzorci a kontrolním procesem, který končí určením odpovědné osoby a konkrétního kroku.

Bod	Podrobnosti
Rozlišujte metriky a KPI	Metrika popisuje aktivitu. KPI je metrika s cílem, odpovědným vlastníkem a rozhodnutím, které je na ni navázáno.
Používejte rozložení, nejen průměry	Průměry doplňte mediány, percentily nebo časovými intervaly, aby malý počet pomalých tiketů nemohl zakrýt typickou zkušenost.
Benchmarky potřebují kontext	Před stanovením cílů zohledněte vlastní výchozí stav, poměr kanálů, složitost tiketů, personální obsazení a závazky úrovně služeb.
Kvalita dat je na prvním místě	Před zveřejněním výsledku definujte, které události spouštějí, pozastavují a ukončují jednotlivé časomíry.
Deskhero obsahuje pevně dané reportovací pohledy	Deskhero poskytuje provozní Dashboard a oblast Statistics s devíti pevně danými záložkami, filtry, zobrazením grafů a tabulek a exportem do Excelu na většině záložek.

Obsah

Jaký je rozdíl mezi metrikou helpdesku a KPI?
Hlavní metriky reportování helpdesku rozdělené podle účelu
Jak pro svůj tým nastavit realistické cíle a benchmarky
Jak navrhnout dashboardy, které bude každé publikum skutečně používat
Jak zajistit správnost dat před jejich reportováním
Úskalí reportování, kvůli nimž jsou vaše metriky zavádějící
Praktická šablona dashboardu, kterou můžete dnes zkopírovat
Kde se reportování skutečně vyplácí
Deskhero vám poskytne data připravená k reportování od prvního dne
Zdroje
Časté dotazy

Jaký je rozdíl mezi metrikou helpdesku a KPI?

Metrika je jakákoli naměřená hodnota, například počet vytvořených tiketů, medián doby do první odpovědi nebo počet otevřených tiketů. KPI je metrika vybraná k reprezentaci důležitého výsledku. Má definici, cíl nebo přijatelné rozmezí, vlastníka a reakci pro případ, že se výkonnost dostane mimo toto rozmezí.

Objem tiketů je obvykle diagnostická metrika. Popisuje poptávku, ale neříká, zda si tým vedl dobře. Plnění SLA pro první odpověď může být KPI, protože měří výkonnost vůči stanovenému závazku. I tehdy by se mělo posuzovat společně s údaji o kvalitě a vytížení.

Užitečné rozdělení je následující:

Diagnostické metriky: objem tiketů, poměr kanálů, poměr priorit, poměr kategorií a složení nevyřízených tiketů
Možné KPI: doba do první odpovědi, doba řešení, plnění SLA, vyřešení při prvním kontaktu, míra znovuotevření a spokojenost zákazníků

Zařazení závisí na tom, co se organizace snaží zlepšit. Nákladová metrika může být pro jeden tým podpory zásadní a pro jiný irelevantní. Ke každému KPI si napište zamýšlené rozhodnutí. Pokud nikdo nedokáže vysvětlit, jakou akci má změna vyvolat, metrika pravděpodobně patří spíše do diagnostického přehledu.

Tip profesionála: Každé KPI zdokumentujte jednou větou: vzorec, populaci, časové období, výjimky, vlastníka a cíl. Zabráníte tak tomu, aby dva týmy používaly stejný název pro odlišné výpočty.

Hlavní metriky reportování helpdesku rozdělené podle účelu

Metriky seskupujte podle otázky, na kterou odpovídají. Metriky poptávky popisují, co vstoupilo do fronty. Metriky efektivity ukazují, jak se práce posouvala. Metriky zkušenosti odrážejí zpětnou vazbu zákazníků. Metriky spolehlivosti ukazují, zda byly dodrženy závazky. Finanční metriky propojují činnost podpory s náklady.

Schéma metrik helpdesku rozdělených podle účelu

Metriky produktivity

Objem tiketů
Definice: Tikety vytvořené během reportovaného období.
Vzorec: Počet tiketů podle časového razítka vytvoření v rámci vybraného období.
Využití: Porovnávejte objem podle dne, kanálu, skupiny, priority a kategorie. Před změnou personálního obsazení prošetřete nárůsty.

Objem vyřešených tiketů
Definice: Tikety vyřešené během daného období.
Využití: Porovnávejte objem vytvořených a vyřešených tiketů za stejný interval. Pokud objem vytvořených tiketů opakovaně převyšuje objem vyřešených, nevyřízené tikety pravděpodobně narostou.

Vytížení podle User
Definice: Tikety přiřazené, zpracované nebo vyřešené jednotlivými User podle toho, na jakou otázku hledáte odpověď.
Využití: Vyvažujte fronty a identifikujte koncentraci práce. Nepřevádějte jediný počet vytíženosti na žebříček výkonnosti bez zohlednění složitosti, dostupnosti a kvality.

Rozdělení podle kanálů
Definice: Podíl tiketů vytvořených prostřednictvím jednotlivých kanálů.
Vzorec: Tikety z daného kanálu dělené všemi tikety v období.
Využití: Přizpůsobte personální obsazení a cíle úrovně služeb skutečné poptávce.

Metriky efektivity

Doba do první odpovědi
Definice: Čas od vytvoření tiketu do první kvalifikované lidské nebo automatické odpovědi podle vašich pravidel reportování.
Využití: Reportujte medián, 90. percentil a časové intervaly. Uveďte, zda časomíra používá kalendářní čas nebo pracovní hodiny a zda se započítávají automatická potvrzení.

Ruce nastavující ovládací kolečko pro dobu odpovědi

Doba řešení
Definice: Čas od vytvoření tiketu do jeho vyřešení.
Využití: Rozdělujte podle skupiny, priority, kategorie a stavu eskalace. Pokud se časomíra pozastavuje při čekání na zákazníka, toto pravidlo zdokumentujte.

Vyřešení při prvním kontaktu
Definice: Podíl způsobilých tiketů vyřešených během první interakce s podporou bez pozdějšího navazujícího kontaktu nebo znovuotevření ve zvoleném sledovaném období.
Využití: Před porovnáním období definujte sledované období a způsobilé kanály. Jednoduchý příznak nulového znovuotevření nemusí k určení vyřešení při prvním kontaktu vždy stačit.

Počet odpovědí do vyřešení
Definice: Počet vyměněných odpovědí před vyřešením.
Využití: Hledejte kategorie, které vytvářejí zbytečné dohadování tam a zpět. Nízký počet je užitečný pouze tehdy, když byl problém skutečně vyřešen.

Metriky zákaznické zkušenosti

Spokojenost zákazníků
Definice: Podíl nebo průměr odpovědí na definovaný průzkum po interakci.
Využití: Spolu s výsledkem vždy reportujte počet odpovědí a míru odpovědí. Procházejte písemné komentáře a pečlivě segmentujte, zejména když jsou velikosti vzorků malé.

Net Promoter Score
Definice: Procento promotérů minus procento kritiků z definovaného průzkumu doporučení.
Využití: Vnímejte jej jako širší měřítko vztahu, nikoli jako přímou náhradu spokojenosti na úrovni tiketů.

Míra znovuotevření
Definice: Vyřešené tikety znovuotevřené v definovaném období dělené způsobilými vyřešenými tikety.
Využití: Při změně míry kontrolujte kategorie, User a postupy uzavírání. Znovuotevření může znamenat neúplné vyřešení, ale může také odrážet situaci, kdy zákazník přidá nový problém do starého vlákna.

Metriky spolehlivosti a SLA

Plnění SLA
Definice: Dokončené časomíry odpovědi nebo řešení, které splnily příslušný cíl, dělené dokončenými časomírami v reportované populaci.
Využití: Plnění SLA udržujte oddělené od aktuálního počtu tiketů, kterým hrozí porušení SLA nebo u nichž již k porušení došlo. První hodnota je historický výsledek, zatímco druhá je provozní snímek.

Stáří nevyřízených tiketů
Definice: Rozložení stáří otevřených tiketů.
Využití: Zobrazujte věkové intervaly a nejstarší tikety. Zvolte hranice odpovídající vašim závazkům úrovně služeb, místo abyste uplatňovali jeden univerzální limit.

Míra eskalací
Definice: Tikety eskalované na jinou skupinu nebo specialistu dělené způsobilými tikety.
Využití: Segmentujte podle kategorie a priority. Eskalace může signalizovat mezeru ve znalostech, ale může být také správnou cestou pro složitou práci.

Finanční metriky

Náklady na tiket
Definice: Přidělené náklady podpory za období dělené způsobilými tikety zpracovanými v daném období.
Využití: Zdokumentujte, které mzdy, software, dodavatelé a režijní náklady zahrnujete. Porovnávejte srovnatelná období a podobné populace tiketů.

Náklady podle kanálu nebo kategorie
Definice: Přidělené náklady na kanál nebo kategorii dělené jejich způsobilým objemem tiketů.
Využití: Používejte pouze tehdy, když jsou časové a nákladové alokace dostatečně kvalitní pro podporu výpočtu. Falešná přesnost je horší než ponechat pole prázdné.

Jak pro svůj tým nastavit realistické cíle a benchmarky

Univerzální benchmarky helpdesku jsou jen zřídka skutečně univerzální. Cíl závisí na kanálu, provozní době, složitosti tiketů, prioritě, personálním obsazení a příslibu daném zákazníkům. Nejprve stanovte cíle podle vlastního provozu.

Definujte metriku. Zapište počáteční událost, koncovou událost, pozastavení, výjimky a způsobilou populaci.
Vytvořte výchozí stav. Použijte dostatečnou historii pokrývající běžné výkyvy. Porovnávejte medián a percentilové hodnoty, nejen průměry.
Segmentujte výchozí stav. Oddělte kanály, priority, skupiny a hlavní kategorie tiketů, pokud se jejich pracovní postupy liší.
Propojte cíl se závazkem. Cíle SLA by měly odpovídat příslibu úrovně služeb. Interní cíle zlepšování by měly být náročné, ale provozně realistické.
Cíl po změnách procesů znovu posuďte. Nové směrování, personální obsazení, automatizace nebo vydání produktu mohou změnit výchozí stav.

Metrika	Přístup ke stanovení cíle	Doporučená frekvence
Doba do první odpovědi	Stanovte podle kanálu, priority a závazku úrovně služeb	Denně
Doba řešení	Stanovte podle priority a kategorie tiketu	Denně a týdně
Vyřešení při prvním kontaktu	Vytvořte výchozí stav podle kategorie a definujte sledované období	Týdně
Spokojenost zákazníků	Stanovte až po pochopení objemu odpovědí a zkreslení	Týdně nebo měsíčně
Plnění SLA	Přizpůsobte zveřejněnému nebo smluvně dohodnutému závazku	Denně a týdně
Stáří nevyřízených tiketů	Používejte hranice navázané na prioritu a pravidla poskytování služeb	Denně
Míra znovuotevření	Vytvořte výchozí stav podle kategorie a pravidel uzavírání	Týdně
Náklady na tiket	Sledujte konzistentně definovaný interní trend	Měsíčně

Pokud má metrika malý vzorek nebo výrazné denní výkyvy, používejte klouzavá období. Pokud potřebujete identifikovat provozní změny, používejte porovnání období. V obou případech zobrazte počet způsobilých tiketů, aby čtenáři mohli posoudit stabilitu výsledku.

Jak navrhnout dashboardy, které bude každé publikum skutečně používat

Dashboard funguje, když každá karta odpovídá na otázku svého publika. Provozní přehledy by měly lidem pomáhat jednat okamžitě. Manažerské přehledy by měly vysvětlovat trendy a výjimky. Přehledy pro vedení by měly propojovat výsledky podpory se službami, riziky a náklady.

Mapování publika na metriky

User potřebují znát svou otevřenou práci, tikety čekající na první odpověď, časomíry SLA s blížícím se termínem nebo po jeho překročení a dostatek kontextu fronty pro výběr dalšího tiketu.

Ruce spravující položky pracovního prostoru a časovač

Vedoucí týmů potřebují objem vytvořených versus vyřešených tiketů, stáří nevyřízených tiketů, rozložení dob odpovědi, riziko SLA a vytížení podle User. Potřebují také odkazy na podrobné zobrazení tiketů, které se za daným číslem skrývají.

Manažeři podpory potřebují trendy podle skupiny, priority, kanálu a kategorie a také jasné definice každého KPI. Souhrnný přehled by měl vést k tabulce nebo grafu, který vysvětluje změnu.

Vedoucí pracovníci obvykle potřebují malý soubor ukazatelů služeb, kvality, rizik a nákladů. Zobrazte cíl, aktuální hodnotu, směr vývoje a krátké vysvětlení významných změn.

Doporučené widgety

Vytvořené versus vyřešené tikety: trendové čáry používající stejný interval
Rozložení doby do první odpovědi: medián, 90. percentil a časové intervaly
Trend doby řešení: segmentovaný podle priority nebo kategorie
SLA právě teď: aktuálně porušené, blížící se a pozastavené časomíry
Plnění SLA: dokončené časomíry, které v daném období splnily své cíle
Nevyřízené tikety podle stáří: počty otevřených tiketů v užitečných věkových intervalech
Tabulka vytížení: aktivita podle skupiny a User s relevantním kontextem
Rozdělení podle kanálů a témat: poměr poptávky a opakující se témata

Frekvence reportování

Živý provozní přehled: otevřené tikety, čekání na první odpověď a aktuální riziko SLA
Denní kontrola: objem, stáří nevyřízených tiketů, první odpověď, doba řešení a porušení SLA
Týdenní kontrola: trendy, výjimky, míra znovuotevření, míra eskalací a kroky ke zlepšení
Měsíční kontrola: výsledky služeb, náklady, kapacita a změny cílů

Každou schůzku propojte s rozhodnutími. Týdenní kontrola by měla skončit určením odpovědné osoby, termínu a metriky, která ukáže, zda změna fungovala.

Jak zajistit správnost dat před jejich reportováním

Metriky jsou spolehlivé pouze natolik, nakolik jsou spolehlivé definice jejich událostí. Před vytvořením dashboardu ověřte, že ticketový systém konzistentně zaznamenává události vytvoření, odpovědi, změny stavu, přiřazení a vyřešení.

Minimální schéma tiketu

Export pro reportování často potřebuje například tato pole:

ticket_id: stabilní identifikátor tiketu
created_at: časové razítko vytvoření tiketu
first_qualifying_response_at: časové razítko používané definicí první odpovědi
resolved_at: časové razítko vyřešení
assignee_id: aktuálně přiřazený User nebo User v okamžiku události, jasně označený
group_id: odpovědná skupina
channel: zdrojový kanál
priority: řízená hodnota priority
status: řízená hodnota stavu
tags: pokud možno řízené kategorie
sla_policy_id: příslušná politika, pokud je k dispozici
reopened_count: počet událostí znovuotevření

Ne každá platforma zpřístupňuje stejné schéma. Vnímejte tyto položky jako reportovací koncepty, nikoli jako tvrzení o přesných názvech polí. Pokud se hodnota může měnit, rozhodněte, zda report potřebuje aktuální hodnotu, nebo hodnotu v okamžiku události.

Označování a taxonomie

Pro kategorie, které ovlivňují personální obsazení, směrování nebo práci na zlepšování, používejte řízenou taxonomii. Seznam udržujte dostatečně malý, aby se používal konzistentně. Než začnete věřit trendům kategorií, kontrolujte nekategorizované tikety a téměř duplicitní štítky.

Automatizace může pomoci s přiřazováním polí, ale automatická klasifikace stále vyžaduje kontrolu. Sledujte neznámé výsledky nebo výsledky s nízkou mírou jistoty, místo abyste každý tiket násilně zařadili do zavádějící kategorie.

Kontrolní seznam instrumentace

[ ] Všechna časová razítka používají jeden uložený časový standard a zdokumentované zobrazované časové pásmo
[ ] Definice první odpovědi uvádí, zda se započítávají automatické odpovědi
[ ] Časomíry v pracovních a kalendářních hodinách se nemíchají
[ ] Pozastavené stavy jsou pro časomíry řešení zdokumentované
[ ] Události znovuotevření a eskalace mají explicitní definice
[ ] Aktuálně přiřazený User se nezaměňuje s User při vyřešení
[ ] Pro smazané, sloučené, spamové, testovací a importované tikety existuje stanovená politika zahrnutí
[ ] Každý výsledek zobrazuje počet způsobilých tiketů

Tip profesionála: Malý vzorek přepočítejte ručně. Pokud výsledek dashboardu nelze reprodukovat z událostí tiketů, opravte před stanovením cíle definici nebo data.

Úskalí reportování, kvůli nimž jsou vaše metriky zavádějící

Považování počtu tiketů za ukazatel výkonnosti. Objem měří poptávku. Než vyvodíte závěry o výkonnosti, doplňte jej o nevyřízené tikety, rychlost a kvalitu.
Reportování průměru bez rozložení. Průměry mohou skrývat dlouhé čekání. Přidejte medián, percentil nebo zobrazení v časových intervalech.
Řazení User pouze podle uzavřených tiketů. Počty ovlivňuje složitost tiketů, pracovní doba, přeřazování i kvalita. Tabulky vytížení používejte k vyvažování práce, nikoli jako samostatné hodnocení výkonnosti.
Míchání nesrovnatelných populací tiketů. Různé priority, kanály a kategorie často vyžadují různé cíle. Před porovnáním segmentujte.
Zaměňování aktuálního stavu SLA za historické plnění. Aktuálně porušený tiket je provozní problém. Dokončená časomíra, která nesplnila svůj cíl, patří do míry plnění. Tyto dvě populace nespojujte.
Ignorování změn jmenovatele. Procento se může změnit, protože se změnila způsobilá populace. Vždy zobrazte počet, který je jeho základem.
Vymýšlení přesnosti. Pokud jsou údaje o době zpracování, alokaci nákladů nebo pokrytí průzkumu neúplné, omezení označte nebo metriku vynechte.

Praktická šablona dashboardu, kterou můžete dnes zkopírovat

Níže uvedená šablona není vázaná na konkrétní platformu. Upravte názvy polí a vzorce podle svého datového modelu a každou úpravu následně zdokumentujte.

Schéma tabulky a vzorce

Název sloupce	Vzorec nebo zdroj	Poznámky
`ticket_id`	Ticketový systém	Stabilní klíč
`created_at`	Událost tiketu	Ukládejte v jednom časovém standardu
`first_response_at`	Událost první kvalifikované odpovědi	Zdokumentujte nakládání s automatickými odpověďmi
`resolved_at`	Událost vyřešení	Zdokumentujte nakládání se znovuotevřením
`frt_minutes`	Rozdíl mezi vytvořením a první odpovědí	Kalendářní nebo pracovní minuty
`resolution_minutes`	Rozdíl mezi vytvořením a vyřešením	V případě potřeby odečtěte zdokumentovaná pozastavení
`reopened_count`	Počet událostí znovuotevření	Zvolte sledované období
`sla_first_reply_met`	Výsledek časomíry SLA	Null, pokud není k dispozici příslušná dokončená časomíra
`sla_resolution_met`	Výsledek časomíry SLA	Null, pokud není k dispozici příslušná dokončená časomíra
`channel`	Zdroj tiketu	Řízená hodnota
`priority`	Pole tiketu	Řízená hodnota
`group_id`	Pole tiketu nebo historie událostí	Uveďte, zda jde o aktuální hodnotu, nebo hodnotu v okamžiku události

Ukázky SQL dotazů

Doba do první odpovědi v kalendářním čase v MySQL:

SELECT ticket_id,
       TIMESTAMPDIFF(MINUTE, created_at, first_response_at) AS frt_minutes
FROM tickets
WHERE first_response_at IS NOT NULL;

Vytvořené tikety podle aktuálně přiřazeného User a dne:

SELECT assignee_id,
       DATE(created_at) AS ticket_date,
       COUNT(*) AS tickets_created
FROM tickets
GROUP BY assignee_id, DATE(created_at)
ORDER BY ticket_date DESC, tickets_created DESC;

Plnění SLA pro první odpověď u dokončených tiketů:

SELECT
  AVG(CASE WHEN sla_first_reply_met = 1 THEN 1.0 ELSE 0.0 END) * 100 AS attainment_pct
FROM tickets
WHERE sla_first_reply_met IS NOT NULL
  AND created_at >= :period_start
  AND created_at < :period_end;

Tyto příklady používají zjednodušená pole a kalendářní čas. Produkční reportování musí uplatňovat stejná pravidla způsobilosti, pracovních hodin, pozastavení, slučování a mazání jako zdrojový systém.

Rozvržení záložek dashboardu

Provozní záložka: otevřená fronta, čekání na první odpověď, aktuální riziko SLA a nejstarší tikety
Manažerská záložka: trend vytvořených versus vyřešených tiketů, rozložení dob odpovědi, trend doby řešení, plnění SLA, stáří nevyřízených tiketů a tabulky vytížení
Výkonná záložka: vybraná KPI služeb, kvality, rizik a nákladů s cíli a krátkým komentářem

Tip profesionála: Vedle dashboardu udržujte slovník metrik. Změny vzorců a cílů verzujte, aby historické posuny zůstaly vysvětlitelné.

Kde se reportování skutečně vyplácí

Reportování se vyplácí tehdy, když mění řízení front, personální obsazení, směrování, dokumentaci nebo práci na produktu. Sofistikovaný graf, který nevede k žádnému rozhodnutí, je méně užitečný než jednoduchý přehled nevyřízených tiketů, jenž týmu pomůže vyřídit staré tikety.

Začněte jedním měřítkem poptávky, jedním měřítkem rychlosti, jedním měřítkem spolehlivosti nebo kvality a stářím nevyřízených tiketů. Posuzujte je společně. Pokud objem roste, zatímco doba odpovědi zůstává stabilní, tým možná disponuje kapacitou. Pokud objem vyřešených tiketů zaostává za objemem vytvořených a nevyřízené tikety stárnou, problém je viditelný dříve, než začne být alarmující jediný hlavní průměr.

Pomocí podrobného rozlišení přejděte od vzorce k tiketům, které za ním stojí. Nejlepší otázka při kontrole nezní jednoduše „Proč se číslo změnilo?“, ale „Které tikety změnu způsobily, co mají společného a co uděláme jinak?“

Deskhero vám poskytne data připravená k reportování od prvního dne

Deskhero mění propojené schránky Gmail, Google Workspace a Microsoft 365 na sdílené fronty tiketů. Přijímá také tikety z vložených formulářů a svého AI chat-botu založeného na FAQ.

Deskhero

Deskhero obsahuje provozní Dashboard s přehledy stavu tiketů, tikety čekajícími na první odpověď, trendy objemu tiketů, průměrnou dobou do první odpovědi, průměrnou dobou řešení a průměrnou dobou v jednotlivých stavech. Jeho oblast Statistics obsahuje devět pevných záložek pokrývajících přehled, trendy, doby odpovědí, SLA, tým, AI a automatizaci, kanály, statistiky témat a shluk témat.

Statistics lze filtrovat podle data a skupiny, přičemž na záložce SLA je k dispozici další filtr politiky. Karty grafů lze přepínat mezi zobrazením grafu a tabulky a většinu záložek lze exportovat do Excelu. Údaje se vztahují ke skupinám, k nimž má přihlášený User přístup, a obvykle se ukládají do mezipaměti přibližně na pět minut. Živý panel SLA je oddělený od historického plnění.

Deskhero neobsahuje nástroj pro tvorbu vlastních reportů. Pohledy témat mají také datové podmínky: shlukování témat vyžaduje přibližně 100 tiketů a pravidelně se znovu vytváří. K dispozici je 30denní bezplatná zkušební verze bez nutnosti zadat platební kartu.

Zdroje

Tato příručka využívá chování reportování zdokumentované v produktové implementaci Deskhero. Níže uvedené související příručky Deskhero poskytují další kontext k dashboardům a příjmu tiketů.

Časté dotazy

Jaké jsou klíčové metriky pro reportování service desku?

Začněte objemem tiketů, objemem vytvořených versus vyřešených tiketů, dobou do první odpovědi, dobou řešení, plněním SLA, stářím nevyřízených tiketů, mírou znovuotevření, mírou eskalací, vytížením podle User a poměrem kanálů. Metriky spokojenosti a nákladů přidejte, pokud jsou jejich zdrojová data spolehlivá.

Jaká KPI jsou vhodná pro IT helpdesk?

Doba do první odpovědi, doba řešení, plnění SLA, vyřešení při prvním kontaktu, míra znovuotevření a spokojenost zákazníků mohou být užitečnými KPI. Vyberte pouze metriky navázané na důležitý výsledek, jasný cíl a akci, kterou může tým provést.

Jak často byste měli posílat průzkumy CSAT?

Zvolte konzistentní spouštěč odpovídající cestě zákazníka, například po vyřešení způsobilého tiketu. Průzkum udržujte krátký, neposílejte opakované žádosti stejnému zákazníkovi a spolu s výsledkem reportujte počet odpovědí a míru odpovědí.

Jaká je dobrá míra vyřešení při prvním kontaktu?

Neexistuje jedna univerzálně užitečná míra pro každý tým. Definujte, co se počítá jako první kontakt, stanovte sledované období pro následné kontakty nebo znovuotevření, určete výchozí stav podle kategorie a kanálu a zlepšujte tuto hodnotu, aniž byste podporovali předčasné uzavírání.

Jak vypočítáte náklady na tiket?

Vydělte konzistentně alokované náklady podpory za období způsobilými tikety zpracovanými v daném období. Zdokumentujte, které náklady na práci, software, dodavatele a režii zahrnujete, a poté porovnávejte srovnatelná období a populace tiketů.

Klíčové metriky reportingu helpdesku pro manažery podpory