Skip to main content
Question

Analyse meldingen

  • July 28, 2026
  • 5 replies
  • 68 views

Patrick van Hoof
Forum|alt.badge.img+2

Hoi allemaal, binnen onze organisatie krijgen we vanuit functioneel beheer veel meldingen binnen. Deze meldingen zijn gecategoriseerd en willen we graag analyses uitvoeren in welke meldingen echt gebruikersvragen zijn (waarvoor kennisitems voor aangemaakt kunnen worden) en functionele meldingen/wijzigingen. Vanuit selecties kunnen we we wel bundelen welke melding betrekking heeft op een bepaalde categorie, maar inhoudelijk moeten we alle meldingen wel scannen en analyseren om te bepalen of dit een gebruikersvraag of fout betreft of een functionele melding. 

Hebben jullie hier tips voor om dit eenvoudiger te doen dan alle meldingen door te spitten?

5 replies

RinskeJansen
Forum|alt.badge.img+3

Hoi ​@Patrick van Hoof , 

wij gebruiken daarvoor het veld ‘soort melding’, waarin we dus onderscheid maken in storingen, vragen en aanvragen (hoort eigenlijk in wijzigingsbeheer, maar die wordt nog ingericht) . 

In rapportages kan ik dan binnen één categorie zien hoeveel functionele storingen er zijn, en wat er opgelost kan worden met een kennisitem(alles onder de soort vragen) en wat er aan rechten oid wordt aangevraagd. 

 

 


Patrick van Hoof
Forum|alt.badge.img+2

Hoi ​@Patrick van Hoof , 

wij gebruiken daarvoor het veld ‘soort melding’, waarin we dus onderscheid maken in storingen, vragen en aanvragen (hoort eigenlijk in wijzigingsbeheer, maar die wordt nog ingericht) . 

In rapportages kan ik dan binnen één categorie zien hoeveel functionele storingen er zijn, en wat er opgelost kan worden met een kennisitem(alles onder de soort vragen) en wat er aan rechten oid wordt aangevraagd. 

 

 

Hoi Rinske, en zetten jullie deze soort dan als behandelaar goed? Want we merken dat aanmelders niet altijd goed weten wat voor soort melding zij moeten gebruiken. Bij hen gaat er gewoon “iets” fout.


RinskeJansen
Forum|alt.badge.img+3

Hoi ​@Patrick van Hoof , 

wij gebruiken daarvoor het veld ‘soort melding’, waarin we dus onderscheid maken in storingen, vragen en aanvragen (hoort eigenlijk in wijzigingsbeheer, maar die wordt nog ingericht) . 

In rapportages kan ik dan binnen één categorie zien hoeveel functionele storingen er zijn, en wat er opgelost kan worden met een kennisitem(alles onder de soort vragen) en wat er aan rechten oid wordt aangevraagd. 

 

 

Hoi Rinske, en zetten jullie deze soort dan als behandelaar goed? Want we merken dat aanmelders niet altijd goed weten wat voor soort melding zij moeten gebruiken. Bij hen gaat er gewoon “iets” fout.

 

Hoi Patrick, 

We hebben in onze dienstenomschrijving een verwijzing naar welk formulier waarvoor gebruikt dient te worden. Dus 70-80% komt goed binnen. Maar we controleren deze invulling wel altijd, net zoals categorisatie.


tverschuur
Forum|alt.badge.img+5
  • Explorer ⭐⭐⭐⭐
  • July 28, 2026

Ik denk dat het eerst belangrijk is om te bepalen vanuit welk proces je de meldingen wilt analyseren. Veel organisaties registreren meldingen vanuit het perspectief van de gebruiker, bijvoorbeeld als Klacht, Wens, Informatie(verzoek) of Storing (KWIS of een vergelijkbare indeling). Dat werkt goed voor de intake, maar is minder geschikt wanneer je analyses wilt uitvoeren.

Als je wilt bepalen welke meldingen zich lenen voor verbeteringen of wijzigingen, is een ITIL-classificatie vaak waardevoller. ITIL maakt bijvoorbeeld onderscheid tussen:

  • Service Request – een gebruikersvraag of standaardaanvraag. Dit zijn vaak de beste kandidaten voor kennisartikelen.
  • Change (Major, Minor, Normal of Standard) – een wijzigingsverzoek.
  • Problem – de onderliggende oorzaak van één of meerdere terugkerende incidenten.

In TOPdesk maken wij daarom onderscheid tussen de verschillende beheerprocessen.

Meldingenbeheer

  • Klacht
  • Wens
  • Informatie(verzoek)
  • Storing (Incident)

KWIS beschrijft vooral hoe de klant of gebruiker de melding ervaart.

Wijzigingsbeheer

  • Change (Major, Minor, Normal of Standard)
  • Service Request (gebruikersvraag of aanvraag)

ITIL kijkt juist naar hoe de organisatie de melding afhandelt.

Probleembeheer

  • Problem (de onderliggende oorzaak van één of meerdere incidenten)

Door deze indeling te gebruiken, kunnen we veel beter analyseren hoeveel meldingen daadwerkelijk gebruikersvragen zijn, hoeveel incidenten of wijzigingsverzoeken en welke problemen structureel terugkomen. Dat maakt het eenvoudiger om trends te herkennen en gericht verbeteracties op te stellen.

 

Bij KWIS wil ik nog wel een kanttekening plaatsen. Hoewel de melding vanuit het perspectief van de gebruiker wordt geregistreerd, bepaalt uiteindelijk de behandelaar welk soort melding het daadwerkelijk is.

