De vigtigste helpdesk-målinger for supportledere

De mest nyttige helpdesk-rapporter forbinder efterspørgsel, hastighed, kvalitet og pålidelighed. Start med antal tickets, tid til første svar, løsningstid, løsning ved første kontakt, SLA-opfyldelse, backlogens alder, genåbningsrate, eskaleringsrate, arbejdsbelastning pr. User, kanalmix og pris pr. ticket. Tilføj kun kundetilfredshedsmålinger, når du har en pålidelig undersøgelsesproces og tilstrækkeligt mange svar til at fortolke dem ansvarligt.
En praktisk rapporteringsrytme kan se sådan ud:
- Antal tickets: dagligt øjebliksbillede og ugentlig tendens
- Tid til første svar: daglig tendens samt live SLA-overvågning, hvor det er relevant
- Løsningstid: daglig tendens og ugentlig gennemgang
- Løsning ved første kontakt: ugentligt
- SLA-opfyldelse: dagligt operationelt overblik og ugentlig opsummering
- Backlogens alder: dagligt
- Genåbnings- og eskaleringsrater: ugentligt
- Arbejdsbelastning pr. User: dagligt for at balancere køen
- Kanalmix: ugentligt
- Pris pr. ticket: månedligt
Start ikke med at spore alt. Vælg et lille scorecard, bekræft, at de underliggende tidsstempler og felter er pålidelige, og tilføj kun detaljer, når de hjælper nogen med at træffe en beslutning.
Vigtigste pointer
Pålidelig helpdesk-rapportering begynder med rene hændelsesdata, klart definerede formler og en gennemgangsproces, der slutter med en ansvarlig ejer og en handling.
| Punkt | Detaljer |
|---|---|
| Adskil målinger fra KPI'er | En måling beskriver aktivitet. En KPI er en måling med et mål, en ansvarlig ejer og en beslutning knyttet til sig. |
| Brug fordelinger, ikke kun gennemsnit | Kombinér gennemsnit med medianer, percentiler eller tidsintervaller, så et lille antal langsomme tickets ikke kan skjule den typiske oplevelse. |
| Benchmarks kræver kontekst | Brug din egen baseline, dit kanalmix, ticketkompleksitet, bemanding og serviceforpligtelser, før du fastsætter mål. |
| Datakvalitet kommer først | Definér, hvilke hændelser der starter, sætter på pause og afslutter hvert ur, før du offentliggør en score. |
| Deskhero omfatter faste rapporteringsvisninger | Deskhero tilbyder et operationelt Dashboard og et Statistics-område med ni faste faner, filtre, diagram- og tabelvisninger samt Excel-eksport på de fleste faner. |
Indholdsfortegnelse
- Hvad er forskellen på en helpdesk-måling og en KPI?
- De vigtigste helpdesk-rapporteringsmålinger grupperet efter formål
- Sådan fastsætter du realistiske mål og benchmarks for dit team
- Sådan designer du dashboards, som hver målgruppe rent faktisk vil bruge
- Få styr på dine data, før du rapporterer om dem
- Rapporteringsfælder, der gør dine målinger misvisende
- En dashboard-skabelon, der er klar til brug, og som du kan kopiere i dag
- Hvor rapportering faktisk giver værdi
- Deskhero giver dig rapporteringsklare data fra dag ét
- Kilder
- FAQ
Hvad er forskellen på en helpdesk-måling og en KPI?
En måling er enhver værdi, der bliver målt, såsom oprettede tickets, median tid til første svar eller antallet af åbne tickets. En KPI er en måling, der er udvalgt til at repræsentere et vigtigt resultat. Den har en definition, et mål eller et acceptabelt interval, en ejer og en reaktion, når resultatet bevæger sig uden for dette interval.
Antallet af tickets er normalt en diagnostisk måling. Den beskriver efterspørgslen, men siger ikke, om teamet præsterede godt. Opfyldelse af SLA for første svar kan være en KPI, fordi den måler præstationen i forhold til en fastlagt forpligtelse. Selv da bør den læses sammen med data om kvalitet og arbejdsbelastning.
En nyttig opdeling er:
- Diagnostiske målinger: antal tickets, kanalmix, prioritetsmix, kategorimix og backlog-sammensætning
- Mulige KPI'er: tid til første svar, løsningstid, SLA-opfyldelse, løsning ved første kontakt, genåbningsrate og kundetilfredshed
Klassificeringen afhænger af, hvad organisationen forsøger at forbedre. En omkostningsmåling kan være central i én supportorganisation og irrelevant i en anden. Skriv den tilsigtede beslutning ved siden af hver KPI. Hvis ingen kan forklare, hvilken handling en ændring bør udløse, hører målingen sandsynligvis hjemme i en diagnostisk visning i stedet.
Pro tip: Dokumentér hver KPI i én sætning: formel, population, tidsperiode, undtagelser, ejer og mål. Det forhindrer, at to teams bruger den samme betegnelse for forskellige beregninger.
De vigtigste helpdesk-rapporteringsmålinger grupperet efter formål
Gruppér målinger efter det spørgsmål, de besvarer. Efterspørgselsmålinger beskriver, hvad der kom ind i køen. Effektivitetsmålinger viser, hvordan arbejdet bevægede sig. Oplevelsesmålinger afspejler kundefeedback. Pålidelighedsmålinger viser, om forpligtelser blev overholdt. Økonomiske målinger forbinder supportaktivitet med omkostninger.

