De belangrijkste helpdeskmetrics voor supportmanagers

De statistieken die elke supportmanager, in volgorde van prioriteit, zou moeten rapporteren: ticketvolume, eerste responstijd (FRT), oplostijd (MTTR), oplossing bij het eerste contact (FCR), CSAT, SLA-naleving, ouderdom van de achterstand, heropeningspercentage, escalatiepercentage, tickets per medewerker, gemiddelde afhandeltijd (AHT), kosten per ticket, NPS en uitsplitsing per kanaal. Begin hiermee en je hebt een compleet beeld van de gezondheid van je team.

Hier volgt de geprioriteerde lijst met de aanbevolen rapportagefrequentie:

Ticketvolume — dagelijkse momentopname, wekelijkse trend
Eerste responstijd (FRT) — dagelijks (realtime waarschuwing bij SLA-overschrijding)
Oplostijd / MTTR — dagelijkse trend, wekelijkse evaluatie
Oplossing bij het eerste contact (FCR) — wekelijks
CSAT — wekelijkse score, maandelijkse trend
SLA-nalevingspercentage — dagelijkse meter, wekelijkse samenvatting
Ouderdom van de achterstand — dagelijks voor tickets ouder dan 48 uur
Heropeningspercentage — wekelijks
Escalatiepercentage — wekelijks
Tickets per medewerker — dagelijkse controle van de werkbelasting
Gemiddelde afhandeltijd (AHT) — wekelijks
Kosten per ticket — maandelijks
NPS — maandelijks of per kwartaal
Uitsplitsing per kanaal — wekelijks

De meeste teams proberen alles tegelijk bij te houden en ondernemen uiteindelijk op geen enkele statistiek actie. Kies de zes belangrijkste voor je eerste dashboard, zorg dat de gegevens schoon zijn en voeg daarna de rest toe.

Belangrijkste punten

Betrouwbare helpdeskrapportage begint met schone gegevens, een korte lijst KPI's met concrete doelen en een wekelijkse evaluatie waarbij iemand verantwoordelijk is voor elk getal.

Punt	Details
Maak onderscheid tussen statistieken en KPI's	Label elke statistiek als “Diagnostisch” of “KPI” voordat je een dashboard bouwt, om tegenstrijdige signalen te voorkomen.
FRT en CSAT vormen het paar met de hoogste ROI	Voorzie eerst de eerste responstijd en CSAT van meetinstrumenten; ze zijn snel in te stellen en vallen rechtstreeks binnen de controle van het team.
Benchmarks hebben context nodig	Gebruik de voorgestelde Amerikaanse doelbereiken (bijvoorbeeld FRT onder 1 uur voor e-mail en CSAT van 80%+) als uitgangspunt en stel daarna doelen vast op basis van je eigen basislijn van 90 dagen.
Datakwaliteit komt vóór dashboards	Zorg dat alle tijdstempels door de server worden gegenereerd en velden automatisch worden ingevuld voordat je een statistiek openbaar maakt.
Deskhero automatiseert de meetinrichting	Deskhero vult ticketvelden automatisch in en biedt een ingebouwde kaart met ticketinzichten, zodat rapportageklare gegevens vanaf het eerste ticket beschikbaar zijn.

Inhoudsopgave

Wat is het verschil tussen een helpdeskstatistiek en een KPI?
De belangrijkste helpdeskrapportagestatistieken, gegroepeerd naar doel
Realistische doelen en benchmarks voor je team instellen
Dashboards ontwerpen die elke doelgroep daadwerkelijk gebruikt
Je gegevens op orde brengen voordat je erover rapporteert
Rapportagevalkuilen die je statistieken misleidend maken
Een direct bruikbaar dashboardtemplate dat je vandaag kunt kopiëren
Waar rapportage daadwerkelijk rendement oplevert
Deskhero levert vanaf dag één rapportageklare gegevens
Bronnen
Veelgestelde vragen

Wat is het verschil tussen een helpdeskstatistiek en een KPI?

Elk getal dat je ticketsysteem produceert, is een statistiek. Een KPI is een statistiek waarvoor je hebt besloten het team verantwoordelijk te houden, met een doel en een consequentie als de score verslechtert. Het onderscheid is belangrijk, omdat het combineren van beide in één rapport verwarring veroorzaakt over wat informatief is en wat een prestatienorm vormt.