Een gebruiker zal bijvoorbeeld aangeven dat er sprake is van een storing omdat hij of zij niet kan inloggen. Bij onderzoek blijkt vervolgens dat het contract of de autorisatie is verlopen. Voor de gebruiker voelt dit als een storing, maar voor de behandelaar is het bijvoorbeeld een wens of informatieverzoek, omdat er geen technisch probleem is.

Een ander voorbeeld is een melding dat het veel te koud is in een kantoor. De gebruiker ervaart dit misschien als een klacht, maar de behandelaar zal eerst onderzoeken wat de oorzaak is. Blijkt de verwarming defect, dan is het een storing. Is de temperatuur verkeerd ingesteld of is uitleg nodig over de bediening, dan kan het juist een informatieverzoek zijn.

Een klacht gaat meestal niet over het technische probleem zelf, maar over de manier waarop een product of dienst is geleverd. Bijvoorbeeld: de wens was om een ruimte opnieuw te schilderen. Het schilderwerk is uitgevoerd, maar er is slecht schoongemaakt of afspraken zijn niet nagekomen. De klacht gaat dan over de kwaliteit van de dienstverlening, niet over de oorspronkelijke wens.

Daarom is het belangrijk dat de behandelaar de melding niet alleen registreert zoals de gebruiker deze ervaart, maar ook classificeert op basis van de daadwerkelijke oorzaak of de juiste afhandeling. Dat levert veel betrouwbaardere analyses en rapportages op.

 


Patrick van Hoof
Forum|alt.badge.img+2

Ik denk dat het eerst belangrijk is om te bepalen vanuit welk proces je de meldingen wilt analyseren. Veel organisaties registreren meldingen vanuit het perspectief van de gebruiker, bijvoorbeeld als Klacht, Wens, Informatie(verzoek) of Storing (KWIS of een vergelijkbare indeling). Dat werkt goed voor de intake, maar is minder geschikt wanneer je analyses wilt uitvoeren.

Als je wilt bepalen welke meldingen zich lenen voor verbeteringen of wijzigingen, is een ITIL-classificatie vaak waardevoller. ITIL maakt bijvoorbeeld onderscheid tussen:

  • Service Request – een gebruikersvraag of standaardaanvraag. Dit zijn vaak de beste kandidaten voor kennisartikelen.
  • Change (Major, Minor, Normal of Standard) – een wijzigingsverzoek.
  • Problem – de onderliggende oorzaak van één of meerdere terugkerende incidenten.

In TOPdesk maken wij daarom onderscheid tussen de verschillende beheerprocessen.

Meldingenbeheer

  • Klacht
  • Wens
  • Informatie(verzoek)
  • Storing (Incident)

KWIS beschrijft vooral hoe de klant of gebruiker de melding ervaart.

Wijzigingsbeheer

  • Change (Major, Minor, Normal of Standard)
  • Service Request (gebruikersvraag of aanvraag)

ITIL kijkt juist naar hoe de organisatie de melding afhandelt.

Probleembeheer

  • Problem (de onderliggende oorzaak van één of meerdere incidenten)

Door deze indeling te gebruiken, kunnen we veel beter analyseren hoeveel meldingen daadwerkelijk gebruikersvragen zijn, hoeveel incidenten of wijzigingsverzoeken en welke problemen structureel terugkomen. Dat maakt het eenvoudiger om trends te herkennen en gericht verbeteracties op te stellen.

 

Bij KWIS wil ik nog wel een kanttekening plaatsen. Hoewel de melding vanuit het perspectief van de gebruiker wordt geregistreerd, bepaalt uiteindelijk de behandelaar welk soort melding het daadwerkelijk is.

Een gebruiker zal bijvoorbeeld aangeven dat er sprake is van een storing omdat hij of zij niet kan inloggen. Bij onderzoek blijkt vervolgens dat het contract of de autorisatie is verlopen. Voor de gebruiker voelt dit als een storing, maar voor de behandelaar is het bijvoorbeeld een wens of informatieverzoek, omdat er geen technisch probleem is.

Een ander voorbeeld is een melding dat het veel te koud is in een kantoor. De gebruiker ervaart dit misschien als een klacht, maar de behandelaar zal eerst onderzoeken wat de oorzaak is. Blijkt de verwarming defect, dan is het een storing. Is de temperatuur verkeerd ingesteld of is uitleg nodig over de bediening, dan kan het juist een informatieverzoek zijn.

Een klacht gaat meestal niet over het technische probleem zelf, maar over de manier waarop een product of dienst is geleverd. Bijvoorbeeld: de wens was om een ruimte opnieuw te schilderen. Het schilderwerk is uitgevoerd, maar er is slecht schoongemaakt of afspraken zijn niet nagekomen. De klacht gaat dan over de kwaliteit van de dienstverlening, niet over de oorspronkelijke wens.

Daarom is het belangrijk dat de behandelaar de melding niet alleen registreert zoals de gebruiker deze ervaart, maar ook classificeert op basis van de daadwerkelijke oorzaak of de juiste afhandeling. Dat levert veel betrouwbaardere analyses en rapportages op.

 

Dankjewel voor je uitgebreide tip, daar kunnen we zeker wat mee! En ben het er helemaal mee eens dat de behandelaar van de melding goed kan inschatten wat voor soort melding het betreft en dit anders kan zijn in de ogen van de aanmelder.