Produktivitetsmålinger
Antal tickets
Definition: Tickets oprettet i en rapporteringsperiode.
Formel: Tæl tickets efter oprettelsestidsstempel inden for den valgte periode.
Anvendelse: Sammenlign antal tickets efter dag, kanal, gruppe, prioritet og kategori. Undersøg stigninger, før du ændrer bemandingen.
Antal løste tickets
Definition: Tickets, der blev løst i perioden.
Anvendelse: Sammenlign oprettede og løste tickets over det samme interval. Hvis antallet af oprettede tickets gentagne gange overstiger antallet af løste tickets, vil backloggen sandsynligvis vokse.
Arbejdsbelastning pr. User
Definition: Tickets, der er tildelt, håndteret eller løst af hver User, afhængigt af spørgsmålet.
Anvendelse: Balancér køer og identificér koncentrationer af arbejde. Gør ikke én optælling af arbejdsbelastning til en præstationsrangliste uden at tage højde for kompleksitet, tilgængelighed og kvalitet.
Kanalfordeling
Definition: Andelen af tickets, der blev oprettet via hver kanal.
Formel: Tickets fra en kanal divideret med alle tickets i perioden.
Anvendelse: Tilpas bemanding og servicemål efter den faktiske efterspørgsel.
Effektivitetsmålinger
Tid til første svar
Definition: Tiden fra oprettelse af en ticket til det første kvalificerende menneskelige eller automatiserede svar i henhold til din rapporteringspolitik.
Anvendelse: Rapportér medianen, den 90. percentil og tidsintervaller. Angiv, om uret bruger kalendertid eller åbningstid, og om automatiske kvitteringer tæller med.

