Checklist: Gebruik je logische categorieën voor incidenten?

Je team is waarschijnlijk veel tijd kwijt aan het categoriseren van binnenkomende incidenten. Maar waarom ken je eigenlijk categorieën toe? Handelt de servicedesk hierdoor sneller incidenten af? Check met deze 6 vragen of je het maximale uit de categorisatie van je incidenten haalt.

Waarom zou je incidenten überhaupt categoriseren?

Laten we beginnen bij de belangrijkste vraag: waarom zou je überhaupt moeite doen om incidenten te categoriseren? Heb je die informatie echt nodig? Kun je het telefoongesprek niet gewoon registreren en het daarbij laten?

Het categoriseren van incidenten heeft twee hoofddoelen: doorsturen en rapporteren.

Door te categoriseren wijs je snel een telefoongesprek toe aan het juiste team. In de meeste gevallen wijs je handmatig toe, maar soms gaat dit automatisch door middel van AI, of op basis van triggerwoorden.

Met categorieën krijg je ook inzicht in de aard van terugkerende incidenten. Je kunt zo onderliggende problemen oplossen, relevante kennisitems genereren of processen automatiseren, zoals wachtwoorden opnieuw instellen.

Volg deze best practices om alles uit ITIL incident management te halen >>

1. Hoe kun je je categorieën het beste ordenen?

Het ordenen gebeurt in de praktijk op allerlei manieren, maar ik raad je aan om je categorieën te baseren op je diensten en de bijbehorende problemen.

Je hoofdcategorie bestaat dan uit de diensten die je levert, zoals ‘e-mail’, ‘werkplek’ of ‘onboarding/offboarding’. Per categorie vermeld je de problemen die bij deze diensten horen, zoals ‘geblokkeerde e-mail’, ‘aanvraag werkplekitem’ of ‘nieuwe aanwerving’.

Een paar tips met betrekking tot deze categorieën:

· Maak je subcategorieën niet te specifiek. Ik zie dat veel organisaties de dienst (‘e-mail’) vastleggen in de hoofdcategorie en de mogelijke oorzaak in de subcategorie (bijvoorbeeld ‘storing mailserver’ of ‘bug Outlook’). Het probleem hierbij is dat je bij het registreren van het telefoongesprek nog niet zeker weet wat het probleem veroorzaakt. Als je aan het begin van de incidentafhandeling een verkeerde inschatting maakt, moet je de categorie tijdens de afhandeling van het telefoongesprek aanpassen.

· Fixeer je niet te veel op het afstemmen van je categorieën op je selfserviceportal. Elke dienst kan uit een aantal verschillende taken voor je teams bestaan. Zelfs als deze taken in verschillende categorieën vallen, wil je toch nog steeds één volledige dienst aan je klanten laten zien.

2. Hoeveel niveaus moeten je categorieën hebben?

Twee. Of eigenlijk: niet meer dan strikt noodzakelijk. Maar in de meeste gevallen zouden twee categorieën meer dan genoeg moeten zijn. Dit is waarom:

· Je wil niet dat je team te lang bezig is om telefoongesprekken te registreren. En je wilt ook niet dat klanten die je selfserviceportal gebruiken, te veel moeite moeten doen om de juiste categorie te vinden. Het is verleidelijk om mensen tot diep in je categorieën mee te nemen, maar je categorisatie wordt er alleen maar minder transparant van.

· Je wil het de servicedesk zo makkelijk mogelijk maken om een categorie te kiezen. Met elk extra niveau wordt de juiste categorie kiezen echter lastiger en tijdrovender. Soms weet je welke subcategorie je nodig hebt, maar weet je niet meer onder welke hoofdcategorie deze viel. Als je je omgekeerd een weg door twee bovenliggende niveaus aan categorieën moet banen, kan dat nogal een gedoe zijn.

· Je categorieën hoeven niet per se elk stukje beschikbare informatie te bevatten. Je hoeft incidenten niet in steeds kleinere categorieën op te splitsen. Dat brengt ons bij de volgende vraag.

3. Welke informatie hoort niet in je categorieën thuis?

Soms zie ik organisatie categorisatie gebruiken om informatie te registreren die beter op een andere manier kan worden geregistreerd. Twee voorbeelden van informatie die niet bij categorieën thuishoren:

