Je team is waarschijnlijk veel tijd kwijt aan het categoriseren van binnenkomende incidenten. Maar waarom ken je eigenlijk categorie\u00ebn toe? Handelt de servicedesk hierdoor sneller incidenten af? Check met deze 6 vragen of je het maximale uit de categorisatie van je incidenten haalt.<\/p>\n
Laten we beginnen bij de belangrijkste vraag: waarom zou je \u00fcberhaupt moeite doen om incidenten te categoriseren? Heb je die informatie echt nodig? Kun je het telefoongesprek niet gewoon registreren en het daarbij laten?<\/p>\n
Het categoriseren van incidenten heeft twee hoofddoelen: doorsturen en rapporteren.<\/strong><\/p>\n 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.<\/p>\n Met categorie\u00ebn 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.<\/p>\n Volg deze best practices om alles uit ITIL incident management te halen >><\/a><\/p>\n Het ordenen van categorie\u00ebn kan op verschillende manieren, maar het is vaak het meest effectief om deze te baseren op de diensten die je levert en de bijbehorende problemen.<\/p>\n De hoofdcategorie bestaat dan uit je diensten, zoals \u2018e-mail\u2019, \u2018werkplek\u2019 of \u2018onboarding\/offboarding\u2019. Binnen elke categorie vermeld je de meest voorkomende problemen, bijvoorbeeld \u2018geblokkeerde e-mail\u2019, \u2018aanvraag werkplekitem\u2019 of \u2018nieuwe aanwerving\u2019.<\/p>\n Een paar tips voor het opzetten van categorie\u00ebn:<\/p>\n Maak subcategorie\u00ebn niet te specifiek.<\/strong><\/p>\n<\/li>\n<\/ul>\n Veel organisaties leggen de dienst vast in de hoofdcategorie (bijvoorbeeld \u2018e-mail\u2019) en de mogelijke oorzaak in de subcategorie (zoals \u2018storing mailserver\u2019 of \u2018bug Outlook\u2019). Het probleem hierbij is dat bij het registreren van een melding de oorzaak vaak nog niet bekend is. Wordt er in eerste instantie een verkeerde inschatting gemaakt, dan moet de categorie later alsnog worden aangepast.<\/p>\n Stem categorie\u00ebn niet uitsluitend af op de selfserviceportal.<\/strong><\/p>\n<\/li>\n<\/ul>\n Elke dienst kan uit verschillende taken bestaan voor de betrokken teams. Ook wanneer die taken in meerdere categorie\u00ebn vallen, is het belangrijk dat klanten nog steeds \u00e9\u00e9n volledige dienst als geheel ervaren.<\/p>\n Twee. Of beter gezegd: niet meer dan strikt noodzakelijk. In de meeste gevallen zijn twee niveaus van categorie\u00ebn ruim voldoende. Dit is waarom:<\/p>\n Beperk de moeite voor registratie.\u00a0<\/strong><\/p>\n<\/li>\n<\/ul>\n Je wilt niet dat je team te veel tijd kwijt is aan het registreren van telefoongesprekken. En klanten die je selfserviceportal gebruiken, moeten zonder gedoe de juiste categorie kunnen vinden. Hoe dieper je de categorie\u00ebn maakt, hoe minder transparant het overzicht wordt.<\/p>\n Maak het eenvoudig voor de servicedesk.<\/strong><\/p>\n<\/li>\n<\/ul>\n Hoe meer niveaus je toevoegt, hoe lastiger en tijdrovender het wordt om de juiste categorie te kiezen. Soms weet je w\u00e9l de juiste subcategorie, maar niet meer onder welke hoofdcategorie die valt. Dan moet je terugzoeken door meerdere lagen heen \u2013 een frustrerende klus.<\/p>\n Focus op wat nodig is.<\/strong><\/p>\n<\/li>\n<\/ul>\n Je categorie\u00ebn hoeven niet elk detail vast te leggen. Het is niet nodig incidenten op te splitsen in steeds kleinere categorie\u00ebn.<\/p>\n Dat brengt ons bij de volgende vraag\u2026<\/p>\n Soms gebruiken organisaties categorie\u00ebn om informatie vast te leggen die eigenlijk beter op een andere manier kan worden geregistreerd. Twee voorbeelden van informatie die niet thuishoren in categorie\u00ebn zijn:<\/p>\n Middelen waarop het probleem betrekking heeft.<\/strong><\/p>\n<\/li>\n<\/ul>\n Wanneer je in categorie\u00ebn specifieke middelen opneemt, bijvoorbeeld een bepaald type laptop, moeten de categorie\u00ebn worden aangepast zodra de organisatie overstapt op een nieuw type. Het is praktischer om het relevante asset direct bij het telefoongesprek te registreren en er een link naar te plaatsen.<\/p>\n Afdeling of team.<\/strong><\/p>\n<\/li>\n<\/ul>\n Regelmatig worden categorie\u00ebn ingericht op basis van afdelingen (zoals \u2018IT-diensten\u2019 of \u2018facilitaire diensten\u2019) of teams (bijvoorbeeld \u2018Databaseteam\u2019 of \u2018Applicatiebeheer\u2019). Dit levert echter problemen op, omdat bij het registreren van een telefoongesprek vaak nog niet duidelijk is welk team de melding uiteindelijk gaat afhandelen.<\/p>\n Niet echt. Net als bij het aantal niveaus geldt hier: gebruik er niet meer dan nodig is. De 7\u00d77-regel is een goed uitgangspunt. Probeer je te beperken tot 7 categorie\u00ebn en 7 subcategorie\u00ebn per categorie.<\/p>\n Maar je hoeft je hier niet strikt aan te houden. Zit je bij een servicedesk waar je met 8, 9 of 10 categorie\u00ebn beter uitkomt, dan doe je dat gewoon. Ben je meer dan 10 categorie\u00ebn aan het vastleggen, denk dan nog even goed na of je ze echt allemaal nodig hebt.<\/p>\n Deze vraag leidt vaak tot flinke discussies. Een categorie \u2018overig\u2019<\/strong> kan echter zeer nuttig zijn. Hoewel sommige professionals hier fel tegen zijn, zijn er goede redenen om deze categorie wel op te nemen.<\/p>\n Zonder een specifieke plek voor moeilijk te categoriseren incidenten, worden mensen geneigd bestaande categorie\u00ebn te gebruiken die niet goed passen. Dit ondermijnt het doel van categorisatie.<\/p>\n Met een categorie \u2018<\/strong>overig\u2019 is direct duidelijk welke incidenten lastig in te delen zijn. Bovendien biedt het waardevolle inzichten: als er regelmatig incidenten in deze categorie terechtkomen, kan dit helpen om je categorie\u00ebn te verbeteren en beter af te stemmen op de werkelijkheid.<\/p>\n Heb je eenmaal besloten welke categorie\u00ebn goed voor je werken, blijf je systeem dan regelmatig controleren en aanpassen terwijl je het gebruikt. Voer een maandelijkse beoordeling uit nadat je categorie\u00ebn zijn ingevoerd of aangepast. Na enkele maanden volstaat meestal een driemaandelijkse beoordeling. Let bij het evalueren van je categorie\u00ebn op het volgende:<\/p>\n Controleer de categorie \u2018overig\u2019.<\/strong> Bevat deze veel gesprekken, of wordt deze vaak door dezelfde teamleden gebruikt? Kijk of er een nieuwe categorie toegevoegd moet worden of dat het team meer uitleg nodig heeft over het gebruik van categorie\u00ebn.<\/p>\n<\/li>\n Evalueer het gebruik van alle categorie\u00ebn.<\/strong> Bevatten sommige categorie\u00ebn veel of juist weinig gesprekken? Overweeg categorie\u00ebn samen te voegen, te splitsen of te verwijderen. Julie Mohr geeft in een blogpost de volgende richtlijn:<\/p>\n Een CTI-element dat 25% van je ticketvolume bevat, kan duiden op een te grove structuur.<\/p>\n<\/li>\n Een CTI-element met minder dan 2% van het ticketvolume is waarschijnlijk te specifiek.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n Analyseer de oorzaken van incidenten.<\/strong> Door incidenten te categoriseren kun je terugkerende problemen en onderliggende oorzaken beter identificeren. Gebruik deze inzichten bij elke beoordeling om processen te verbeteren en herhaling te voorkomen.<\/p>\n<\/li>\n<\/ul>\n We delen regelmatig onze\u00a0best practices op het gebied van servicemanagement. Dit is een selectie van artikelen die je misschien interessant vindt:<\/p>\n \u2022\u00a0Werk jij al met een prioriteitenmatrix op je servicedesk?<\/a><\/p>\n \u2022\u00a03 redenen om jouw onboarding op orde te krijgen<\/a><\/p>\n1. Hoe kun je je categorie\u00ebn het beste ordenen?<\/h2>\n
\n
\n
2. Hoeveel niveaus hebben je categorie\u00ebn nodig?<\/h2>\n
\n
\n
\n
3. Welke informatie hoort niet in je categorie\u00ebn thuis?<\/h2>\n
\n
\n
4. Staat er een maximum op het aantal categorie\u00ebn?<\/h2>\n
5. Hebben we een categorie ‘overig’ nodig?<\/h2>\n
6. Waar moet je op letten als je je categorie\u00ebn beoordeelt?<\/h2>\n
\n
\n
Meer best practices lezen?<\/h2>\n