Deskhero
Čeština
Vyzkoušet zdarma

← Back to articles

Metriky reportingu helpdesku, které by měli manažeři podpory sledovat

Metriky reportingu helpdesku, které by měli manažeři podpory sledovat

Základní metriky helpdeskového reportingu zahrnují objem tiketů, dobu do první odpovědi, průměrnou dobu řešení (MTTR), vyřešení při prvním kontaktu (FCR), CSAT, plnění SLA, nevyřízené tikety a jejich stáří, míru znovuotevření, míru eskalací, využití Uživatelů, náklady na tiket a objem podle kanálů. Sledujte je společně jako jednu sadu, nikoli jako nabídku, ze které si vyberete, protože izolování jediného čísla vede ke špatně nastaveným motivacím: zaměřte se pouze na rychlost a míra znovuotevření vzroste; zaměřte se pouze na CSAT a náklady na tiket mohou stoupnout.

Smyslem zobrazení metrik helpdeskového reportingu na jednom místě je pokrýt čtyři oblasti najednou: efektivitu, kvalitu, pracovní zatížení a náklady. Pokud jednu vynecháte, řídíte tým jen na základě neúplného obrazu.

Zde je seznam, který můžete ještě dnes umístit na dashboard:

  • Objem tiketů: celkový objem i objem podle kanálů, aby počet pracovníků odpovídal poptávce
  • Doba do první odpovědi (FRT): jak dlouho zákazníci čekají na první věcnou odpověď
  • MTTR: medián doby řešení rozdělený podle priority
  • FCR: procento tiketů vyřešených bez eskalace nebo následné komunikace
  • CSAT: skóre spokojenosti po vyřešení tiketu
  • Plnění SLA: procento tiketů splňujících cíle pro odpověď a vyřešení
  • Nevyřízené tikety a jejich stáří: otevřené tikety seskupené podle doby čekání
  • Míra znovuotevření: tikety uzavřené a následně znovuotevřené v určeném časovém okně
  • Míra eskalací: procento tiketů předaných na úroveň 2 nebo vyšší
  • Využití Uživatelů: aktivní pracovní čas ve srovnání s dostupnou kapacitou
  • Náklady na tiket: celkové náklady na podporu vydělené objemem tiketů
  • Objem podle kanálů: rozdělení na e-mail, chat, telefon a samoobsluhu

Váš další krok: vytvořte jednostránkový týdenní dashboard zobrazující objem tiketů, FRT, MTTR, CSAT a stáří nevyřízených tiketů. Je to nejrychlejší způsob, jak během patnácti minut zjistit, zda se týden nevyvíjel špatným směrem.

Hlavní závěry

Helpdeskový reporting funguje tehdy, když manažeři sledují metriky efektivity, kvality, pracovního zatížení a nákladů společně, místo aby optimalizovali jediné číslo izolovaně.

Konstatování Podrobnosti
Sledujte celou sadu Kombinujte FRT, MTTR, FCR, CSAT, plnění SLA, stáří nevyřízených tiketů, míru znovuotevření, míru eskalací, využití a náklady na tiket.
Propojte FCR s mírou znovuotevření Samotné vysoké FCR může skrývat předčasné uzavírání; míra znovuotevření odhalí to, co FCR nezachytí.
Vytvářejte dashboardy pro konkrétní cílové skupiny Vedoucí pracovníci potřebují trendy a náklady; manažeři potřebují přehled o zatížení a rizicích; Uživatelé potřebují vlastní frontu.
Pro provoz používejte data v reálném čase, pro strategii historická data Hloubka fronty a časovače SLA řídí rozhodnutí během dne; trendová data řídí nábor a změny procesů.
Automatizujte datový tok Deskhero sjednocuje tikety z e-mailu, formulářů a svého AI chatbota v jednom systému a poskytuje pevně dané pohledy Statistics s exporty do Excelu.

Obsah

Co jsou metriky a KPI helpdeskového reportingu?

Metrika je jakékoli číslo, které měříte. KPI je metrika navázaná na cíl, která vám říká, zda je výkonnost přijatelná. Objem tiketů je metrika; „vyřešit 90 % tiketů do 8 pracovních hodin“ je KPI postavené na metrice.