· Middelen waarop het probleem van toepassing is. Als je in je categorieën specifieke middelen vermeldt, bijvoorbeeld een bepaald type laptop, moet je je categorieën aanpassen wanneer je organisatie een nieuw type laptop gaat gebruiken. Je kunt de relevante asset beter bij het telefoongesprek vermelden en er een link naar plaatsen.

· Afdeling of team. Ik zie vaak dat voor de categorieën afdelingen (bijvoorbeeld ‘IT-diensten’, ‘facilitaire diensten’) of teams (bijvoorbeeld ‘Databaseteam’ of ‘Applicatiebeheer’ worden gebruikt. Het probleem hiermee is dat je bij het registreren van een telefoongesprek vaak niet weet wie het zal afhandelen.

4. Staat er een maximum op het aantal categorieën?

Niet echt. Net als bij het aantal niveaus geldt hier: gebruik er niet meer dan nodig is.

De 7×7-regel is een goed uitgangspunt. Probeer je te beperken tot 7 categorieën en 7 subcategorieën per categorie.

Maar je hoeft je hier niet strikt aan te houden. Zit je bij een servicedesk waar je met 8, 9 of 10 categorieën beter uitkomt, dan doe je dat gewoon. Ben je meer dan 10 categorieën aan het vastleggen, denk dan nog even goed na of je ze echt allemaal nodig hebt.

5. Hebben we een categorie 'overig' nodig?

Deze vraag leidt vaak tot behoorlijk heftige discussies. Wat mij betreft zou ik zeker een categorie ‘overig’ gebruiken. Maar ik heb ook professionals gesproken die zich fel verzetten tegen deze bodemloze categorie. Waarom ben ik er dan wel voorstander van?

Als je geen specifieke plek hebt voor incidenten die moeilijk te categoriseren zijn, kunnen mensen niet anders dan categorieën gebruiken die niet echt geschikt zijn. Je gaat hiermee ook volledig voorbij aan het doel van categorisatie. Elke categorie kan een aantal incidenten bevatten die daar niet thuishoren. Met een categorie ‘overig’ weet je dat er moeilijk in te delen incidenten zijn en wordt je aandacht er meteen op gevestigd. En als er altijd incidenten in de categorie ‘overig’ staan, kun je hier zelfs nuttige informatie uit halen om je categorieën te verbeteren.

6. Waar moet je op letten als je je categorieën beoordeelt?

Heb je eenmaal besloten welke categorieën goed voor je werken, blijf je systeem dan steeds controleren en aanpassen terwijl je het gebruikt. Voer een maandelijkse beoordeling uit nadat je je categorieën hebt ingevoerd of aangepast. Na een paar maanden zou een driemaandelijkse beoordeling moeten volstaan. Dit is waar je op moet letten bij het beoordelen van je categorieën:

· Controleer de categorie ‘overig’. Bevat deze veel gesprekken? Of wordt deze categorie vaak door dezelfde teamleden gebruikt? Kijk of je een nieuwe categorie moet toevoegen of dat je je team meer uitleg moet geven.

· Controleer het gebruik van alle categorieën. Bevatten sommige categorieën veel of slechts enkele gesprekken? Verwijder of splits categorieën op. In een handige blogpost geeft Julie Mohr de volgende richtlijn: ‘Heb je een CTI-element (bucket) dat 25 procent van je ticketvolume bevat, dan is de structuur mogelijk niet gedetailleerd genoeg. Bevat een bucket minder dan twee procent van je ticketvolume, dan is deze waarschijnlijk te specifiek.’

· Een van de grote voordelen van het categoriseren van incidenten is dat je de oorzaken kunt analyseren. Je incidenten worden gegroepeerd, dus je kunt met een oorzakenanalyse bij elke beoordeling onderliggende problemen voor soortgelijke of terugkerende problemen vinden en oplossen.

Meer best practices lezen?

We delen regelmatig onze best practices op het gebied van servicemanagement. Dit is een selectie van artikelen die je misschien interessant vindt:

• Werk jij al met een prioriteitenmatrix op je servicedesk?

• 3 redenen om jouw onboarding op orde te krijgen

• 5 best practices voor problem management

Of download onze Best Practice Service Management e-book: