Servicedeskcapaciteit plannen: rooster op je eigen piekmomenten, niet op onderbuikgevoel

Op veel servicedesks staat het rooster al jaren vast, terwijl de vraag allang is veranderd. De bezetting is ooit bepaald op een inschatting, en sindsdien past niemand hem meer aan. Het gevolg: op drukke momenten staat iedereen tegelijk in de wacht, en op rustige momenten zit een deel van het team niets te doen. Dit artikel laat zien hoe je bezetting plant op basis van je eigen ticketdata, hoe je het rooster daarop aanpast, en wat je doet als de capaciteit structureel tekortschiet.

Piekmomenten herkennen in je eigen data

Je hoeft niet te gokken wanneer het druk is, je ticketsysteem weet het al. Elke melding heeft een tijdstip. Zet die tijdstippen naast elkaar en er ontstaat een patroon: maandagochtend na het weekend, de eerste dagen na een vakantie, het moment direct na een update of migratie. Ook dagdelen verschillen vaak sterk: veel servicedesks zien een piek vroeg in de ochtend en nog een na de lunch, met een rustige periode ertussenin.

Kijk niet alleen naar het aantal meldingen, maar ook naar het type. Een piek in wachtwoordresets vraagt om iets anders dan een piek in complexe verstoringen. De eerste kun je makkelijk verdelen over meer mensen met basiskennis, de tweede vraagt om specifieke kennis op het juiste moment. De servicedesk-KPI's die er echt toe doen helpen je die piekmomenten structureel bijhouden en zichtbaar maken voor de planning.

Het rooster aanpassen op wat je ziet

Zodra je de patronen kent, is de volgende stap simpel maar wordt vaak overgeslagen: het rooster er daadwerkelijk op aanpassen.

Zet mensen waar de vraag zit

Verschuif een dienst een uur naar voren als de piek vroeg in de ochtend ligt. Laat iemand net iets later beginnen als de rustige periode voorspelbaar is. Kleine verschuivingen in bestaande diensten leveren vaak al veel op, zonder dat je iemand extra nodig hebt.

Bouw ruimte in voor onvoorspelbare drukte

Niet elke piek is te voorspellen. Een storing in een kernsysteem raakt niemand van tevoren. Reserveer daarom een deel van de capaciteit als buffer, in plaats van het rooster tot de laatste minuut vol te plannen. Een team dat continu op de rand van zijn kunnen draait, heeft geen ruimte voor het onverwachte.

Verander in stappen, niet in één keer

Een compleet nieuw rooster in één keer invoeren levert weerstand op en maakt het lastig om te zien wat werkt. Pas een paar diensten aan, kijk wat het doet met de wachttijd, en bouw daarna verder.

Als de capaciteit structureel tekortschiet

Soms is roosteren niet genoeg en blijft de druk hoog, dienst na dienst. De reflex is dan om meer mensen aan te nemen. Kijk eerst of dat wel het echte probleem is.

1. Kijk eerst naar het werk zelf. Onderzoek of een deel van de meldingen te voorkomen was geweest, bijvoorbeeld met shift-left en self-service of een kennisartikel dat de vraag al beantwoordt.
2. Verminder wat niet nodig is. Terugkerende storingen met dezelfde oorzaak, onnodige doorverwijzingen en onvolledige meldingen die extra vragen opleveren, kosten allemaal capaciteit zonder dat de gebruiker er iets aan heeft.
3. Verschuif waar dat kan. Werk dat nu bij de eerste lijn ligt maar net zo goed door de gebruiker zelf gedaan kan worden, hoort daar niet thuis.
4. Breid pas uit als dat allemaal is gedaan. Blijft de vraag dan nog boven de capaciteit uitkomen, dan is extra bezetting een onderbouwde keuze in plaats van een eerste reflex.

Wat het oplevert

Een rooster dat aansluit op de werkelijke vraag zorgt voor kortere wachttijden zonder dat je extra mensen nodig hebt. Het team werkt op de momenten dat het nodig is, in plaats van continu op halve kracht of juist overvraagd. En als de capaciteit toch tekortschiet, weet je zeker dat je eerst het werk hebt verminderd voordat je uitbreidt. Dat is precies meer bereiken met dezelfde mensen: niet harder roosteren, maar slimmer. Lees ook over van reactief naar proactief IT-support: terugkerende meldingen die je voorkomt, nemen druk weg zonder dat het rooster hoeft te veranderen. En voor hulp bij de capaciteitsaanpak: bekijk onze diensten voor servicemanagement.

Veelgestelde vragen

Hoe vaak moet je het rooster herzien? Een paar keer per jaar is genoeg, of direct na een grote verandering zoals een reorganisatie, een nieuwe applicatie of een fusie. Vaker heeft weinig zin, patronen veranderen niet elke maand.

Wat als de drukte per team of locatie verschilt? Kijk dan per team of locatie naar de data. Een landelijk gemiddeld rooster past zelden op de werkelijkheid van een specifiek team.

Is meer mensen aannemen dan nooit de oplossing? Soms wel, maar pas nadat je hebt gecontroleerd of het werk zelf niet eerst kleiner kan. Anders los je een probleem op met extra kosten die je ook had kunnen voorkomen.

Wil je weten of je servicedeskbezetting aansluit op de werkelijke vraag? plan een gesprek en we kijken samen naar je ticketdata.

Verder lezen

• ITIL (Wikipedia)
• IT-servicemanagement (Wikipedia)