Metriky helpdeskového reportingu obecně spadají do čtyř skupin. Když víte, do které skupiny se díváte, nepřikládáte nepřiměřenou váhu jediné dimenzi:

  • Metriky produktivity: objem tiketů, využití Uživatelů, počet tiketů uzavřených jedním Uživatelem za den
  • Metriky efektivity: doba do první odpovědi, MTTR, doba do první odpovědi podle kanálu
  • Metriky kvality: CSAT, FCR, míra znovuotevření, skóre kontroly kvality
  • Nákladové metriky: náklady na tiket, náklady na vyřešený problém, přesčasové hodiny související s nárůstem nevyřízených tiketů

Nejčastější chybou týmů je výběr metrik podle toho, že je nástroj náhodou reportuje, nikoli podle toho, zda odpovídají obchodnímu cíli. Pokud vedení záleží na udržení zákazníků, mohou být CSAT a míra znovuotevření důležitější než samotný počet tiketů. Pokud vedení řeší plánování počtu pracovníků, mohou být důležitější objem tiketů a využití Uživatelů než CSAT. Začněte rozhodnutím, které potřebujete učinit, a poté vyberte metriku, která vám ho pomůže informovat.

14 základních helpdeskových metrik: definice, vzorce a opatření

Každá z těchto metrik slouží jako nástroj pro manažera, nikoli jako tabulka výsledků. Zde se dozvíte, co jednotlivé metriky znamenají, jak je vypočítat, jak je rozdělit a co skutečně dělat, když se jejich hodnota změní.

Objem tiketů. Celkový počet tiketů přijatých za určité období. Vzorec: počet nových tiketů rozdělený podle kanálu, priority a kategorie. Pokud objem vzroste bez odpovídající změny produktu, hledejte chybu, výpadek nebo marketingovou kampaň, která přivádí návštěvnost. Trvalý růst objemu bez růstu počtu pracovníků je nejčasnějším varovným signálem problémů s nevyřízenými tikety.

Objem podle kanálů. Objem tiketů rozdělený podle zdroje přijetí: e-mail, vložené webové formuláře, chat a telefon. Ukazuje, kam investovat do odklonu požadavků. Pokud se objem chatu ztrojnásobí a zároveň zaostává kvalita řešení, jde o nedostatek školení, nikoli pracovníků.

Doba do první odpovědi (FRT). Čas od vytvoření tiketu do první věcné odpovědi Uživatele. Vzorec: součet (časové razítko první odpovědi minus časové razítko vytvoření) vydělený počtem tiketů. Rozdělte podle kanálu a priority. FRT je užitečná, protože měří první čekání, které zákazník zažije. Když FRT začne růst, před volbou řešení prověřte směrování, počet pracovníků a poptávku. Automatická potvrzení by měla být měřena odděleně od věcných odpovědí. AI automatické odpovědi Deskhero se započítávají jako první odpověď a jsou identifikovány odděleně od odpovědí lidí.

Průměrná doba řešení (MTTR). Průměrný nebo mediánový čas od vytvoření do vyřešení. Vzorec: součet (resolved_at minus created_at) vydělený počtem vyřešených tiketů. Pokud vícedenní odlehlé hodnoty zkreslují průměr, používejte vedle průměru také medián. Rozdělte podle priority a kategorie. Rostoucí MTTR u tiketů s nízkou prioritou při stabilní hodnotě u urgentních tiketů může ukazovat na problém s tříděním nebo kapacitou.

Vyřešení při prvním kontaktu (FCR). Procento tiketů uzavřených v rámci jediné interakce bez následné komunikace nebo eskalace. Vzorec: počet tiketů vyřešených při prvním kontaktu dělený celkovým počtem tiketů krát 100. FCR a míru znovuotevření vždy čtěte společně. Vysoké FCR s rostoucí mírou znovuotevření může znamenat, že Uživatelé tikety uzavírají předčasně.

CSAT. Skóre spokojenosti po vyřešení, obvykle hodnocení od 1 do 5 spojené se závěrečným průzkumem. Vzorec: počet spokojených odpovědí dělený celkovým počtem odpovědí krát 100. Rozdělte podle Uživatele, kategorie a kanálu. Pokles CSAT v jedné kategorii, například u fakturace, při stabilním celkovém CSAT může odhalit, kde je zapotřebí koučování nebo revize procesu.

