MSP performance meten kwaliteit: waarom ticketaantallen je misleiden

MSP performance meten kwaliteit klinkt logisch, maar in de praktijk zit bijna elk functioneringsgesprek nog vast aan tickets en geschreven uren. Je verkoopt aan de voorkant waarde, en intern beoordeel je mensen op volume. Die twee werelden botsen harder dan de meeste eigenaren willen toegeven, en het gat wordt elk kwartaal groter naarmate AI en automation de simpele tickets overnemen.

Herkenbaar scenario: aan de klantkant beweeg je richting een value-based model. Managed contracten, vaste maandbedragen, ontzorgen. Negentig procent van je klantportfolio zit al niet meer op uurtje-factuurtje. En toch gaat het halfjaarlijkse gesprek met je engineer nog steeds over hoeveel tickets hij heeft weggewerkt en hoeveel uur hij declarabel was. Dat is geen klein administratief dingetje. Dat is een fundamentele mismatch tussen wat je verkoopt en waar je op stuurt.

De tweede laag onder dat probleem is subtieler. Een engineer die vandaag 80% van zijn tickets snel afhandelt, scoort op papier uitstekend. Maar als een deel van die snel-afgewerkte tickets over drie weken terugkomt als groter probleem, heb je in feite productiviteit gemeten die geen waarde was. Je hebt beloond wat je over een maand weer moet oplossen. En in een wereld waar AI de simpele tickets steeds vaker zelf oppakt, blijft precies dat soort werk over: de context, de inschatting, het gesprek met de klant.

Dan is er nog de leiderschapsvraag. Als jij als eigenaar niet helder krijgt wat kwaliteit concreet betekent in gedrag, tast je MT in het duister. En je team daaronder nog meer. Vage termen als verantwoordelijkheid en flexibiliteit staan op het whiteboard, maar niemand kan vertellen welk gedrag daarbij hoort op een maandagochtend om half tien.

Van ticketteller naar kwaliteitsmix

Wat in de praktijk begint te werken bij MSP's die deze omslag serieus nemen, is geen nieuwe tool en geen vierde dashboard. Het is een expliciete keuze dat output een mix is van kwantiteit én kwaliteit, en dat kwaliteit zwaarder weegt. Dat klinkt soft, maar het heeft directe operationele consequenties. Je gaat metrics over een langere periode meten, niet per sprint of per maand. En je accepteert dat snelheid alleen niets zegt zolang je niet weet of de oplossing standhoudt.

Concreet betekent dat voor de meeste MSP's dat je naast ticketvolume ook kijkt naar herhaalincidenten binnen 30 of 60 dagen op dezelfde infrastructuur. Naar de marge-ontwikkeling per servicecontract over een jaar. Naar hoe vaak een engineer een probleem escaleert naar een collega, en of dat na coaching afneemt. Niet omdat die cijfers op zichzelf de waarheid zijn, maar omdat ze samen een beeld geven dat één ticket-KPI nooit kan geven.

De tweede verschuiving zit in frequentie. Een jaarlijks of halfjaarlijks beoordelingsgesprek past niet meer bij een vak dat elk kwartaal verandert door nieuwe tooling, nieuwe dreigingen en nieuwe klantverwachtingen. Je wilt continu bijsturen, niet in juni terugkijken op januari. Dat vraagt om korte check-ins van vijftien minuten per maand waarin je niet alleen cijfers bespreekt maar ook concreet gedrag.

En die derde laag, de menselijke skills, verdient een plek in het model. Hoe goed voert iemand een lastig gesprek met een klant die boos is? Durft een junior aan te geven dat een deadline niet haalbaar is? Pakt iemand nieuwe tooling adaptief op of blijft hij hangen in de oude manier? Dat zijn beoordeelbare dingen, mits je ze concreet maakt.

Wat kwaliteit meten in de praktijk betekent

Een werkbare opzet die we steeds vaker zien, bestaat uit vier blokken die elk kwartaal langskomen. Blok één: output-kwaliteit. Daaronder vallen first-time-fix percentages, herhaalincidenten per klant per kwartaal, en gemiddelde oplossingstijd gesplitst naar complexiteit. Niet één getal, maar drie die samen vertellen of iemand snel én duurzaam werkt. Een engineer die 95% first-time-fix haalt maar twee herhaalincidenten per maand produceert, scoort anders dan iemand met 80% en nul herhaalincidenten. Dat onderscheid komt alleen boven water als je bereid bent de cijfers naast elkaar te leggen in plaats van ze te middelen tot één dashboardgetal dat niemand nog kan interpreteren.