Løsningstid
Definition: Tiden fra oprettelse af en ticket til løsning.
Anvendelse: Opdel efter gruppe, prioritet, kategori og eskaleringsstatus. Hvis uret sættes på pause, mens man venter på kunden, skal denne regel dokumenteres.
Løsning ved første kontakt
Definition: Andelen af kvalificerede tickets, der blev løst under den første supportinteraktion uden senere opfølgning eller genåbning inden for det valgte observationsvindue.
Anvendelse: Definér observationsvinduet og de kvalificerede kanaler, før du sammenligner perioder. En simpel markering af nul genåbninger er ikke altid tilstrækkelig til at fastslå løsning ved første kontakt.
Svar frem til løsning
Definition: Antallet af udvekslede svar, før ticketen blev løst.
Anvendelse: Find kategorier, der skaber unødvendig frem-og-tilbage-kommunikation. Et lavt antal er kun nyttigt, når problemet faktisk blev løst.
Målinger af kundeoplevelsen
Kundetilfredshed
Definition: Andelen eller gennemsnittet af svar på en defineret undersøgelse efter interaktionen.
Anvendelse: Rapportér altid antal svar og svarprocent sammen med scoren. Gennemgå skriftlige kommentarer, og segmentér omhyggeligt, især når stikprøverne er små.
Net Promoter Score
Definition: Procentdelen af ambassadører minus procentdelen af kritikere fra en defineret anbefalingsundersøgelse.
Anvendelse: Betragt den som et bredere mål for kunderelationen, ikke som en direkte erstatning for tilfredshed på ticketniveau.
Genåbningsrate
Definition: Løste tickets, der blev genåbnet inden for en defineret periode, divideret med kvalificerede løste tickets.
Anvendelse: Gennemgå kategorier, Users og procedurer for lukning, når raten ændrer sig. En genåbning kan indikere en ufuldstændig løsning, men kan også afspejle, at en kunde tilføjer et nyt problem til en gammel tråd.
Pålideligheds- og SLA-målinger
SLA-opfyldelse
Definition: Afsluttede svar- eller løsningstider, der overholdt det gældende mål, divideret med afsluttede tider i rapporteringspopulationen.
Anvendelse: Hold opfyldelse adskilt fra det aktuelle antal tickets, der er i risiko for eller har overskredet SLA'en. Den første er en historisk vurdering, mens den anden er et operationelt øjebliksbillede.
Backlogens alder
Definition: Aldersfordelingen for åbne tickets.
Anvendelse: Vis aldersintervaller og de ældste tickets. Vælg tærskler, der passer til dine serviceforpligtelser, i stedet for at anvende én universel grænse.
Eskaleringsrate
Definition: Tickets, der blev eskaleret til en anden gruppe eller specialist, divideret med kvalificerede tickets.
Anvendelse: Segmentér efter kategori og prioritet. Eskalering kan signalere et videnshul, men kan også være den korrekte vej for komplekst arbejde.
Økonomiske målinger
Pris pr. ticket
Definition: Allokerede supportomkostninger for en periode divideret med kvalificerede tickets, der blev håndteret i perioden.
Anvendelse: Dokumentér, hvilke lønninger, softwareudgifter, entreprenører og faste omkostninger der er inkluderet. Sammenlign tilsvarende perioder og lignende ticketpopulationer.
Pris efter kanal eller kategori
Definition: Allokerede omkostninger for en kanal eller kategori divideret med dens kvalificerede antal tickets.
Anvendelse: Brug kun dette, når tids- og omkostningsallokeringen er tilstrækkelig god til at understøtte beregningen. Falsk præcision er værre end at lade feltet stå tomt.
Sådan fastsætter du realistiske mål og benchmarks for dit team
Universelle helpdesk-benchmarks er sjældent universelle. Et mål afhænger af kanal, åbningstid, ticketkompleksitet, prioritet, bemanding og det løfte, der er givet til kunderne. Fastlæg først mål ud fra din egen drift.
- Definér målingen. Skriv starthændelse, sluthændelse, pauser, undtagelser og kvalificeret population ned.
- Opbyg en baseline. Brug tilstrækkeligt med historik til at dække normal variation. Sammenlign median- og percentilværdier, ikke kun gennemsnit.
- Segmentér baselinen. Adskil kanaler, prioriteter, grupper og større ticketkategorier, når deres arbejdsgange er forskellige.
- Knyt målet til en forpligtelse. SLA-mål bør matche serviceløftet. Interne forbedringsmål bør være udfordrende, men operationelt realistiske.
- Gennemgå målet efter procesændringer. Ny routing, bemanding, automatisering eller produktudgivelser kan ændre baselinen.
| Måling | Tilgang til mål | Foreslået frekvens |
|---|---|---|
| Tid til første svar | Fastlægges efter kanal, prioritet og serviceforpligtelse | Dagligt |
| Løsningstid | Fastlægges efter prioritet og ticketkategori | Dagligt og ugentligt |
| Løsning ved første kontakt | Fastlæg baseline efter kategori, og definér et observationsvindue | Ugentligt |
| Kundetilfredshed | Fastsættes først, når svarmængde og bias er forstået | Ugentligt eller månedligt |
| SLA-opfyldelse | Tilpasses den offentliggjorte eller kontraktligt aftalte forpligtelse | Dagligt og ugentligt |
| Backlogens alder | Brug tærskler, der er knyttet til prioritet og servicepolitik | Dagligt |
| Genåbningsrate | Fastlæg baseline efter kategori og politik for lukning | Ugentligt |
| Pris pr. ticket | Følg en internt defineret tendens konsekvent | Månedligt |
Brug rullende perioder, når en måling har et lille datagrundlag eller store daglige variationer. Brug periodesammenligninger, når du skal identificere driftsændringer. Vis i begge tilfælde antallet af kvalificerede tickets, så læserne kan vurdere, hvor stabilt resultatet er.
Sådan designer du dashboards, som hver målgruppe rent faktisk vil bruge
Et dashboard fungerer, når hvert kort besvarer et spørgsmål for målgruppen. Operationelle visninger skal hjælpe folk med at handle nu. Ledelsesvisninger skal forklare tendenser og undtagelser. Direktionens visninger skal forbinde supportresultater med service, risiko og omkostninger.
Sammenkobling af målgrupper og målinger
Users har brug for deres åbne arbejde, tickets, der venter på første svar, SLA-ure, der nærmer sig forfald eller er overskredet, samt tilstrækkelig køkontekst til at vælge den næste ticket.