NPS nebo CES, pokud je sledujete. Net Promoter Score měří loajalitu; Customer Effort Score měří, jak náročná interakce působila. Ani jedno nenahrazuje CSAT, ale zejména CES je užitečný pro identifikaci tření v samoobslužných procesech ještě předtím, než zákazníci vůbec vytvoří tiket.

Plnění SLA. Procento tiketů splňujících smluvní lhůty pro odpověď a vyřešení. Vzorec: počet tiketů v rámci SLA dělený celkovým počtem tiketů krát 100. Rozdělte podle úrovně priority, protože jediné souhrnné číslo SLA může skrýt skutečnost, že u urgentních tiketů SLA selhává, zatímco u tiketů s nízkou prioritou vypadá vše dobře.

Nevyřízené tikety a jejich stáří. Počet otevřených tiketů seskupených do věkových kategorií (0 až 24 hodin, 1 až 3 dny, více než 3 dny). Rostoucí počet starších tiketů může signalizovat problém s kapacitou nebo pracovním postupem dříve, než dojde k nesplnění cíle SLA.

Míra znovuotevření. Procento vyřešených tiketů znovuotevřených v definovaném časovém okně, obvykle do 48 hodin. Vzorec: počet znovuotevřených tiketů dělený počtem vyřešených tiketů krát 100. Propojení míry znovuotevření s FCR pomáhá odhalit, zda rychlejší uzavírání není na úkor trvalého vyřešení.

Míra eskalací. Procento tiketů předaných mimo první úroveň. Vzorec: počet eskalovaných tiketů dělený celkovým počtem tiketů krát 100. Rostoucí eskalace při stabilním objemu tiketů může signalizovat nedostatek znalostí, problém se směrováním nebo změnu složitosti tiketů.

Využití Uživatelů. Aktivní pracovní čas dělený naplánovaným dostupným časem. Vzorec: čas strávený na tiketech dělený naplánovanými hodinami krát 100. Trvalé nadměrné vytížení může zvýšit riziko vyhoření, proto toto číslo vyhodnocujte společně s pracovním zatížením a absencemi.

Náklady na tiket. Celkové náklady na podporu (mzdy, nástroje a režie) dělené objemem tiketů za dané období. Manažerům a finančnímu oddělení poskytují společný způsob, jak hovořit o nákladech na podporu.

Skóre kontroly kvality. Ruční nebo AI podporované hodnocení přepisů tiketů podle hodnoticího rámce, které zahrnuje tón, přesnost a dodržování zásad. Kontrola kvality může doplnit kontext, který průzkumy spokojenosti nezachytí, zejména při nízkém počtu odpovědí na průzkum.

Metrika Vzorec Hlavní cílová skupina
Objem tiketů Počet nových tiketů za období Manažer, vedoucí pracovník
Doba do první odpovědi Součet (čas první odpovědi − čas vytvoření) / počet tiketů Uživatel, manažer
MTTR Medián (čas vyřešení − čas vytvoření) Manažer, vedoucí pracovník
FCR Vyřešení při prvním kontaktu / celkový počet tiketů × 100 Manažer
CSAT Spokojené odpovědi / celkový počet odpovědí × 100 Manažer, vedoucí pracovník
Plnění SLA Tikety v rámci SLA / celkový počet tiketů × 100 Manažer, vedoucí pracovník
Stáří nevyřízených tiketů Otevřené tikety seskupené podle věkové kategorie Manažer, Uživatel
Míra znovuotevření Znovuotevřené tikety / vyřešené tikety × 100 Manažer
Míra eskalací Eskalované tikety / celkový počet tiketů × 100 Manažer
Využití Uživatelů Aktivní pracovní čas / naplánovaný čas × 100 Manažer
Náklady na tiket Celkové náklady na podporu / objem tiketů Vedoucí pracovník
Skóre kontroly kvality Vážené skóre podle hodnoticího rámce za tiket Manažer, Uživatel

Úplný rozbor toho, jak se tyto definice uplatňují u týmů různých velikostí, najdete v článku základní metriky helpdeskového reportingu pro manažery podpory.

Jak by se měly dashboardy lišit pro vedoucí pracovníky, manažery a Uživatele?

Vedoucí pracovníci potřebují trendy a náklady. Manažeři potřebují přehled o zatížení a rizicích. Uživatelé potřebují soustředěný pohled na vlastní frontu. Jeden dashboard obvykle nedokáže dobře obsloužit všechny tři skupiny, proto začněte rozhodnutími, která musí jednotlivé skupiny učinit.