Blok twee: klantimpact. Hoeveel contactmomenten per contract per kwartaal, welk type (storing, advies, proactief), en de ontwikkeling in klantfeedback. Veel MSP's hebben hier wel een NPS-cijfer, maar koppelen dat zelden terug naar individuele engineers. Terwijl juist daar het leermoment zit. Als drie klanten in één kwartaal dezelfde engineer specifiek noemen als sterk of zwak punt, is dat harder beoordelingsmateriaal dan welke urenstaat ook. Een praktische manier om dit op te pakken: laat je accountmanagers na elk kwartaalgesprek met een klant twee namen noteren, één positief en één aandachtspunt. Binnen een jaar heb je een beeld dat geen enkel ticketsysteem je kan geven.

Gedragsindicatoren naast de cijfers

Blok drie is waar het meestal fout gaat: concreet gedrag. Als je op kernwaarden als eigenaarschap of samenwerking wilt beoordelen, moet je per kernwaarde drie tot vijf observeerbare gedragingen definiëren. Eigenaarschap is dan bijvoorbeeld: binnen 24 uur terugkoppelen aan de klant, zelf een tweedelijns inschakelen zonder te wachten op management, en bij een gemiste deadline eerst zelf een nieuwe planning voorstellen. Dat is bespreekbaar. "Hij heeft eigenaarschap" is dat niet. En het mooie is: zodra je het zo concreet maakt, kan een engineer zichzelf ook beoordelen voordat jij er iets van zegt. Dat haalt de spanning uit het gesprek en verschuift het van oordeel naar ontwikkeling.

Blok vier gaat over adaptiviteit, en dat is het blok dat de meeste MSP's nog niet eens hebben. Hoe snel pakt iemand nieuwe tooling op? Experimenteert iemand zelfstandig met AI-ondersteuning in zijn dagelijks werk, of wacht hij tot er een training komt? Dit soort gedrag kun je niet meten in cijfers, maar wel in observeringen die je kwartaalgewijs vastlegt. De engineers die over drie jaar het verschil maken, zijn niet degenen die de meeste tickets wegwerken, maar degenen die het snelst nieuwe context oppakken. Dat betekent ook dat je je wervingsprofiel moet herzien: wie je nu aanneemt op pure technische diepte, loopt het risico over twee jaar vast te lopen als de aard van het werk verschuift.

Hoe je dit model invoert zonder weerstand

De invoering zelf is minstens zo belangrijk als het model. Als je morgen in een teamoverleg aankondigt dat tickets er niet meer toe doen, verlies je je senior engineers binnen een kwartaal. Die hebben jarenlang hard gewerkt binnen het oude systeem en voelen zich terecht overvallen. Werkbaar is een parallel traject: je houdt de bestaande KPI's zichtbaar, maar voegt per kwartaal één nieuw blok toe en bespreekt dat expliciet in de één-op-één gesprekken. Na drie kwartalen heeft iedereen door hoe het nieuwe model werkt en kun je het oude dashboard rustig naar de achtergrond schuiven.

Een laatste praktische noot: dit model werkt alleen als je als eigenaar bereid bent zelf anders te sturen. Als jij in elk MT-overleg vraagt naar ticketvolume en declarabele uren, krijgt je team dat signaal luider dan welk nieuw beoordelingsformulier ook. De verschuiving naar kwaliteit begint op de directiekamer, niet in HR. En ze kost minstens twee tot drie kwartalen voordat je er iets van terugziet in de cijfers, dus geduld hoort erbij.

De MSP's die de komende drie jaar echt naar een value-based model bewegen, zijn de MSP's die intern al zijn gestopt met beoordelen op volume. Niet omdat tickets niet tellen, maar omdat ze te weinig vertellen. Wie wacht tot de perfecte XLA-structuur bestaat voordat hij zijn interne beoordeling aanpast, blijft hangen in een model waarvan iedereen weet dat het achterhaald is. Begin bij één team, één kwartaal, vier blokken. Dat is genoeg om te zien of het werkt.