Een statistiek wordt een KPI wanneer aan drie voorwaarden is voldaan: de statistiek heeft een directe bedrijfsimpact (CSAT houdt verband met klantbehoud), is stabiel genoeg om over meerdere weken zinvol trends te tonen en kan daadwerkelijk door beslissingen van iemand in het team worden beïnvloed. Ticketvolume is bijvoorbeeld bijna altijd een diagnostische statistiek. Het vertelt je hoe druk het is, maar geen enkele medewerker kan de inkomende vraag verminderen door harder te werken. CSAT is daarentegen een KPI-kandidaat, omdat medewerkers en managers deze score kunnen beïnvloeden via kwaliteit, snelheid en nauwkeurigheid van de oplossing.

De praktische verdeling ziet er zo uit:

Diagnostische statistieken (context, geen doelen): ticketvolume, kanaalverdeling, aantal escalaties, AHT
KPI-kandidaten (stel een doel in, volg wekelijks): FRT, MTTR, FCR, CSAT, SLA-naleving, heropeningspercentage, kosten per ticket

Een veelgemaakte fout is het combineren van volume- en kwaliteitsstatistieken in dezelfde grafiek zonder normalisatie. Een medewerker die dagelijks 80 tickets behandelt, zal vrijwel altijd een lagere CSAT laten zien dan iemand die er 30 behandelt, niet omdat die persoon slechter is, maar omdat een hoog volume de kwaliteit van reacties onder druk zet. Rapporteer het aantal tickets per medewerker naast CSAT, zodat de cijfers het volledige verhaal vertellen.

Pro-tip: Label bij de eerste inrichting van je rapportage elke statistiek in je dashboard als “Diagnostisch” of “KPI” in de kolomkop of widgettitel. Zo moet het team vooraf overeenstemming bereiken over wat een doel is en wat slechts context biedt. Bovendien voorkom je dat managers een diagnostisch getal als beoordeling van prestaties behandelen.

De belangrijkste helpdeskrapportagestatistieken, gegroepeerd naar doel

De 17 veelgebruikte helpdeskstatistieken vallen uiteen in vier natuurlijke groepen: productiviteit, efficiëntie, klantervaring en betrouwbaarheid/financiën. Elke groep hieronder bevat de formule, een uitgewerkt voorbeeld, een op de VS gerichte benchmark en de actie die je moet ondernemen wanneer het getal verandert.

Diagram van helpdeskstatistieken, gecategoriseerd naar doel

Productiviteitsstatistieken

Ticketvolume Definitie: Totaal aantal aangemaakte tickets in een periode. Formule: Aantal tickets met created_at binnen het rapportagevenster. Voorbeeld: 340 tickets van maandag tot en met vrijdag = 68 per dag. Benchmark: Varieert per teamgrootte; volg de verandering ten opzichte van de vorige week, niet het absolute aantal. Bij een piek: Controleer eerst op een productincident, marketingcampagne of seizoensfactor voordat je extra personeel aanneemt. Type: Alleen diagnostisch.

Tickets per medewerker Definitie: Gemiddelde dagelijkse ticketbelasting per actieve medewerker. Formule: Totaal aantal toegewezen tickets ÷ aantal actieve medewerkers in de periode. Voorbeeld: 340 tickets ÷ 5 medewerkers = 68 tickets per medewerker per week. Benchmark: 40–80 tickets per medewerker per dag is een gebruikelijk bereik voor e-mailondersteuning; livechat verkleint dit aanzienlijk. Bij een stijging: Herverdeel toewijzingen of start een evaluatie van de personeelsbehoefte; aanhoudende overbelasting voorspelt binnen 2–4 weken een daling van CSAT. Type: Diagnostisch.

Uitsplitsing per kanaal Definitie: Percentage tickets dat via elk kanaal binnenkomt (e-mail, chat, telefoon, formulier, social media). Formule: (Tickets via kanaal X ÷ totaal aantal tickets) × 100.

Benchmark: Geen universeel doel; gebruik deze statistiek om personeelsbezetting en SLA-regels af te stemmen op de werkelijke kanaalmix. Als het aandeel chat groeit: Evalueer AHT en personeelsbezetting voor gelijktijdige sessies. Type: Diagnostisch.

Efficiëntiestatistieken