Widgety pro vedoucí pracovníky: trend CSAT za 12 měsíců, celkové plnění SLA s porovnáním měsíc na měsíc, náklady na tiket, objem tiketů v porovnání s počtem pracovníků a krátký seznam nejrizikovějších položek získaný z eskalací.

Widgety pro manažery: aktuální počet otevřených tiketů podle priority a fronty, plnění SLA podle kategorie, rozložení pracovního zatížení Uživatelů, trend FCR, míra eskalací, rozložení stáří nevyřízených tiketů a průběžné průměry kontroly kvality.

Widgety pro Uživatele: vlastní otevřené tikety, hloubka přiřazené fronty, blížící se termíny SLA a relevantní odkazy na znalostní databázi.

Tip: Udržujte každý dashboard zaměřený. Namísto přidávání dalších dlaždic používejte odkazy na podrobné rozpracování a odstraňte widgety, které nevedou k opakovanému rozhodování.

Frekvence aktualizací je stejně důležitá jako výběr widgetů. Hloubka fronty, termíny SLA a přiřazení Uživatelů vyžadují aktuální data, protože řídí rozhodnutí během dne. Trendy CSAT, náklady na tiket a průměry kontroly kvality lze aktualizovat denně nebo týdně, protože informují o rozhodnutích s dopadem v delším období. Aktuální provozní data pomáhají manažerům odhalit přetížené fronty a přerozdělit práci dříve, než začnou termíny sklouzávat.

Jak by se měly dashboardy lišit pro vedoucí pracovníky, manažery a Uživatele? Přehledový diagram

Reporting v reálném čase vs. historický reporting: který potřebujete?

Reporting v reálném čase řídí provozní rozhodnutí přijímaná v daném okamžiku; historický reporting řídí strategická rozhodnutí přijímaná v průběhu týdnů nebo čtvrtletí. Záměna těchto dvou typů vede k tomu, že týmy sledují živý dashboard během rozhovoru o náboru nebo vytahují čtvrtletní report při rozhodování, kdo pokryje odpolední směnu.

Účel Frekvence aktualizace Časový horizont Klíčové metriky Cílová skupina
Provozní (směrování, personální zajištění) V reálném čase až každou hodinu Stejný den Hloubka fronty, termíny SLA, stav Uživatele Manažer, Uživatel
Strategický (nábor, procesy) Denně až měsíčně Týdny až čtvrtletí Trend MTTR, trend CSAT, náklady na tiket Manažer, vedoucí pracovník

Provozní dashboardy by měly řídit rozhodnutí o směrování a personálním zajištění, zatímco historické reporty jsou vhodným nástrojem pro rozhodování o náboru, investicích do školení a změnách procesů. Smíchání obou typů pouze vytváří hlučné, reaktivní řízení.

Z hlediska dat vyřeší většinu problémů s reportingem tři návyky: sjednoťte před reportingem všechny zdroje tiketů do jednoho systému; ověřte, že časová razítka stavů odpovídají realitě; a automatizujte opakované exporty, pokud vestavěný report nestačí. Tiket označený jako „vyřešený“ několik dní po skutečném odstranění problému zákazníka zkreslí MTTR bez ohledu na reportingový nástroj.

Při výběru nástroje obvykle rozhoduje, kde se vaše data již nacházejí. Power BI často dobře zapadá do prostředí založených na nástrojích Microsoftu, zatímco Tableau se běžně používá ke kombinování několika zdrojů. Ať už zvolíte kterýkoli nástroj, ujistěte se, že váš export nebo API obsahuje ID tiketu, časová razítka relevantních změn stavu, prioritu, kategorii, přiřazeného Uživatele a kanál. Přesná pole ověřte podle výpočtů, které bude váš dashboard používat.

Jak nastavit realistické cíle SLA a CSAT?

