Wanneer een supportteam overloopt, is de eerste reflex vaak: we hebben een beter ticketsysteem nodig. Soms klopt dat. Meestal niet. In de teams die ik heb gecoördineerd, zat het probleem bijna altijd in afspraken die ontbraken, niet in software die ontbrak. Meldingen komen via zes kanalen binnen, iedereen pakt op wat het hardst roept, dezelfde storing wordt drie keer opgelost en niemand weet wanneer een leverancier eigenlijk moet leveren.
Een nieuw systeem lost dat niet op. Het maakt het hooguit zichtbaarder. Hieronder de vijf afspraken die ik als eerste invoer, en die met vrijwel elk bestaand ticketsysteem, een gedeelde mailbox of desnoods een lijst in SharePoint uit te voeren zijn.
1. Eén ingang, en die wordt bewaakt
Alles wat support nodig heeft, komt via één kanaal binnen: een mailadres, een formulier of een portaal. Een collega die de beheerder aanschiet bij de koffieautomaat, krijgt een vriendelijk "zet het even in een ticket". Dat voelt eerst onaardig. Na twee weken merkt iedereen dat dingen niet meer kwijtraken.
Bij die ene ingang hoort iemand die de intake doet: bekijkt wat er binnenkomt, controleert of de informatie compleet is en kent een prioriteit toe. Dat hoeft geen aparte functie te zijn. In een klein team kan het een dagdienst zijn die rouleert. Het gaat erom dat het gebeurt, elke dag, op een vast moment.
2. Prioriteit is een formule, geen gevoel
De klassieke ITIL-benadering werkt hier prima: prioriteit is impact maal urgentie. Impact: hoeveel mensen of hoe belangrijk een proces. Urgentie: hoe snel het moet. Ik gebruik een matrix van drie bij drie, meer niet.
Het belangrijkste is niet de matrix zelf maar dat hij is afgesproken met de organisatie. Als de directie weet dat een kapotte laptop van één medewerker een prioriteit 3 is en de uitval van het ERP-pakket een prioriteit 1, dan is de discussie voorbij voordat hij begint. Zonder afspraak wint altijd degene die het hardst roept.
Bij elke prioriteit hoort een reactietijd en een streeftijd voor oplossing. Realistisch, niet ambitieus. Een streeftijd die nooit gehaald wordt, is erger dan geen streeftijd.
3. Escalatie heeft een pad, en het pad heeft namen
Wat gebeurt er als een melding niet binnen de streeftijd is opgelost? In veel teams: niets, tot iemand boos wordt. Een escalatiepad legt vast wie er wanneer wordt geïnformeerd en wie er mag beslissen over een uitwijk of extra inzet.
Twee soorten escalatie hou ik uit elkaar:
- Functioneel: de melding gaat naar iemand met meer kennis, bijvoorbeeld van de eerste naar de tweede lijn of naar een leverancier.
- Hiërarchisch: de leidinggevende wordt geïnformeerd omdat de streeftijd in gevaar komt of omdat er een beslissing nodig is die het team niet zelf mag nemen.
Beide krijgen een naam en een vervanger. Niet "de manager", maar een persoon. En bij grote storingen die over meerdere leveranciers gaan, is vooraf vastgelegd wie coördineert. Dat is bijna altijd de eigen ICT, niet een van de leveranciers.
4. Kennis vastleggen op het moment zelf
Elke servicedesk heeft het voornemen om een kennisbank te vullen. Vrijwel geen enkele doet het, omdat het altijd "straks" gebeurt. De enige manier die ik heb zien werken: bij het sluiten van een melding die vaker voorkomt, drie regels opschrijven. Wat was het, wat was de oorzaak, wat was de oplossing. Niet mooi, niet volledig, maar wel nu.
Daarnaast hou ik een eenvoudig overzicht bij van de belangrijkste systemen: wat het is, wie de eigenaar is, welke leverancier erachter zit, welk contract en welke licenties eraan hangen, en waar het van afhankelijk is. Geen volwaardige CMDB, gewoon een lijst die klopt. Die lijst blijkt onmisbaar zodra een contract afloopt of een storing over meerdere systemen gaat.
5. Leveranciers krijgen een vaste plek aan tafel
Veel frustratie in supportteams gaat over leveranciers: meldingen die blijven liggen, onduidelijkheid over wat er in het contract zit, niemand die de leverancier aanspreekt. De oplossing is niet harder mailen maar structuur:
- Eén contactpersoon per leverancier aan de eigen kant, die het overzicht heeft van de open meldingen.
- Een gezamenlijke lijst van openstaande punten, die periodiek wordt doorgenomen. Maandelijks voor belangrijke leveranciers, per kwartaal voor de rest.
- De contractafspraken bij de hand. Reactietijden, wat wel en niet in de dienst zit, wat extra kost. Verrassend vaak weet niemand dit tot het te laat is.
Een leverancier die weet dat er elke maand een lijst wordt doorgenomen, gedraagt zich anders dan een leverancier die af en toe een boze mail krijgt.
Wat dit oplevert
Geen van deze afspraken kost geld. Ze kosten een paar weken discipline en één persoon die de coördinatie op zich neemt en volhoudt. Na een maand of twee zie je het in de cijfers: minder meldingen die kwijtraken, minder herhaalde storingen, minder ruis richting het management. Pas daarna is het zinvol om te kijken of het ticketsysteem nog past. Meestal past het gewoon.
