msp kwaliteit meten
Hoe meet je kwaliteit binnen een MSP?
Kwaliteit in een MSP meet je door uitkomsten over weken te volgen, niet door tickets en uren per dag te turven. Snelle afhandeling zegt niets als dezelfde storing drie weken later terugkomt in groter formaat.
MSP Late Night · 8 oktober 2026
Waarom zijn tickets en uren geen kwaliteitsmaat meer?
Een AI-tool haalt vandaag een voldoende op standaard ticketafhandeling. Dat betekent dat een engineer die scoort op aantal tickets en gewerkte uren feitelijk concurreert met een geautomatiseerde zes. Echte kwaliteit zit in het voorkomen van herhaalincidenten en de staat van de klantomgeving over een langere periode. Dat vraagt om continue meting, niet om een maandrapportje met ticketvolumes.
Wat meet je in plaats van ticketvolume?
Volg of een opgelost ticket binnen drie weken terugkomt bij dezelfde klant of asset. Herhaalincidenten zijn de hardste indicator dat snelle afhandeling eigenlijk uitstel was.
Waarom is kennis uit het hoofd niet meer relevant?
De techneut die wist op welke pagina firmware-updates stonden, is ingehaald door tools die dat sneller opzoeken. Kwaliteit zit nu in oordeelsvermogen over wat een incident betekent voor de klantomgeving.
Waarom is dit intern een struggle?
Beoordelingsgesprekken draaien nog om tickets en uren omdat die cijfers er al zijn. Sturen op uitkomst over tijd vraagt om nieuwe meetpunten en een gesprek dat engineers niet gewend zijn.
Een zes kan je met een AI-tool ook doen. Als persoon moet je minimaal hoger scoren dan dat.
Veelgestelde vragen
Welke KPI's vervangen tickets per dag en gewerkte uren?
Een gangbare richting is sturen op herhaalfrequentie van incidenten per klant, gemiddelde tijd tussen storingen op dezelfde asset, en het aandeel tickets dat binnen een vast venster van bijvoorbeeld drie weken terugkomt. Dat zijn uitkomst-KPI's over tijd, in plaats van activiteiten-KPI's per dag. Ze geven zicht op of een oplossing echt een oplossing was.
Hoe beoordeel je een engineer als AI de standaardtickets wegwerkt?
De beoordeling verschuift naar wat AI niet goed doet: inschatten of een incident een symptoom is van een groter probleem, communicatie met de klant, en keuzes die structurele problemen oplossen. Engineers worden beoordeeld op het voorkomen van toekomstige tickets, niet op de snelheid waarmee ze de huidige wegwerken.
Waarom is 80% snelle ticketafhandeling misleidend?
Snelheid meet alleen hoe vlot een ticket uit de lijst verdwijnt. Als 20% van die snel afgehandelde tickets binnen enkele weken terugkeert als groter probleem, is de netto bijdrage negatief. De klant ervaart meer verstoring en de MSP doet dubbel werk. Kwaliteitsmeting over een langere periode legt dat patroon pas bloot.
Hoe vaak moet je kwaliteit meten binnen een MSP?
Continu, niet per kwartaal. Een maand- of kwartaalrapport laat trends te laat zien om bij te sturen op individueel of teamniveau. Doorlopende meting op herhaalincidenten en klantimpact maakt het mogelijk om patronen vroeg te signaleren en het beoordelingsgesprek te voeden met actuele data in plaats van een momentopname.
Het hele gesprek, uitgeschreven
Want een 6 kan je met een AI-tool ook doen. Dus je zult als persoon minimaal een hoger score moeten gaan halen dan dat. Want iedereen kan een voldoende halen nu. Want ook al doe je niks, dan heb je je AI goed geprogrammeerd, heb je een voldoende. Ik ben bang dat het gemiddelde bewonersgesprek nog steeds gaat over hoeveel tickets heb je afgewerkt, hoeveel uren heb je gewerkt. Dus aan de ene kant willen we aan de klantzijde dat heel graag willen doen. Aan de andere kant intern is het best een struggle om dat zomaar even aan te passen. Maar als de ticketafhandeling, als die heel snel gebeurt, en dat is 80%, dat is heel mooi, maar als de ticket over drie weken zorgt voor nog grotere problemen, dan is het misschien helemaal niet zo goed dat je dat allemaal heel snel afgewikkeld hebt. Dus je wil uiteindelijk ook kwaliteit meten over een langere periode, maar wel continu. In plaats van, ik heb iemand en die kent het hele boekje uit zijn hoofd, want die hebben techneuten die precies wisten op welke pagina die dingen stonden en alle firmware updates, alles uit hun hoofd kenden. Dat is eigenlijk niet meer relevant nu.