Cíle nastavte tak, že nejprve změříte výchozí stav, porovnáte ho s referenční hodnotou srovnatelného týmu a poté rozvrhnete zlepšení do stanoveného období, místo abyste rovnou stanovili libovolné „špičkové“ číslo.

  1. Změřte současný výchozí stav každé metriky nejméně za čtyři až šest týdnů, aby se vyrovnal dopad jednoho špatného týdne.
  2. Vyberte pásmo referenčních hodnot z oborových zdrojů nebo srovnatelných týmů a upravte ho podle svého modelu podpory (helpdesk B2B SaaS a vysokobjemový e-commerce tým by neměly mít stejný cíl MTTR).
  3. Nastavte postupný cíl s časovým plánem, například zvýšit plnění SLA z 82 % na 90 % během dvou čtvrtletí namísto požadavku na 95 % již příští měsíc.
  4. Propojte cíle s plánováním kapacity, aby cíle zlepšení doprovázely investice do personálu nebo automatizace potřebné k jejich dosažení, nikoli pouze příkaz.

U každého KPI zdokumentujte definici, zdroj dat, výchozí stav, cíl a datum kontroly. Benchmarkové reporty mohou poskytnout kontext, ale váš cíl by měl zohledňovat kanál, závažnost, příslib zákazníkovi, provozní dobu a dostupnou kapacitu.

Jakým chybám v reportingu by se měli manažeři vyhnout?

Nejčastějšími chybami jsou honba za povrchními metrikami, reporting průměrů namísto percentilů, odměňování rychlosti bez kontroly kvality a oddělené fungování dashboardů jednotlivých týmů.

  • Sledování průměrných namísto percentilových časů skrývá nejhorší případy. Uvádějte mediánový a 90. percentil MTTR vedle sebe.
  • Odměňování samotné rychlosti (rychlé uzavírání, vysoké FCR) bez sledování míry znovuotevření může Uživatele motivovat k uzavírání tiketů dříve, než je problém skutečně vyřešen.
  • Ignorování míry znovuotevření vytváří mezeru v kvalitě; přidejte ji, pokud ji váš ticketovací nástroj standardně nezobrazuje.
  • Stejné zacházení se všemi kanály skrývá skutečnost, že chat a e-mail mají zcela odlišná očekávání FRT.
  • Špatná hygiena dat (duplicitní tikety, nesprávně označená priorita) nenápadně narušuje všechny navazující metriky; kontrolujte štítky tiketů čtvrtletně.

Co patří do týdenního reportu a co do měsíčního?

Týdenní reporty pokrývají provozní stav; měsíční reporty pokrývají trendy a dopad na podnikání.

  1. Objem tiketů a rozdělení podle kanálů za daný týden
  2. FRT, MTTR, CSAT a FCR ve srovnání s cílem
  3. Plnění SLA rozdělené podle kategorií
  4. Pět nejčastějších kategorií tiketů podle objemu
  5. Rozložení pracovního zatížení Uživatelů a případné signály nedostatečné kapacity
  6. Jeden odstavec shrnující hlavní příběh týdne

V měsíčním reportu pro vedení uveďte meziměsíční a meziroční trendy CSAT, plnění SLA a nákladů na tiket, počet pracovníků v porovnání s poptávkou, krátkou poznámku o spuštěných iniciativách a jejich měřitelném dopadu a případná výhledová rizika, například sezónní nárůsty objemu.

Použitelná narativní věta může znít: „Objem tento týden po chybě ve fakturaci vzrostl o 14 %, plnění SLA u urgentních tiketů kleslo na 84 % a doporučujeme dočasné posílení kapacity, dokud nebude oprava nasazena.“ Čísla jsou ilustrativní, ale struktura poskytuje čtenáři změnu, příčinu, důsledek a opatření. Připravené šablony najdete v šablonách dashboardů zákaznické podpory Deskhero.

Jak tyto metriky skutečně vypočítat z nezpracovaných dat?

Přesný výpočet závisí více než na kterémkoli vzorci na jediné věci: konzistentních časových razítkách stavů a jasné, společně odsouhlasené definici pojmů „vyřešený“ a „uzavřený“. Pokud polovina týmu označuje tiket jako vyřešený při nasazení opravy a druhá polovina až po potvrzení zákazníkem, váš MTTR porovnává dvě různé věci.

  1. FRT = first_response_at − created_at, zprůměrované nebo vyjádřené mediánem za období
  2. MTTR = resolved_at − created_at, vyjádřené mediánem a rozdělené podle priority
  3. FCR = (tikety s nulovým počtem přeřazení a znovuotevření) / celkový počet tiketů
  4. Míra znovuotevření = tikety znovuotevřené do 48 hodin / vyřešené tikety
  5. Využití Uživatelů = time_spent / scheduled_hours
  6. Plnění SLA = tikety splňující SLA / celkový počet tiketů

