De situatie
Ik kwam binnen bij een organisatie waar de servicedesk niet slecht functioneerde, maar wel voortdurend achter de feiten aan liep. Het team bestond uit een eerste lijn die de telefoon en de mailbox bemande, en een tweede lijn die de zwaardere zaken oppakte. Op papier een prima indeling.
In de praktijk bepaalde vooral het volume van de melder de volgorde. Wie het hardst aan de bel trok, werd het eerst geholpen. Er was geen gedeelde definitie van wat urgent is, dus iedere collega maakte zijn eigen afweging, en die afwegingen waren allemaal verdedigbaar en onderling verschillend.
Daar kwam bij dat er meerdere externe leveranciers in het spel waren: voor de netwerkinfrastructuur, voor een branchespecifieke applicatie en voor telefonie. Bij een storing die de grens tussen die domeinen raakte, wees iedereen beleefd naar de ander. Niemand voelde zich eigenaar van het geheel.
En het meeste wat het team wist, zat in hoofden. Wie er die dag was, bepaalde hoe snel iets werd opgelost.
De vraag
Het management vroeg mij om de coördinatie op te pakken. Niet om een nieuw ticketsysteem, en ook niet om een servicemanagementmodel over de organisatie heen te leggen. De vraag was concreter: zorg dat we weten wat er speelt, dat de juiste dingen eerst gebeuren en dat terugkerende storingen ook echt eindigen.
Ik heb bewust geen implementatietraject met veel jargon opgetuigd. Het denkwerk uit ITIL is bruikbaar, maar een team dat al onder druk staat, heeft vooral behoefte aan afspraken die op maandagochtend werken.
Mijn aanpak
1. Meekijken voordat ik iets verander
De eerste periode heb ik vooral meegelopen: meeluisteren bij de eerste lijn, meekijken bij de tweede lijn en oude meldingen doorlezen. Niet om te oordelen, maar om patronen te zien. Een aantal storingen bleek in verschillende gedaantes steeds terug te keren.
2. Triage-afspraken en een prioriteringsmatrix
Daarna heb ik samen met het team vastgelegd hoe een melding binnenkomt en wie hem oppakt. Kern daarvan is een eenvoudige matrix: hoe groot is de impact en hoe dringend is het. Die twee samen bepalen de prioriteit, niet de toon van de melder.
Ik heb die matrix bewust klein gehouden: een paar categorieën met voorbeelden uit de eigen organisatie erbij, zodat iedereen dezelfde beelden heeft. In het begin bepaalden we twijfelgevallen samen, tot het vanzelf ging.
3. Een escalatiepad dat mensen durven te gebruiken
Escalatie was in dit team een soort nederlaag geworden. Ik heb het omgedraaid: op vaste momenten in de doorlooptijd hoort een melding hogerop, ongeacht wie eraan werkt. Dat neemt de persoonlijke lading eruit. Ook heb ik vastgelegd wie er bij een grote verstoring de regie heeft en wie de organisatie informeert, zodat dat niet ter plekke uitgevonden hoeft te worden.
4. Leveranciers aan tafel in plaats van in de cc
Ik heb een terugkerend overleg ingericht met de belangrijkste leveranciers, met een gedeelde lijst van lopende punten. Belangrijker nog: bij storingen die meerdere domeinen raken, benoemen we vooraf wie de coördinatie heeft. Meestal was ik dat. Dat is minder comfortabel, maar het voorkomt dat een melding twee weken heen en weer kaatst.
5. Kennis uit hoofden halen
Bij elke opgeloste melding die vaker voorkomt, is een korte notitie in de kennisbank gemaakt. Geen handboek, maar praktische stappen. Daarnaast heb ik een overzicht opgebouwd van de belangrijkste systemen, hun onderlinge afhankelijkheden, de bijbehorende contracten en de licenties die daaronder hangen.
6. Terugkerende storingen structureel oppakken
Als laatste hebben we periodiek gekeken welke meldingen structureel terugkomen. Die kregen een eigen aanpak, los van de dagelijkse stroom. Een storing die je keer op keer oplost, heb je nog nooit opgelost.
Wat er na afronding staat
Er ligt een gedeelde manier van prioriteren die het team zelf heeft helpen opstellen en die ook navolgbaar is voor nieuwe collega's. Bij een grote verstoring is duidelijk wie de regie heeft en hoe de organisatie geïnformeerd wordt.
De leveranciers zitten periodiek aan tafel met een gezamenlijke lijst, en bij domeinoverstijgende storingen is vooraf belegd wie coördineert. De kennisbank is een levend document geworden in plaats van een goed voornemen. En er is een actueel overzicht van systemen, afhankelijkheden en licenties, waardoor beslissingen over vervanging of verlenging op feiten rusten.
Wat ik hiervan meeneem
Prioritering is een sociaal vraagstuk, geen technisch. De matrix was in een middag gemaakt. Het echte werk zat in het gesprek over waarom de hardste stem niet altijd de eerste plek verdient.
Escalatie moet neutraal zijn. Zolang hulp vragen voelt als falen, gebeurt het te laat. Een vaste tijdsgrens haalt het oordeel eruit.
Coördinatie tussen leveranciers moet iemand expliciet dragen. Als niemand is aangewezen, wijst iedereen netjes naar elkaar en gebeurt er niets.
Kennis vastleggen lukt alleen op het moment zelf. Achteraf een kennisbank vullen, komt er nooit van. Tijdens het oplossen drie regels opschrijven wel.