Je hebt net een nieuw ticketsysteem geïnstalleerd. Alles is schoon, overzichtelijk, logisch. En dan?
▶Inhoudsopgave
Drie maanden later heeft iemand een categorie “Diversen” gemaakt. Daarna “Diversen 2”. En dan “Diversen_FINAL_v3”. Als je niet opletten, wordt je hele systeem een digitale rommelbak waar nog geen mens iets meer kan vinden.
Maar het hoeft helemaal niet zo te zijn. Met een paar slimme keuzes vandaag, bouw je een structuur die over twee jaar nog stevig staat. Geen rommelbak. Geen frustratie. Gewoon helder.
Waarom de meeste ticketcategorieën al snel kapot gaan
Het probleem zit hem niet in het systeem. Het zit hem in hoe mensen denken over categorieën.
De meeste teams beginnen met wat ze nu nodig hebben. En dat klinkt logisch, maar het is precies waar het misgaat. Stel: je hebt vijf medewerkers en drie soorten problemen.
Dan maak je drie categorieën. Makkelijk. Maar over een jaar heb je twintig medewerkers, een nieuw product, en plotseling ook externe klanten die tickets sturen. Die drie categorieën?
Die zijn dan zo nutteloos als een paraplu in de woestijn. De fout die bijna iedereen maakt: je categoriseert op basis van problemen, niet op basis van structuur. En dat is een wereld van verschil.
Begin niet met wat je nu hebt, maar met wat je systeem moet doen
Een goede ticketcategorie zegt iets over de aard van het verzoek, niet over de specifieke inhoud. Dat klinkt abstract, maar het is eigenlijk heel simpel. Kijk naar hoe grote helpdesks het doen.
Bijvoorbeeld bij bedrijven die Freshdesk of Zendes gebruiken. Zij werken vaak met een vaste set hoofdcategorieën die losstaan van afdelingen of producten.
- Technisch probleem — iets werkt niet
- Vraag over gebruik — hoe werkt dit?
- Factuur of betaling — geldzaken
- Account of toegang — inloggen, rechten, wachtwoorden
- Suggestie of feedback — ideeën van buitenaf
Denk aan dingen als: Zie je het patroon?
De gouden regel: maximaal zeven hoofdcategorieën
Deze categorieën veranderen niet als je een nieuw product lanceert of een team uitbreiden. Ze zijn functioneel, niet inhoudelijk. En dat maakt ze bestendig.
Ja, echt. Zeven. Niet twintig. Niet vijftien. Zeven. Waarom?
Omdat mensen niet goed kiezen uit meer dan zeven opties. Dat is geen mening, dat is cognitieve psychologie. Het heet de wet van Miller, en die bestaat al sinds 1956. Als je meer dan zeven hoofdcategorieën hebt, beginnen mensen te raden in plaats van kiezen.
En raden betekent fouten. Fouten betekenen verkeerd gerouteerde tickets.
En dat betekent wachttijd. Minder is meer.
Vooral als je wilt dat het over twee jaar nog klopt.
Gebruik subcategorieën als sparringspartner, niet als vluchtmogelijkheid
Hier gaat het bij veel teams mis. Ze voegen een subcategorie toe omdat ze even niet weten waar iets heen moet. En dan blijft die hangen. Voor altijd.
Subcategorieën zijn krachtig, maar alleen als ze één ding doen: verfijnen, niet vervangen. Een goed voorbeeld:
Hoofdcategorie: Technisch probleem
Subcategorie: App crasht bij inloggen
Dat werkt. De hoofdcategorie vertelt het systeem waar het ticket heen moet. De subcategorie helpt de medewerker om, zoals beschreven in ons intern helpdesk handboek, sneller te begrijpen wat er aan de hand is.
Een slecht voorbeeld:
Hoofdcategorie: Diversen
Subcategorie: Alles wat niet past
Dat is geen structuur. Dat is een afvalbak met een label.
Geef elke subcategorie een duidelijke eigenaar
Elke subcategorie moet één persoon of één team hebben die er verantwoordelijk voor is. Niet twee teams. Niet “wie het eerste pikt”. Eén eigenaar.
Waarom? Omdat verantwoordelijkheid zorgt voor onderhoud. Als iemand eigenaar is van een categorie, houdt die persoon ook in de gaten of de categorie nog klopt. Of er te veel tickets in landen. Of de naam nog logisch is.
Zonder eigenaar wordt elke categorie uiteindelijk slopend.
Test je structuur met de “over-2-jaar-test”
Voordat je je categorieën definitief maakt, doe dan dit: stel je voor dat je over twee jaar een compleet nieuw product hebt. Een nieuwe doelgroep. Misschien zelfs een nieuwe markt.
Vragen die je jezelf moet stellen: Als je antwoord op de laatste vraag “ja” is, dan zit je goed. Als je moet beginnen met “nou, eigenlijk moet ik alles herschrijven”, dan is je structuur te fragiel.
- Passen mijn huidige categorieën dan nog?
- Moet ik dan compleet opnieuw beginnen?
- Of kan ik gewoon een subcategorie toevoegen zonder de hele boom omver te gooien?
Een voorbeeld uit de praktijk: een middelgroot SaaS-bedrijf in Nederland had ooit vijftien hoofdcategorieën.
Na een herstructurering gingen ze naar zes. Het resultaat? Dertig procent minder verkeerd gerouteerde tickets. En medewerkers die eindelijk wisten waar ze moesten zoeken, mede door het vermijden van veelgemaakte fouten bij het inrichten.
Documenteer je keuzes, ook als ze vandaag logisch lijken
Vandaag weet je precies waarom je “Factuurproblemen” gescheiden hebt van “Betalingsvragen”. Maar over twee jaar weet niemand dat meer.
En dan komt er iemand die denkt: “Laten we die samenvoegen, toch?”
En dan ben je terwaar bij af. Bouw een kennisbank op die je team écht gebruikt door op te schrijven waarom je bepaalde keuzes maakt. Niet een hele handleiding.
Gewoon een paar zinnen per categorie. Waarom bestaat deze? Wat valt eronder? Wat valt er niet onder? Dat kost vandaag vijf minuten. Over twee jaar bespaart het je uren van verwarring.
Maak het een gewoonte om elk jaar te reviewen
Zet het in je agenda. Eén keer per jaar, bijvoorbeeld in januari, kijk je naar je categorieën.
Niet om alles te veranderen. Maar om te checken of het nog klopt.
Stel je zoekt naar een categorie die in het afgelopen jaar minder dan tien tickets heeft gehad. Dan is het tijd om te vragen: bestaat deze nog wel? Of is het tijd om het samen te voegen met iets anders?
Je wilt niet te snel schrappen. Maar je wilt ook niet wachten tot je systeem een museum is van categorieën die niemand meer gebruikt.
Het geheim is simpel: bouw voor structuur, niet voor nu
Ticketcategorieën zijn geen lijstje van wat je vandaag nodig hebben. Ze zijn het skelet van hoe je organisatie informatie verwerkt.
En skeletten moeten stevig zijn, anders valt alles in elkaar. Dus begin klein. Maximaal zeven hoofdcategorieën. Duidelijke subcategorieën met eigenaren. Documentatie van je keuzes.
En een jaarlijkse check. Dat is het geen ingewikkelde formule. Geen duur systeem.
Gewoon een paar keuzes die ervoor zorgen dat je over twee jaar niet hoeft te beginnen met het opruimen van je eigen rommel.
En echt, dat is het waard.
Veelgestelde vragen
Waarom ontstaan er vaak te veel ticketcategorieën in een ticketsysteem?
Veel teams creëren initially categorieën op basis van hun huidige behoeften, wat vaak leidt tot een overvloed aan categorieën. Na verloop van tijd, met nieuwe medewerkers, producten en klanten, worden deze categorieën onbruikbaar en rommelig. Het is daarom belangrijk om te beginnen met een gestructureerde aanpak.
Hoe kan ik ervoor zorgen dat mijn ticketcategorieën over twee jaar nog relevant blijven?
Om ervoor te zorgen dat je ticketcategorieën over twee jaar nog bruikbaar zijn, is het essentieel om ze te baseren op de aard van het verzoek, in plaats van op specifieke inhoud. Denk na over de fundamentele categorieën die je systeem nodig heeft, zoals technische problemen, vragen over gebruik, facturen en accountproblemen, en houd deze consistent.
Wat is de maximale hoeveelheid hoofdcategorieën die ik zou moeten gebruiken?
Op basis van cognitieve psychologie, is het aan te raden om maximaal zeven hoofdcategorieën te gebruiken. Meer dan zeven opties kan leiden tot verwarring en fouten bij het categoriseren van tickets, waardoor ze minder effectief worden. Het is beter om minder, maar duidelijke categorieën te hebben.
Hoe kan ik subcategorieën effectief gebruiken in mijn ticketsysteem?
Subcategorieën zijn nuttig als sparringspartner om de hoofdcategorieën te verfijnen, maar ze mogen niet gebruikt worden als een manier om de hoofdcategorieën te ontwijken. Gebruik ze om specifieke onderwerpen binnen een hoofdcategorie verder te specificeren, maar houd het aantal hoofdcategorieën beperkt.
Welke voorbeelden van hoofdcategorieën kunnen nuttig zijn in een ticketsysteem?
Goede voorbeelden van hoofdcategorieën zijn technische problemen (zoals een applicatie die niet werkt), vragen over gebruik (zoals hoe een bepaalde functie te gebruiken), facturen of betalingen, en account- of toegangsproblemen. Deze basiscategorieën zijn vaak consistent over verschillende producten en teams.