Požadovaná nezpracovaná pole: ID tiketu, created_at, first_response_at, resolved_at, closed_at, protokol změn stavu, priorita, fronta, přiřazený Uživatel, time_spent a nákladové středisko.

Jednoduchý dotaz pro FRT a MTTR v určitém rozsahu dat může vypadat takto:

SELECT AVG(first_response_at - created_at) AS avg_frt,
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY resolved_at - created_at) AS median_mttr
FROM tickets
WHERE created_at BETWEEN :start_date AND :end_date;

Berte to jako výchozí podobu a syntaxi i pravidla pro časová razítka přizpůsobte své databázi. Než výsledek použijete v dashboardu, ověřte ho na malé sadě známých tiketů.

Jak se mají metriky IT podpory lišit od metrik zákaznického servisu?

IT podpora a podpora orientovaná na zákazníky měří úspěch odlišně, přestože obě fungují na frontách tiketů. Metriky IT podpory se více zaměřují na MTTR, míru eskalací a plnění SLA navázané na závažnost incidentu, protože náklady na výpadek výrazně převyšují náklady na poněkud pomalejší odpověď. Tiket k výpadku P1 potřebuje jiné hodiny SLA a jinou eskalační cestu než požadavek na reset hesla. Smíchání obou do jednoho čísla MTTR zakrývá obojí.

Zákaznický servis a e-commerce podpora naopak mohou klást větší váhu na CSAT, FCR a objem podle kanálů, protože dopad na podnikání se projevuje v udržení zákazníků a opakovaných nákupech, nikoli v dostupnosti systému. Obchodník na Shopify, který řeší dotazy na stav objednávky, může více zajímat FRT v zákaznických kanálech než MTTR u vzácné technické eskalace. Integrace Shopify Deskhero přidává do odpovídajících tiketů aktuální kontext zákazníka, objednávky, vyřízení a sledování zásilky, zatímco katalog produktů může pomáhat s návrhy odpovědí AI.

Řešením není vybrat jednu sadu metrik na úkor druhé. Pokud váš tým obsluhuje oba typy podpory, rozdělte dashboard podle modelu podpory, aby interní IT fronta a zákaznická fronta měly samostatné úrovně SLA, pravidla eskalací a referenční cíle namísto jednoho smíšeného čísla, které dobře nevyhovuje ani jedné.

Mohou analýza trendů a prognózy zlepšit plánování helpdesku?

Analýza trendů mění statickou metriku v plánovací nástroj a prognózy vám umožní zajistit kapacitu předem podle očekávané poptávky, místo abyste na ni reagovali. Stabilní číslo CSAT vám řekne, kde jste dnes; dvanáctiměsíční trend CSAT ukáže, zda změna procesu z minulého čtvrtletí skutečně fungovala.

Nejpraktičtějším využitím je prognózování objemu. Pokud objem tiketů spolehlivě vzroste každý listopad kvůli cyklu uvedení produktu na trh, zakreslení tohoto sezónního vzorce proti počtu pracovníků vám umožní požádat o dočasné posílení kapacity s předstihem. Stejná logika platí pro míru eskalací: její trvalý růst může vést k šetření ještě před zhoršením plnění SLA.

Analytika podpory může plnit dvě odlišné úlohy: udržovat frontu v dobrém stavu každý den a analyzovat obsah tiketů s cílem najít opakující se témata, která poslouží produktovým týmům a týmům zákaznické zkušenosti. Sledujte provozní výkonnost i opakující se témata, aby reportingový program podporoval více než jen správu fronty.

Proč tato sada metrik funguje pro moderní helpdesky

Nejčastější chybou, kterou vídám, není výběr špatných metrik. Je to výběr dobrých metrik v izolaci. Tým, který reportuje FCR bez míry znovuotevření, vypadá na papíře skvěle až do chvíle, kdy zákazníci začnou podávat stejnou stížnost podruhé. Propojení čísel efektivity s kontrolou kvality skutečně chrání helpdesk před optimalizací, která vede ke zhoršení služeb.