Eerste responstijd (FRT) Definitie: Tijd vanaf het aanmaken van een ticket tot het eerste antwoord van een medewerker. Formule: first_response_at − created_at (voor de meeste SLA's alleen tijdens kantooruren). Voorbeeld: Ticket aangemaakt om 9:00 uur, eerste antwoord om 9:47 uur = FRT van 47 minuten. Benchmark: Onder 1 uur voor e-mail is een veelgenoemd Amerikaans doel; voor livechat geldt minder dan 5 minuten. Als FRT stijgt: Controleer wachtroutering, beschikbaarheid van medewerkers en of een automatische ontvangstbevestiging een echte vertraging verhult. Type: KPI-kandidaat.

Handen die een bedieningsknop voor responstijd aanpassen

Gemiddelde afhandeltijd (AHT) Definitie: Gemiddelde tijd die een medewerker actief besteedt aan een ticket, van openen tot sluiten. Formule: Totale afhandeltijd voor alle tickets ÷ aantal gesloten tickets. Voorbeeld: 850 minuten afhandeltijd ÷ 17 tickets = AHT van 50 minuten. Benchmark: Sterk afhankelijk van de context; een AHT van 10 minuten voor wachtwoordresets en 90 minuten voor factuurgeschillen kunnen beide correct zijn. Als AHT stijgt: Controleer de meest tijdrovende ticketcategorieën en maak er kennisbankartikelen voor. Type: Diagnostisch (gebruik dit alleen voor specifieke ticketcategorieën als KPI, niet voor de volledige wachtrij).

Oplostijd / MTTR Definitie: Gemiddelde tijd tot oplossing, vanaf het aanmaken van een ticket tot de sluiting. Formule: Som van (resolved_at − created_at) voor alle gesloten tickets ÷ aantal gesloten tickets. Voorbeeld: 5 tickets opgelost in 2, 4, 6, 3 en 5 uur = 20 uur totaal ÷ 5 = MTTR van 4 uur. Benchmark: Onder 24 uur voor standaardprioriteit; minder dan 4 uur voor hoge prioriteit is een gebruikelijk doel voor Amerikaanse servicedesks. Als MTTR stijgt: Segmenteer op prioriteit en categorie. Eén tickettype drijft het gemiddelde vaak omhoog; door die categorie aan te pakken, verbetert het totaalcijfer. Type: KPI-kandidaat.

Oplossing bij het eerste contact (FCR) Definitie: Percentage tickets dat wordt opgelost zonder vervolgcontact of heropening. Formule: (Tickets opgelost bij het eerste contact ÷ totaal aantal tickets) × 100.

Als FCR daalt: Bekijk de ticketcategorieën die het vaakst worden heropend en werk medewerkerscripts of kennisbankinhoud bij. Type: KPI-kandidaat.

Statistieken voor klantervaring

CSAT (Customer Satisfaction Score) Definitie: Percentage klanten dat de supportervaring positief beoordeelt (meestal 4–5 op een schaal van 5). Formule: (Positieve antwoorden ÷ totaal aantal antwoorden) × 100.

Het enquêteontwerp is belangrijk: Goed ontworpen CSAT-enquêtes die binnen 30 minuten na het sluiten van een ticket worden verstuurd, leveren feedback van hogere kwaliteit en met meer actiepunten op dan enquêtes die dagen later worden verstuurd. Als CSAT daalt: Verzamel de letterlijke opmerkingen, segmenteer ze per medewerker en categorie en zoek naar patronen voordat je conclusies trekt. Type: KPI-kandidaat.

NPS (Net Promoter Score) Definitie: De waarschijnlijkheid dat klanten je support aanbevelen, op een schaal van 0–10. Promotors (9–10) minus Criticasters (0–6) = NPS. Formule: (% Promotors − % Criticasters).

Benchmark: Een positieve NPS (boven 0) is het minimum; boven +30 geldt voor B2B-support als goed. Als NPS daalt: NPS is een achterlopende indicator. Combineer deze daarom met CSAT en het heropeningspercentage om de operationele oorzaak te vinden. Type: KPI-kandidaat (maandelijkse of driemaandelijkse frequentie).

Heropeningspercentage Definitie: Percentage opgeloste tickets dat door de klant opnieuw wordt geopend. Formule: (Heropende tickets ÷ totaal aantal opgeloste tickets) × 100.

Als het heropeningspercentage stijgt: Controleer of medewerkers tickets te vroeg sluiten om doelstellingen voor de oplostijd te halen. Type: KPI-kandidaat.

Betrouwbaarheids- en SLA-statistieken

SLA-nalevingspercentage Definitie: Percentage tickets dat binnen het overeengekomen SLA-venster wordt opgelost of beantwoord. Formule: (Tickets die aan de SLA voldoen ÷ totaal aantal tickets) × 100.

Als de naleving daalt: Bepaal welke prioriteitslaag de SLA overschrijdt en of de overschrijding betrekking heeft op FRT of MTTR. Type: KPI-kandidaat.

Ouderdom van de achterstand Definitie: Verdeling van openstaande tickets naar de tijd dat ze onopgelost zijn. Formule: Voor elk open ticket: huidige tijdstempel − created_at. Rapporteer dit als histogram (0–24 uur, 24–48 uur, 48–72 uur, 72 uur+). Voorbeeld: 12 tickets ouder dan 72 uur = een achterstand die onmiddellijk moet worden gesorteerd. Benchmark: Het doel is nul tickets die ouder zijn dan je hoogste SLA-niveau; elk ticket ouder dan 72 uur moet een handmatige beoordeling opleveren. Als de achterstand groeit: Verdeel de wachtrij in leeftijdscategorieën en wijs de oudste tickets als eerste toe, ongeacht het prioriteitslabel. Type: KPI-kandidaat (dagelijkse monitoring).

Escalatiepercentage Definitie: Percentage tickets dat naar een hoger niveau of specialist wordt geëscaleerd. Formule: (Geëscaleerde tickets ÷ totaal aantal tickets) × 100.

Als het escalatiepercentage stijgt: Segmenteer op ticketcategorie en medewerker. Als één categorie de meeste escalaties veroorzaakt, wijst dat meestal op een tekort in de kennisbank. Type: Diagnostisch (kan een KPI worden als trainingsprogramma's eraan worden gekoppeld).

Financiële statistieken

Kosten per ticket Definitie: Totale supportkosten gedeeld door het totale aantal behandelde tickets in de periode. Formule: (Totale supportkosten: salarissen + tools + overhead) ÷ totaal aantal tickets. Voorbeeld: $25.000 maandelijkse supportkosten ÷ 1.400 tickets = $17,86 per ticket. Benchmark: Bereiken verschillen sterk per sector en kanaal; volg je eigen trend in plaats van een absoluut doel. Als de kosten per ticket stijgen: Controleer of het ticketvolume is gedaald (vaste kosten worden over minder tickets verdeeld) of dat AHT is toegenomen. Type: KPI-kandidaat (maandelijks).

Statistiek: Onderzoek van Forrester identificeert het meten van klantervaring consequent als een topprioriteit voor investeringen. Organisaties die ervaring consequent meten, zijn beter gepositioneerd om klantbehoud en omzet te verbeteren — de zakelijke reden om CSAT en NPS als echte KPI's te behandelen, niet als optionele extra's.

Realistische doelen en benchmarks voor je team instellen

Benchmarklijsten zijn een uitgangspunt, geen einddoel. Een MTTR-doel van 24 uur is redelijk voor een team van vijf personen dat 200 tickets per week verwerkt. Voor een enterprise-helpdesk met 50 medewerkers die 10.000 tickets over vier prioriteitsniveaus verwerkt, is dat vrijwel zeker onjuist. De onderstaande methode biedt een herhaalbare manier om doelen in te stellen die passen bij je werkelijke context.

Stel een basislijn vast. Verzamel 90 dagen historische gegevens voor elke statistiek. Bereken de mediaan (niet het gemiddelde — uitschieters vertekenen gemiddelden). Die mediaan is je huidige prestatieniveau.
Vergelijk met vergelijkbare teams. Gebruik sectoronderzoeken en IT-KPI-verzamelingen om het bereik te vinden voor teams van jouw omvang en in jouw sector. Bepaal waar je basislijn binnen dat bereik valt.
Stel een verbeterdoel voor 90 dagen in. Streef naar een verbetering van 10–15% op je zwakste KPI, niet naar een sprong naar best-in-class. Agressieve doelen die nooit worden gehaald, demoraliseren teams sneller dan helemaal geen doelen.
Pas seizoensinvloeden toe. Als je ticketvolume in het vierde kwartaal met 40% stijgt, moet je MTTR-doel voor november en december die realiteit weerspiegelen, niet de basislijn van het tweede kwartaal.
Maak een betrouwbaarheidsbereik, geen enkel getal. Schrijf in plaats van “CSAT moet 85% zijn” bijvoorbeeld “CSAT-doel: 83–87%”. Een bereik houdt rekening met meetruis en voorkomt paniek over een daling in één week.

Een herhaalbaar proces van verzamelen–opschonen–analyseren–handelen is wat helpdeskgegevens omzet in meetbare bedrijfsgroei, in plaats van in een dashboard waar niemand naar kijkt.

Statistiek	Voorgesteld Amerikaans doelbereik	Rapportagefrequentie
Eerste responstijd (e-mail)	Minder dan 1 uur	Dagelijks
Eerste responstijd (chat)	Minder dan 5 minuten	Realtime
MTTR (standaardprioriteit)	Minder dan 24 uur	Dagelijks
MTTR (hoge prioriteit)	Minder dan 4 uur	Realtime waarschuwing
Oplossing bij het eerste contact	80%	Wekelijks
CSAT	80%+	Wekelijkse score
SLA-naleving	90%	Dagelijkse meter
Achterstand (tickets ouder dan 72 uur)	0	Dagelijks
Heropeningspercentage	Minder dan 5%	Wekelijks
Kosten per ticket	Trend volgen	Maandelijks

Vermindering van klantverloop houdt verband met CSAT en FCR. Die formulering zorgt ervoor dat rapportage op directieniveau serieus wordt genomen.*

Wanneer gebruik je voortschrijdende gemiddelden versus doelen per periode? Gebruik voor CSAT en NPS een voortschrijdend gemiddelde van 28 dagen, omdat wekelijkse steekproeven vaak te klein zijn om statistisch betekenisvol te zijn. Gebruik voor FRT en MTTR vergelijkingen tussen perioden (deze week versus vorige week, deze maand versus vorige maand), omdat je operationele veranderingen snel wilt signaleren.

Dashboards ontwerpen die elke doelgroep daadwerkelijk gebruikt

Een dashboard waar niemand naar kijkt, is erger dan helemaal geen dashboard, omdat het de illusie van meting creëert zonder het voordeel ervan. De oplossing is doelgroepmapping: elke groep krijgt alleen de statistieken waarop die groep actie kan ondernemen.

Doelgroep-naar-statistiek-mapping

Medewerkers hebben een persoonlijk overzicht nodig: hun eigen FRT, aantal open tickets, vandaag opgeloste tickets en eventuele SLA-overschrijdingswaarschuwingen in hun wachtrij. Niets meer. Medewerkers zonder context het gemiddelde van de teamscore voor CSAT tonen, veroorzaakt alleen onrust.

Handen die werkruimte-items en een timer beheren

Teamleiders hebben het operationele beeld nodig: FRT-verdeling (niet alleen het gemiddelde), MTTR per categorie, SLA-naleving per prioriteitslaag, heropeningspercentage en een ranglijst van tickets per medewerker. De ranglijst is alleen nuttig wanneer deze wordt gecombineerd met CSAT per medewerker, zodat werkbelasting en kwaliteit samen zichtbaar blijven.

Supportmanagers hebben trendlijnen en uitzonderingsrapporten nodig: wekelijkse CSAT-trend, heatmap van de ouderdom van de achterstand, escalatiepercentage per categorie, kosten per ticket van maand tot maand en FCR-trend. De dashboardtemplates voor klantenservice die voor managers het beste werken, combineren een scorecard op hoofdlijnen met de mogelijkheid om per categorie en medewerker in detail te kijken.

Directieleden hebben een samenvatting van één pagina nodig: CSAT-score en trend, SLA-nalevingspercentage, kosten per ticket en één NPS-getal. Ze hebben geen ticketvolume nodig tenzij dit aan een bedrijfsgebeurtenis is gekoppeld. Beperk het directieoverzicht tot maximaal vier of vijf getallen.

Aanbevolen widgets

Ticketvolume in de tijd: lijngrafiek, dagelijkse granulariteit, venster van 30 dagen
SLA-nalevingsmeter: wijzerplaat of percentagekaart, elk uur bijgewerkt
Histogram van de FRT-verdeling: toont de spreiding, niet alleen het gemiddelde — een mediaan van 45 minuten met een 90e percentiel van 4 uur vertelt een heel ander verhaal dan een mediaan van 45 minuten met een 90e percentiel van 55 minuten
MTTR-trendlijn: voortschrijdend gemiddelde van 28 dagen, uitgesplitst naar prioriteit
CSAT-trend en letterlijke opmerkingen: scorelijn plus een feed met de meest recente negatieve beoordelingen
Heatmap van achterstand naar ouderdom: rijen per categorie, kolommen per leeftijdscategorie (0–24 uur, 24–48 uur, 48–72 uur, 72 uur+)
Ranglijst van tickets per medewerker: in hetzelfde overzicht gekoppeld aan CSAT per medewerker

Rapportagefrequentie

Realtime dashboards: FRT, SLA-naleving, aantal open tickets — altijd live voor medewerkers en teamleiders
Dagelijkse momentopnamen: per e-mail verstuurd overzicht van het volume, de FRT en eventuele SLA-overschrijdingen van gisteren — voor teamleiders
Wekelijkse evaluaties: CSAT, FCR, heropeningspercentage, escalatiepercentage en MTTR-trend — voor managers tijdens een vaste vergadering
Maandelijkse directiesamenvattingen: CSAT, NPS, kosten per ticket, SLA-naleving en één beschrijvende alinea over wat er is veranderd en waarom

Gebruik wekelijkse evaluaties voor trendanalyse, niet voor brandjes blussen.

Je gegevens op orde brengen voordat je erover rapporteert

Statistieken zijn slechts zo betrouwbaar als de gegevens erachter. Een eerste responstijd die is berekend op basis van door medewerkers bewerkte tijdstempels in plaats van door de server geregistreerde gebeurtenissen, is geen meting maar een gok. Zorg eerst dat de meetinrichting klopt voordat je het dashboard bouwt.

Minimaal ticketschema

Elk ticket moet deze velden bij het aanmaken of sluiten automatisch ingevuld krijgen, niet handmatig door medewerkers:

created_at — tijdstempel van de server, nooit bewerkbaar
first_response_at — tijdstempel van de server voor het eerste uitgaande antwoord van een medewerker (geen automatische ontvangstbevestiging)
resolved_at — tijdstempel van de server voor de statuswijziging naar “opgelost”
assignee_id — identificatie van de medewerker
channel — e-mail, chat, formulier, telefoon, social media
sla_type — welk SLA-niveau van toepassing is
priority — laag, normaal, hoog, urgent
tags — categorietaxonomie (zie hieronder)
escalation_flag — boolean, door automatisering ingesteld wanneer een ticket naar een hoger niveau gaat
reopened_count — geheel getal, door automatisering verhoogd wanneer een gesloten ticket een nieuw antwoord ontvangt
cost_center — afdeling of productlijn, voor segmentatie van kosten per ticket

Als een van deze velden ontbreekt of handmatig door medewerkers wordt ingevuld, zullen je statistieken gaan afwijken. Het proces voor e-mail-naar-ticket-mapping is de plek waar de meeste van deze velden automatisch moeten worden ingesteld, niet achteraf.

Tagging en taxonomie

Gebruik voor tags een beheerde keuzelijst, geen vrije tekst. Vrije tekst levert binnen een maand 40 varianten van “factuurvraag” op. Een beheerde taxonomie met vijf tot tien hoofdcategorieën en twee niveaus met subcategorieën is voor de meeste teams voldoende. Automatiseer de toewijzing van tags waar mogelijk met trefwoorden in onderwerpregels en regels voor afzenderdomeinen.

Integraties en extensies uit marketplace-platforms kunnen extra rapportagetelemetrie en automatische invulling van velden bieden, waardoor afwijkingen door handmatige invoer aanzienlijk afnemen — dit principe geldt ongeacht welk platform je gebruikt.

Checklist voor de meetinrichting

[ ] Alle tijdstempels worden door de server gegenereerd en kunnen niet door medewerkers worden bewerkt
[ ] Tijdzone-normalisatie is toegepast (alles opslaan in UTC, converteren voor weergave)
[ ] Automatische ontvangstbevestigingen zijn uitgesloten van de FRT-berekening
[ ] Kantooruren zijn correct geconfigureerd in de SLA-regels
[ ] De escalatievlag wordt door automatisering ingesteld, niet via een selectievakje voor medewerkers
[ ] Het aantal heropeningen wordt automatisch verhoogd bij een inkomend antwoord op een gesloten ticket
[ ] Het kanaalveld wordt ingevuld op basis van routeringsregels, niet via handmatige selectie

Pro-tip: *Voer een datakwaliteitsaudit uit op je tickets van de afgelopen 30 dagen voordat je een dashboard publiceert. Bereken het percentage tickets met een lege first_response_at of een lege resolved_at.

Rapportagevalkuilen die je statistieken misleidend maken

De gevaarlijkste helpdeskapporten zijn rapporten die er netjes uitzien, maar het verkeerde meten. Dit zijn de fouten die consequent leiden tot slechte operationele beslissingen.

Het ruwe aantal tickets als prestatiestatistiek bijhouden. Volume vertelt je iets over de vraag, niet over prestaties. Een team dat 500 tickets per week sluit, is niet per se beter dan een team dat er 200 sluit — als het team met 500 tickets een CSAT van 60% en een heropeningspercentage van 15% heeft, lossen ze tickets op zonder problemen daadwerkelijk te verhelpen. Combineer volume altijd met kwaliteitsstatistieken.
Responstijden middelen zonder naar de verdeling te kijken. Een gemiddelde FRT van 2 uur klinkt acceptabel totdat je ziet dat 30% van de tickets langer dan 8 uur wacht. Rapporteer het 90e percentiel van de FRT naast de mediaan. Die ene aanpassing maakt zichtbaar of je een systematisch probleem hebt of slechts enkele uitschieters die het gemiddelde omhoogtrekken.
Productiviteit van medewerkers te veel benadrukken ten koste van CSAT. Ranglijsten die uitsluitend op gesloten tickets zijn gebaseerd, sturen medewerkers aan op snel sluiten in plaats van goed oplossen. Een team dat een ranglijst “per dag gesloten tickets” invoerde, zag het heropeningspercentage binnen zes weken stijgen van 4% naar 11%, omdat medewerkers tickets als opgelost markeerden voordat klanten hadden bevestigd dat het probleem was verholpen. Koppel elke productiviteitsstatistiek aan een kwaliteitsstatistiek.
Geëscaleerde tickets mengen met statistieken van de normale stroom. Geëscaleerde tickets hebben een fundamenteel andere complexiteit en afhandeltijd. Als je ze opneemt in het algemene MTTR-gemiddelde, blaas je het getal op en lijkt de prestatie van de standaardlaag slechter dan ze is. Rapporteer geëscaleerde tickets als een aparte groep.
Het heropeningspercentage volledig negeren. Het heropeningspercentage is een van de duidelijkste signalen van oplossingskwaliteit, maar veel teams houden het nooit bij. Een stijgend heropeningspercentage voorspelt vaak twee tot drie weken later een daling van CSAT, zodat je tijd hebt om in te grijpen voordat klanten beginnen weg te lopen.
NPS behandelen als een realtime operationele statistiek. NPS is een strategisch signaal, geen dagelijks getal. Teams die NPS wekelijks controleren en reageren op schommelingen van één week verspillen energie aan statistische ruis. Gebruik NPS per kwartaal en combineer deze met CSAT voor het operationele beeld.

Een direct bruikbaar dashboardtemplate dat je vandaag kunt kopiëren

Het onderstaande schema geeft je de exacte kolomnamen voor een spreadsheet- of SQL-export, plus voorbeeldquery's voor de meest voorkomende berekeningen. Het sluit rechtstreeks aan op het ticketschema uit de bovenstaande sectie over datakwaliteit.

Spreadsheetschema en formules

Kolomnaam	Formule / bron	Opmerkingen
`ticket_id`	Door het systeem gegenereerd	Primaire sleutel
`created_at`	Tijdstempel van de server	UTC
`first_response_at`	Tijdstempel van de server	Automatische bevestigingen uitsluiten
`resolved_at`	Tijdstempel van de server	UTC
`frt_minutes`	`(first_response_at − created_at)` in minuten	Alleen kantooruren
`mttr_hours`	`(resolved_at − created_at)` in uren	Alleen kantooruren
`fcr_flag`	1 als `reopened_count = 0`, anders 0	Boolean
`aht_minutes`	Door het systeem geregistreerde afhandeltijd	Geen kloktijd
`cost_per_ticket`	`monthly_support_cost ÷ tickets_in_month`	Maandelijks opnieuw berekenen
`csat_score`	Enquêterespons (1–5)	Koppelen via ticket_id
`sla_met`	1 als opgelost binnen het SLA-venster, anders 0	Boolean
`channel`	Routeringsregel	Beheerde keuzelijst
`escalation_flag`	Door automatisering ingestelde boolean	Geen selectievakje voor medewerkers
`reopened_count`	Automatisch verhoogd geheel getal	Activeert de FCR-vlag

Voorbeeldfragmenten in SQL

FRT per ticket (kantooruren, in minuten):

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

Tickets per medewerker per dag:

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

FCR-percentage voor een periode:

SELECT
  SUM(CASE WHEN reopened_count = 0 THEN 1 ELSE 0 END) * 100.0 / COUNT(*) AS fcr_rate
FROM tickets
WHERE resolved_at BETWEEN '2026-01-01' AND '2026-01-31';

Indeling van dashboardtabbladen

Medewerkerstabblad: persoonlijke FRT, open tickets, vandaag opgeloste tickets, SLA-overschrijdingswaarschuwingen — widgets: getalkaarten + waarschuwingsbanner
Managerstabblad: histogram van FRT-verdeling, MTTR-trendlijn, CSAT-trend + feed met letterlijke opmerkingen, SLA-nalevingsmeter, heatmap van achterstand naar ouderdom, ranglijst van tickets per medewerker gekoppeld aan CSAT per medewerker
Directietabblad: CSAT-scorekaart, NPS-getal, SLA-nalevingspercentage, trend van kosten per ticket — vier widgets, geen detailweergave

Pro-tip: Voorzie je dashboardtemplate van een datum in de bestandsnaam (bijvoorbeeld support_dashboard_v2_2026-02.xlsx) en bewaar de vorige versie één kwartaal. Wanneer een KPI-doel verandert, heb je de oude template nodig om te verklaren waarom de historische trend er anders uitziet dan de nieuwe basislijn.

Waar rapportage daadwerkelijk rendement oplevert

De teams die het meeste uit helpdeskrapportagestatistieken halen, zijn niet de teams met de meest geavanceerde dashboards. Het zijn de teams die twee of drie statistieken kiezen, de gegevens opschonen en ze bespreken tijdens een vaste wekelijkse vergadering waarin iemand verantwoordelijk is voor het getal.

FRT en CSAT vormen samen voor de meeste kleine en middelgrote teams het paar met de hoogste ROI. FRT is eenvoudig te meten, makkelijk te begrijpen en valt rechtstreeks binnen de controle van een medewerker. CSAT sluit de cirkel door te laten zien of snelheid heeft geleid tot een goede ervaring. De ouderdom van de achterstand is de derde statistiek waarop je je in een vroeg stadium moet richten, omdat een groeiende achterstand het vroegste waarschuwingssignaal is dat een team achteropraakt, nog voordat een andere statistiek dat laat zien.

De culturele verandering die dit alles versterkt, is eenvoudig: stop met statistieken in een rapport te beoordelen en begin ze in een gesprek te bespreken. Een getal op een dia verandert niets. Een teamleider die vraagt: “Waarom piekte onze FRT dinsdagmiddag?” en een echt antwoord krijgt — een productstoring, een verkeerd geconfigureerde routering, twee zieke medewerkers — verandert metingen in verbetering. Onderzoek van Forrester naar investeringsprioriteiten voor CX bevestigt dit: consequente meting in combinatie met opvolging binnen de organisatie onderscheidt teams die klantbehoud verbeteren van teams die het alleen bijhouden.

Deskhero levert vanaf dag één rapportageklare gegevens

Als je team handmatig CSV-bestanden exporteert, spreadsheets aan elkaar knoopt of ontdekt dat de helft van je first_response_at-velden leeg is, ligt het probleem meestal bij het platform en niet bij het proces. In die situatie verdient een speciaal daarvoor ontworpen helpdesk zichzelf snel terug.

Deskhero

Deskhero verandert elk Gmail- of Microsoft 365-postvak binnen enkele minuten in een gedeelde ticketwachtrij, met door de server geregistreerde tijdstempels, automatisch ingevulde velden en een ingebouwde kaart met ticketinzichten die de statistieken uit deze gids voedt zonder handmatige gegevensinvoer. De AI maakt antwoorden op basis van je goedgekeurde kennisbank, vult tags automatisch in op basis van routeringsregels en registreert elke geautomatiseerde actie, zodat je audittrail schoon blijft. De case study van eM Client beschrijft het soort efficiëntiewinst dat teams zien wanneer het platform de meetinrichting automatisch afhandelt. Voor een gratis proefperiode van 30 dagen is geen creditcard nodig — begin daar, importeer het spreadsheetschema uit deze gids en je hebt vóór het einde van de proefperiode een werkend dashboard.

Bronnen

De volgende bronnen zijn gebruikt bij het opstellen van deze gids. Raadpleeg het Forrester-artikel voor de zakelijke onderbouwing van CX-metingen, de gids voor enquêteontwerp voor CSAT/NPS-meetinrichting en de gids over data en groei voor de methode verzamelen–opschonen–analyseren–handelen.

Veelgestelde vragen

Wat zijn de belangrijkste statistieken voor servicedeskrapportage?

De belangrijkste servicedeskstatistieken zijn eerste responstijd, oplostijd (MTTR), oplossing bij het eerste contact, CSAT, SLA-nalevingspercentage, ouderdom van de achterstand, heropeningspercentage, escalatiepercentage, tickets per medewerker en kosten per ticket. Begin met FRT en CSAT als je rapportage vanaf nul opbouwt.

Wat zijn goede KPI's voor een IT-helpdesk?

Combineer deze voor de volledige context met IT-statistieken per afdeling, zoals uptime en medewerkerstevredenheid, zoals IT-KPI-frameworks aanbevelen.

Hoe vaak moet je CSAT-enquêtes versturen?

Stuur een CSAT-enquête binnen 30 minuten na het sluiten van een ticket voor de hoogste responspercentages en de meest nauwkeurige feedback. Goed enquêteontwerp beperkt de enquête tot één of twee vragen en houdt altijd ook het responspercentage naast de score bij — een laag responspercentage maakt zelfs een hoge CSAT-score onbetrouwbaar.

Wat is een goed percentage oplossingen bij het eerste contact?

Bereken dit als het percentage tickets dat wordt opgelost zonder vervolgcontact of heropening en segmenteer per ticketcategorie om te bepalen waar de oplossingskwaliteit het zwakst is.

Hoe bereken je de kosten per ticket?

Deel je totale supportkosten (salarissen, tools en overhead) voor een periode door het totale aantal tickets dat in diezelfde periode is behandeld. $25.000 aan maandelijkse kosten gedeeld door 1.400 tickets is bijvoorbeeld $17,86 per ticket. Volg de trend van maand tot maand in plaats van deze met een absoluut getal te vergelijken, omdat de kosten per ticket sterk variëren per sector, kanaalmix en teamgrootte.