Guides
MSP Metrics Benchmarks: tien kernmetrics voor mkb-MSPs
Dit zijn de tien kernmetrics die bepalen of een MSP reactief of proactief opereert — met concrete bandbreedtes per volwassenheidsniveau. Van tickets per endpoint tot recurrence rate: elke metric heeft een definitie, een interpretatie, en een bandbreedte die varieert per maturity level. De getallen in dit overzicht zijn typische ranges uit de Nederlandse mkb-MSP markt. Ze zijn geen universele normen en geen garanties — ze zijn referentiepunten om je eigen operatie tegen af te zetten.
1. Hoe je deze benchmarks leest
Het zijn bandbreedtes, geen normen
De getallen zijn typische ranges die we zien in de mkb-MSP markt. Je eigen cijfers variëren op basis van klantprofiel, sector, schaalgrootte en infrastructuurheterogeniteit. Een healthcare-MSP met strenge compliance-vereisten opereert anders dan een MSP die voornamelijk retailklanten bedient.
Eén metric vertelt weinig
Een lage MTTR is positief — tenzij je recurrence rate hoog is (dan los je snel op maar niet goed). Een hoog FTFR-percentage is positief — tenzij je alert-to-ticket ratio erop wijst dat je veel incidenten mist. Metrics vertellen pas een verhaal in combinatie.
De levels verwijzen naar volwassenheidsniveaus
Dit overzicht gebruikt vijf niveaus van handmatig (Level 1) tot self-healing (Level 5), gebaseerd op het MSP Automation Maturity Model. Elk niveau heeft herkenbare operationele kenmerken — de benchmarks bewegen mee met de manier waarop je werkt.
Methodologie
2. Totaaloverzicht per maturity level
De onderstaande tabel is het kernoverzicht. Alle bandbreedtes zijn indicatief en variëren per organisatie.
| Metric | L1 Reactief | L2 Gemonitord | L3 Geautom. | L4 Policy | L5 Self-h.* |
|---|---|---|---|---|---|
| Tickets/endpoint/jaar | >15 | 8–15 | 4–8 | 1–4 | <1 |
| Tickets/engineer/maand | 40–80 | 60–100 | 80–150 | 150–250 | 200–300+ |
| MTTR (bekende klassen) | >4 uur | 1–4 uur | 30 min–2 uur | <15 min | <2 min |
| FRT (P1) | >60 min | 30–60 min | 15–30 min | <15 min | <5 min |
| First Time Fix Rate | 50–65% | 60–70% | 70–80% | 80–90% | 85–95% |
| Escalatiepercentage | >30% | 20–30% | 15–25% | 5–15% | <5% |
| Alert-to-ticket ratio | 1:10–20 | 1:5–10 | 1:3–5 | 1:1–2 | n.v.t. |
| After-hours interventie | 30–40% | 20–30% | 15–20% | 5–10% | <2% |
| SLA-naleving | 70–85% | 80–90% | 88–95% | 95–99% | >99% |
| Recurrence rate (30d) | >25% | 15–25% | 10–15% | 5–10% | <3% |
* Level 5 is een theoretisch eindniveau. De waarden zijn streefwaarden, geen marktbenchmarks. Level 1–4 beschrijven wat we in de praktijk aantreffen.
Bron: bandbreedtes voor Level 1–4 zijn gebaseerd op operationele praktijkdata en sectorpatronen in de Nederlandse mkb-MSP markt (zie Methodologie). Zie het MSP Automation Maturity Model voor toelichting op de vijf niveaus.
3. Gezond vs. zorgwekkend — snelle referentie
| Metric | Zorgwekkend | Gezond |
|---|---|---|
| Tickets/endpoint/jaar | >15 | <8 |
| Tickets/engineer/maand | <50 of >300 zonder kwaliteitscontrole | 80–200 met stabiel FTFR |
| FRT (P1) | >60 min | <15 min |
| MTTR (gemiddeld) | >4 uur | <2 uur |
| First Time Fix Rate | <60% | >75% |
| Escalatiepercentage | >30% | <15% |
| Alert-to-ticket ratio | >1:10 | <1:3 |
| After-hours interventie | >30% menselijke actie | <10% menselijke actie |
| SLA-naleving | <85% | >95% |
| Recurrence rate (30d) | >20% | <10% |
Valt een metric in de kolom "zorgwekkend"? Dat is niet per se alarmerend — het is een signaal om dieper te kijken. Drie of meer in het rood is een operationeel patroon.
Snelle zelftest — waar sta jij?
Hoeveel van onderstaande uitspraken zijn waar voor jouw operatie?
Waarschijnlijk Level 1–2
De operatie is reactief en schaalt mee met het team, niet met de technologie. De grootste winst zit in monitoring-hygiene en runbook-standaardisatie.
Waarschijnlijk Level 2–3
De basis staat, maar de stap naar autonome uitvoering ontbreekt. De meeste mkb-MSPs zitten hier.
Waarschijnlijk Level 3–4+
De operatie is gestructureerd en grotendeels geautomatiseerd. De volgende stap is policy-driven remediation voor de resterende handmatige handelingen.
4. Ticketvolume en capaciteit
4.1 Tickets per endpoint per jaar
Definitie
Het totaal aantal support-tickets gedeeld door het aantal beheerde endpoints, gemeten over een jaar.
Waarom het ertoe doet. Dit is de meest directe maatstaf voor proactief vs. reactief werken. Een hoge score per endpoint wijst op reactief beheer, onvoldoende monitoring, of infrastructuur die structureel meer aandacht vraagt dan nodig.
Een kanttekening: te lage scores kunnen ook betekenen dat problemen niet gemeld worden. Combineer daarom altijd met klanttevredenheidsdata.
4.2 Tickets per engineer per maand
Definitie
Het totaal gesloten tickets per engineer per maand.
Waarom het ertoe doet. Maat voor engineerproductiviteit en schaalbaarheid. Te laag kan duiden op inefficiëntie; te hoog zonder kwaliteitscontrole is een teken dat tickets te snel worden gesloten.
Bij operaties die structureel automatiseren, stijgt de capaciteit per engineer omdat repetitieve L1-tickets autonoom worden afgehandeld — niet omdat engineers sneller werken, maar omdat ze ander werk doen.
5. Responstijd en doorlooptijd
5.1 First Response Time (FRT)
Definitie
De tijd tussen ticketaanmaak en de eerste inhoudelijke reactie van een engineer.
Waarom het ertoe doet. FRT is direct zichtbaar voor de klant en bepalend voor SLA-naleving. In de praktijk is FRT de metric met de sterkste impact op klanttevredenheid.
Structureel hoge FRT is bijna altijd een capaciteitsprobleem of een prioriteringsprobleem. Investeren in snellere FRT zonder het onderliggende volumeprobleem aan te pakken leidt tot uitputting.
5.2 Mean Time to Resolve (MTTR)
Definitie
De gemiddelde tijd van ticketaanmaak tot definitieve oplossing.
Waarom het ertoe doet. MTTR is de meest directe maat voor operationele effectiviteit.
MTTR is een gemiddelde. Segmenteer altijd naar incidenttype en prioriteit — anders maskeert een snel opgelost certificaatincident een P1 die acht uur open stond.
6. Oploskwaliteit
6.1 First Time Fix Rate (FTFR)
Definitie
Het percentage tickets dat bij de eerste poging volledig wordt opgelost — zonder heropen, terugverwijzing of follow-up-contact.
In operaties met policy-driven remediation stijgt FTFR omdat de geautomatiseerde oplossing altijd de volledige remediatie-flow volgt — inclusief verificatie.
6.2 Escalatiepercentage
Definitie
Het percentage tickets dat wordt geëscaleerd van L1 naar L2 of hoger.
Bij operaties met autonome remediatie daalt het escalatiepercentage structureel — niet door betere L1-engineers, maar doordat bekende incidenttypes de L1-queue niet meer bereiken.
7. Alert-efficiëntie en bereikbaarheid
7.1 Alert-to-ticket ratio
Definitie
De verhouding tussen het aantal gegenereerde monitoring-alerts en het aantal daadwerkelijk aangemaakte tickets.
Een ratio boven 1:10 duidt op alert fatigue: engineers beginnen alerts te negeren, waardoor echte incidenten gemist worden.
7.2 After-hours ticketpercentage
Definitie
Het percentage van het totale ticketvolume dat buiten kantoortijd binnenkomt en menselijke interventie vereist.
Bij operaties met self-healing infrastructure worden bekende nachtelijke incidenten autonoom opgelost. De engineer slaapt; het systeem handelt.
8. Compliance en herhaling
8.1 SLA-nalevingspercentage
Definitie
Het percentage tickets waarbij zowel FRT als MTTR binnen de contractueel afgesproken termijnen vallen.
SLA-naleving is een lagging indicator. Als het daalt, is het onderliggende probleem al weken oud. Wees voorzichtig met het sturen op SLA-naleving als doel: als je de termijnen verruimt, los je niets op.
8.2 Ticketherhalingpercentage (recurrence rate)
Definitie
Het percentage tickets waarbij hetzelfde type probleem binnen 30 dagen opnieuw optreedt bij dezelfde klant of omgeving.
Hoge recurrence is zowel een kwaliteits- als een kostenprobleem. De structurele oplossing is niet sneller oplossen, maar voorkomen. Policy-driven remediation pakt dit aan de bron aan.
9. Hoe gebruik je deze benchmarks?
Benchmarks zijn referentiepunten, geen rapportcijfers. Vier richtlijnen voor effectief gebruik:
Meet eerst
Zonder baseline weet je niet of je verbetert. De meeste PSA-tools kunnen de kernmetrics uit dit overzicht rapporteren — het vereist geen nieuw platform, alleen de discipline om het op te zetten en maandelijks te reviewen.
Combineer metrics
Eén metric in isolatie is misleidend. Een dalende MTTR gecombineerd met een stijgende recurrence rate wijst op snellere symptoombestrijding, niet op betere oplossingen. Lees metrics als een samenspel.
Segmenteer
Benchmarks variëren sterk per klanttype. Rapporteer per segment, niet alleen gemiddeld — anders maskeert een healthcare-outlier je retailbenchmarks.
Gebruik als gesprekstool
Benchmarks werken ook als gespreksopener met klanten over SLA-realisme. Dat is een professioneler gesprek dan "we doen ons best."
10. Veelgestelde vragen
Hoe weet ik of mijn MSP-metrics gezond zijn?
Vergelijk je eigen cijfers met de bandbreedtes per maturity level in dit overzicht. Een enkele metric vertelt weinig — het patroon is bepalend. Een lage MTTR gecombineerd met een hoge recurrence rate duidt op symptoombestrijding. Gezonde metrics bewegen sámen: tickets per endpoint daalt, FTFR stijgt, escalatiepercentage daalt. Als drie of meer metrics in de kolom "zorgwekkend" vallen, is dat een signaal om de operatie structureel te evalueren.
Wat is een realistisch MTTR-doel voor een mkb-MSP?
Dat hangt af van het incidenttype. Voor bekende, herhalende incidenten (service herstart, disk vol, certificaatvernieuwing) is een MTTR onder 15 minuten haalbaar met policy-driven remediation. Voor complexe, nieuwe incidenten die diagnose vereisen, is 1–4 uur een gezonde bandbreedte. Het realistisch doel is niet één MTTR-getal, maar twee: een lage MTTR voor bekende klassen en een acceptabele MTTR voor onbekende — en vervolgens het aandeel bekende klassen vergroten.
Hoe verhoudt mijn alert-to-ticket ratio zich tot de benchmark?
Bij veel mkb-MSPs die op Level 2 opereren, zien we ratio's van 1 ticket per 5 tot 20 alerts. Dat betekent dat 80 tot 95% van alle alerts geen actie vereist — maar wél aandacht opeist. Een gezonde ratio ligt rond 1:2, of alerts worden direct geremedieerd zonder tussenkomst. Als je team meer dan de helft van de werkdag besteedt aan het beoordelen en sluiten van niet-actionable alerts, is dat een capaciteitsprobleem dat zich voordoet als een monitoringprobleem.
Beïnvloedt klantgrootte de benchmarks?
Ja, substantieel. MSPs met voornamelijk kleine klantomgevingen (5–25 endpoints) zien typisch hogere tickets-per-endpoint-ratio's, omdat incidenten relatief vaker voorkomen op minder gestandaardiseerde infrastructuur. Omgekeerd rapporteren MSPs met grotere, homogenere klantomgevingen (100+ endpoints) vaak lagere volumes per endpoint — mits de monitoring-stack goed is ingericht. Segmenteer je benchmarks daarom altijd naar klantprofiel. Een gemiddelde over je hele klantenbestand maskeert de uitschieters.
Welke metric heeft de hoogste impact op klanttevredenheid?
In de praktijk is dat bijna altijd First Response Time. Klanten ervaren wachten als erger dan de duur van de oplossing. Een snelle eerste reactie — zelfs als het nog geen oplossing is — verlaagt escalaties en vergroot het vertrouwen dat het probleem wordt opgepakt. Maar structureel is recurrence rate bepalender: als hetzelfde probleem elke maand terugkomt, kalft het vertrouwen snel af, ongeacht hoe snel je reageert.
Hoe UptimePilot dit aanpakt
UptimePilot is het autonomous infrastructure platform voor mkb-MSPs. De metrics in dit overzicht zijn niet alleen referentiepunten — het zijn de indicatoren waar UptimePilot direct op opereert.
Volgende stap
Hoe scoren jouw metrics?
Laat UptimePilot je huidige operatie scannen op de tien kernmetrics en ontdek waar de structurele verbetermogelijkheden zitten.