Toto seskupení efektivity, kvality, pracovního zatížení a nákladů funguje, protože odpovídá tomu, jak se skutečně přijímají rozhodnutí o personálním zajištění a produktu. Nenabíráte zaměstnance pouze podle CSAT ani nesměrujete tikety pouze podle nákladů na tiket. Potřebujete celou sadu a každý týden ji číst společně.

Použijte tyto reportingové postupy ve svém helpdesku

Ruční vytváření reportů z oddělených exportů e-mailů a formulářů vytváří zbytečnou práci. Deskhero promění schránku Gmail nebo Microsoft 365 v helpdesk a ukládá e-mailové tikety, tikety z vložených formulářů i tikety z AI chatbota v jednom systému. Jeho Dashboard zobrazuje objem tiketů, průměrnou dobu do první odpovědi, průměrnou dobu řešení a čas strávený v jednotlivých stavech. Pevně daná část Statistics přidává trendy, percentily doby odpovědi, SLA, týmové, kanálové, AI a tematické pohledy s filtry a exporty do Excelu pro jednotlivé karty.

Deskhero

Tikety vytvořené e-mailem, vloženým webovým formulářem nebo vestavěným AI chatbotem se dostanou do jedné sdílené schránky. Návrhy odpovědí AI mohou využívat širší znalostní fond pracovního prostoru, zatímco odpovědi chatbota určené zákazníkům a AI automatické odpovědi používají pouze schválené veřejné FAQ. Vícejazyčná podpora pomáhá Uživatelům překládat tikety a odpovědi. Cluster Topics zvýrazňuje opakující se témata, zatímco exporty Statistics a REST API poskytují cesty k další analýze. Deskhero neobsahuje nástroj pro tvorbu vlastních reportů, takže týmy, které potřebují dashboard na míru, by měly použít exportovaná data nebo data dostupná přes API v nástroji BI.

Pokud přepracováváte svůj reportingový proces, můžete začít 30denní bezplatnou zkušební verzi bez nutnosti zadávat platební kartu a prozkoumat pohledy Dashboard a Statistics v Deskhero.

Použijte tyto reportingové postupy ve svém helpdesku. Přehledový diagram

Zdroje

Tyto zdroje podporují referenční hodnoty, pravidla návrhu dashboardů a doporučení k nástrojům uvedená výše a každý z nich jde podrobněji do konkrétní části celkového obrazu.

Časté dotazy

Jaké jsou klíčové metriky pro reporting service desku?

Základní sada zahrnuje objem tiketů, dobu do první odpovědi, MTTR, FCR, CSAT, plnění SLA, stáří nevyřízených tiketů, míru znovuotevření, míru eskalací, využití Uživatelů a náklady na tiket. Tyto metriky se sledují společně, nikoli po jedné.

Jakých je 5 klíčových metrik CX?

Většina týmů staví reporting CX na CSAT, FCR, době do první odpovědi, míře znovuotevření a plnění SLA, protože těchto pět metrik spojuje rychlost, kvalitu a spolehlivost do jediného srozumitelného obrazu.

Jaké jsou příklady KPI pro IT helpdesk?

KPI IT helpdesku obvykle zahrnují MTTR podle úrovně závažnosti, plnění SLA u incidentů P1, míru eskalací a stáří nevyřízených tiketů, protože IT podpora přikládá závažnosti incidentu větší váhu než obecný zákaznický servis.

Jaké jsou dobré KPI pro IT oddělení?

Kromě metrik na úrovni tiketů sledují IT oddělení často náklady na tiket, využití Uživatelů a vyřešení při prvním kontaktu, aby vyvážila kvalitu služeb s náklady na zaměstnance a kapacitou.

Jak často by měly helpdeskové reporty vznikat?

Provozní widgety, jako je hloubka fronty a termíny SLA, potřebují aktuální data, zatímco trendové metriky, jako CSAT a náklady na tiket, lze často sledovat v týdenním nebo měsíčním intervalu.

Dokáže helpdesková platforma, jako je Deskhero, tento reporting automatizovat?

Deskhero zachycuje tikety z e-mailu, webových formulářů a svého AI chatbota v jednom systému. Jeho pevně dané karty Statistics pokrývají trendy, doby odpovědí, SLA, Uživatele, kanály, AI a témata a nabízejí filtry i exporty do Excelu pro jednotlivé karty. Pro týmy, které potřebují další analýzu, je k dispozici také REST API.