Team leads har brug for antal oprettede versus løste tickets, backlogens alder, fordelingen af svartider, SLA-risiko og arbejdsbelastning pr. User. De har også brug for links til at gå ned i detaljerne og se de tickets, der ligger bag et tal.
Supportchefer har brug for tendenser efter gruppe, prioritet, kanal og kategori samt klare definitioner af hver KPI. Et scorecard på overordnet niveau bør føre videre til en tabel eller et diagram, der forklarer ændringen.
Direktionen har som regel brug for et lille sæt indikatorer for service, kvalitet, risiko og omkostninger. Vis målet, den aktuelle værdi, retningen og en kort forklaring på væsentlige ændringer.
Anbefalede widgets
- Oprettede versus løste tickets: tendenslinjer med samme interval
- Fordeling af første svar: median, 90. percentil og tidsintervaller
- Løsningstendens: segmenteret efter prioritet eller kategori
- SLA lige nu: aktuelle overskredne, snart forfaldne og satte-på-pause-ure
- SLA-opfyldelse: afsluttede tider, der overholdt deres mål i den valgte periode
- Backlog efter alder: antal åbne tickets i nyttige aldersintervaller
- Arbejdsbelastningstabel: aktivitet pr. gruppe og pr. User med relevant kontekst
- Kanaler og emnefordelinger: efterspørgselsmix og tilbagevendende temaer
Rapporteringsrytme
- Live operationel visning: åbne tickets, afventning på første svar og aktuel SLA-risiko
- Daglig gennemgang: antal tickets, backlogens alder, første svar, løsningstid og overskridelser
- Ugentlig gennemgang: tendenser, undtagelser, genåbningsrate, eskaleringsrate og forbedringstiltag
- Månedlig gennemgang: serviceresultater, omkostninger, kapacitet og ændringer af mål
Knyt hvert møde til beslutninger. En ugentlig gennemgang bør slutte med en navngiven ejer, en deadline og den måling, der viser, om ændringen virkede.
Få styr på dine data, før du rapporterer om dem
Målinger er kun så pålidelige som deres hændelsesdefinitioner. Før du bygger et dashboard, skal du bekræfte, at ticketsystemet registrerer hændelser for oprettelse, svar, status, tildeling og løsning konsekvent.
Minimal ticketskema
En rapporteringseksport har ofte brug for felter som disse:
ticket_id: stabil ticket-identifikatorcreated_at: tidsstempel for oprettelse af ticketfirst_qualifying_response_at: tidsstempel, der bruges i definitionen af første svarresolved_at: tidsstempel for løsningassignee_id: nuværende ansvarlige eller ansvarlige på hændelsestidspunktet, tydeligt angivetgroup_id: ansvarlig gruppechannel: kildekanalpriority: kontrolleret prioritetsværdistatus: kontrolleret statusværditags: om muligt kontrollerede kategoriersla_policy_id: gældende politik, når den findesreopened_count: antal genåbningshændelser
Ikke alle platforme viser det samme skema. Betragt disse som rapporteringskoncepter, ikke som en påstand om præcise feltnavne. Hvis en værdi kan ændre sig, skal du beslutte, om rapporten har brug for den aktuelle værdi eller værdien på tidspunktet for hændelsen.
Tags og taksonomi
Brug en kontrolleret taksonomi for kategorier, der påvirker bemanding, routing eller forbedringsarbejde. Hold listen lille nok til at kunne bruges konsekvent. Gennemgå ukategoriserede tickets og næsten identiske labels, før du stoler på kategoritendenser.
Automatisering kan hjælpe med at tildele felter, men automatisk klassificering kræver stadig kontrol. Spor ukendte resultater eller resultater med lav sikkerhed i stedet for at tvinge hver ticket ind i en misvisende kategori.
Tjekliste for instrumentering
- [ ] Alle tidsstempler bruger én gemt tidsstandard og en dokumenteret visningstidszone
- [ ] Definitionen af første svar angiver, om automatiske svar tæller
- [ ] Ure baseret på åbningstid og kalendertid blandes ikke
- [ ] Statusser på pause er dokumenteret for løsningstider
- [ ] Hændelser for genåbning og eskalering har eksplicitte definitioner
- [ ] Den aktuelle ansvarlige forveksles ikke med den ansvarlige ved løsning
- [ ] Slettede, sammenlagte, spam-, test- og importerede tickets har en fastlagt inklusionspolitik
- [ ] Hver score viser antallet af kvalificerede tickets
Pro tip: Genberegn et lille udsnit manuelt. Hvis dashboardresultatet ikke kan genskabes ud fra tickethændelser, skal du rette definitionen eller dataene, før du fastsætter et mål.
Rapporteringsfælder, der gør dine målinger misvisende
-
At betragte antallet af tickets som præstation. Antallet måler efterspørgsel. Kombinér det med backlog, hastighed og kvalitet, før du drager konklusioner om præstationen.
-
At rapportere et gennemsnit uden en fordeling. Gennemsnit kan skjule lange ventetider. Tilføj en median, percentil eller visning efter tidsintervaller.
-
At rangere Users alene efter lukkede tickets. Ticketkompleksitet, arbejdstid, gentildeling og kvalitet påvirker alle optællinger. Brug arbejdsbelastningstabeller til at balancere arbejdet, ikke som en selvstændig præstationsscore.
-
At blande forskellige ticketpopulationer. Forskellige prioriteter, kanaler og kategorier kræver ofte forskellige mål. Segmentér, før du sammenligner.
-
At forveksle aktuel SLA-status med historisk opfyldelse. En ticket, der aktuelt har overskredet SLA'en, er et operationelt problem. En afsluttet tid, der ikke nåede sit mål, hører til i opfyldelsesraten. Bland ikke de to populationer.
-
At ignorere ændringer i nævneren. En procentdel kan ændre sig, fordi den kvalificerede population ændrede sig. Vis altid antallet bag den.
-
At opfinde præcision. Hvis håndteringstid, omkostningsallokering eller undersøgelsesdækning er ufuldstændig, skal du angive begrænsningen eller udelade målingen.
En dashboard-skabelon, der er klar til brug, og som du kan kopiere i dag
Skabelonen nedenfor er platformsneutral. Tilpas feltnavne og formler, så de passer til din datamodel, og dokumentér derefter hver tilpasning.
Regnearksskema og formler
| Kolonnenavn | Formel eller kilde | Bemærkninger |
|---|---|---|
ticket_id |
Ticketsystem | Stabil nøgle |
created_at |
Tickethændelse | Gem i én tidsstandard |
first_response_at |
Første kvalificerende svarhændelse | Dokumentér, hvordan automatiske svar behandles |
resolved_at |
Løsningshændelse | Dokumentér håndtering af genåbninger |
frt_minutes |
Forskel mellem oprettelse og første svar | Kalender- eller åbningstidsminutter |
resolution_minutes |
Forskel mellem oprettelse og løsning | Træk dokumenterede pauser fra, hvis det er relevant |
reopened_count |
Antal genåbningshændelser | Vælg et observationsvindue |
sla_first_reply_met |
Vurdering af SLA-ur | Null, hvis der ikke findes et relevant afsluttet ur |
sla_resolution_met |
Vurdering af SLA-ur | Null, hvis der ikke findes et relevant afsluttet ur |
channel |
Ticketkilde | Kontrolleret værdi |
priority |
Ticketfelt | Kontrolleret værdi |
group_id |
Ticketfelt eller hændelseshistorik | Angiv, om det er aktuelt eller gældende på hændelsestidspunktet |
Eksempler på SQL-udsnit
Første svar i kalendertid i MySQL:
SELECT ticket_id,
TIMESTAMPDIFF(MINUTE, created_at, first_response_at) AS frt_minutes
FROM tickets
WHERE first_response_at IS NOT NULL;
Oprettede tickets efter nuværende ansvarlige og dag:
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;
Opfyldelse af SLA for første svar blandt afsluttede sager:
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;
Disse eksempler bruger forenklede felter og kalendertid. Produktionsrapportering skal anvende de samme regler for kvalificering, åbningstid, pauser, sammenlægning og sletning som kildesystemet.
Layout for dashboardfaner
- Operationel fane: åben kø, afventning på første svar, aktuel SLA-risiko og ældste tickets
- Ledelsesfane: tendens for oprettede versus løste tickets, svarfordeling, løsningstendens, SLA-opfyldelse, backlogens alder og arbejdsbelastningstabeller
- Direktionsfane: udvalgte KPI'er for service, kvalitet, risiko og omkostninger med mål og korte kommentarer
Pro tip: Opbevar en måleordbog ved siden af dashboardet. Versionsstyr ændringer af formler og mål, så historiske skift fortsat kan forklares.
Hvor rapportering faktisk giver værdi
Rapportering giver værdi, når den ændrer køstyring, bemanding, routing, dokumentation eller produktarbejde. Et avanceret diagram, der ikke fører til nogen beslutning, er mindre nyttigt end en enkel backlogvisning, der hjælper teamet med at rydde gamle tickets.
Start med ét mål for efterspørgsel, ét mål for hastighed, ét mål for pålidelighed eller kvalitet samt backlogens alder. Gennemgå dem samlet. Hvis antallet af tickets stiger, mens svartiden forbliver stabil, kan teamet have kapacitet. Hvis antallet af løste tickets halter efter antallet af oprettede tickets, og backloggen bliver ældre, er problemet synligt, før et enkelt overordnet gennemsnit bliver alarmerende.
Brug detaljerede visninger til at bevæge dig fra et mønster til de tickets, der ligger bag. Det bedste spørgsmål i en gennemgang er ikke blot: »Hvorfor ændrede tallet sig?« Det er: »Hvilke tickets forårsagede ændringen, hvad har de til fælles, og hvad vil vi gøre anderledes?«
Deskhero giver dig rapporteringsklare data fra dag ét
Deskhero omdanner forbundne Gmail-, Google Workspace- og Microsoft 365-mailbokse til delte ticketkøer. Tjenesten accepterer også tickets fra integrerede formularer og dens AI-chatbot, der er baseret på en FAQ.

Deskhero omfatter et operationelt Dashboard med statusvisninger for tickets, tickets, der venter på første svar, tendenser for antal tickets, gennemsnitlig tid til første svar, gennemsnitlig løsningstid og gennemsnitlig tid pr. status. Statistics-området har ni faste faner, der dækker oversigt, tendenser, svartider, SLA, team, AI og automatisering, kanaler, emnestatistik og en emneklynge.
Statistics kan filtreres efter dato og gruppe, med et ekstra politikfilter på SLA-fanen. Diagramkort kan skifte mellem diagram- og tabelvisning, og de fleste faner kan eksporteres til Excel. Tallene er begrænset til de grupper, som den User, der er logget ind, har adgang til, og bliver generelt cachet i cirka fem minutter. Den live SLA-stribe er adskilt fra den historiske opfyldelse.
Deskhero omfatter ikke en brugerdefineret rapportbygger. Emnevisningerne har også datagrænser: Emnegruppering kræver cirka 100 tickets og genopbygges med jævne mellemrum. En gratis prøveperiode på 30 dage er tilgængelig uden kreditkort.
Kilder
Denne guide bruger den rapporteringsadfærd, der er dokumenteret i Deskheros produktimplementering. De relaterede Deskhero-guides nedenfor giver yderligere kontekst om dashboards og modtagelse af tickets.
- Dashboards til kundesupportchefer: Skabeloner og KPI'er
- Fra e-mail til ticket: Den komplette guide til supportteams
FAQ
Hvad er de vigtigste målinger til service desk-rapportering?
Start med antal tickets, antal oprettede versus løste tickets, tid til første svar, løsningstid, SLA-opfyldelse, backlogens alder, genåbningsrate, eskaleringsrate, arbejdsbelastning pr. User og kanalmix. Tilføj tilfredsheds- og omkostningsmålinger, når deres kildedata er pålidelige.
Hvilke KPI'er er gode til en IT-helpdesk?
Første svar, løsning, SLA-opfyldelse, løsning ved første kontakt, genåbningsrate og kundetilfredshed kan alle være nyttige KPI'er. Vælg kun de målinger, der er knyttet til et vigtigt resultat, et klart mål og en handling, teamet kan udføre.
Hvor ofte bør du sende CSAT-undersøgelser?
Vælg en ensartet udløser, der passer til kunderejsen, f.eks. efter løsning af en kvalificeret ticket. Hold undersøgelsen kort, undgå gentagne henvendelser til den samme kunde, og rapportér antal svar og svarprocent sammen med scoren.
Hvad er en god rate for løsning ved første kontakt?
Der findes ingen nyttig universel rate, der gælder for alle teams. Definér, hvad der tæller som første kontakt, fastsæt et observationsvindue for opfølgninger eller genåbninger, fastlæg en baseline for raten efter kategori og kanal, og forbedr den uden at tilskynde til for tidlig lukning.
Hvordan beregner man pris pr. ticket?
Divider konsekvent allokerede supportomkostninger for en periode med de kvalificerede tickets, der blev håndteret i perioden. Dokumentér, hvilke arbejds-, software-, entreprenør- og faste omkostninger der er inkluderet, og sammenlign derefter tilsvarende perioder og ticketpopulationer.