ServiceNow Australia-release: Action Fabric en MCP-server uitgelegd
Ontdek hoe de ServiceNow MCP-server AI-agenten verbindt met beheerde ITSM-workflows, Action Fabric en veilige bedrijfsautomatisering, plus stappen voor 2026.
Read more →ITIL 4-praktijk · Serviceaanvragen
Service request management: een aanvraagproces dat gebruikers echt gebruiken
Service request management maakt IT-aanvragen gestructureerd, opvolgbaar en consequent afgehandeld: toegang, materiaal, software, informatie. Goed ingericht neemt het repetitief werk weg bij de servicedesk, krijgen gebruikers een portaal dat ze vertrouwen en ziet het IT-management wat er gevraagd wordt en hoe snel het geleverd wordt. Onze ITIL v4-gecertificeerde consultants ontwerpen de servicecatalogus, formulieren, goedkeuringen en SLA's, en richten ze in in uw tool.
180ITSM-implementaties
40+ITSM-migraties
20jaar ervaring in IT-servicemanagement
Zij vertrouwen ons hun ITSM-projecten toe
Wat is service request management?
Service request management is de ITIL 4-praktijk die vooraf bepaalde aanvragen van gebruikers consequent en efficiënt afhandelt. Een serviceaanvraag gaat over iets waar een gebruiker recht op heeft: een account voor een nieuwe medewerker, een laptop, toegang tot een applicatie, een gedeelde mailbox. Het is geen storing en geen klacht; de afhandeling is vooraf gekend. Het is een van de kernpraktijken van ITSM, naast incident-, problem- en change management.
Dat onderscheidt het van incident management. Een incident is onverwacht en vraagt een diagnose; een aanvraag is voorzien en volgt een standaardworkflow met een eigen SLA. Beide in Ă©Ă©n wachtrij steken is de meest voorkomende reden waarom SLA's voor aanvragen niet gehaald worden: incidenten worden als aanvragen behandeld, aanvragen wachten achter incidenten, en geen van beide processen werkt.
Wat hoort in een servicecatalogus?
De servicecatalogus is de lijst van diensten die IT levert, elk met een uitvoeringsprocedure, een eigenaar, de nodige goedkeuringen en een SLA die de gebruiker ziet bij het indienen. De meeste IT-catalogi dekken vier families:
| Familie | Voorbeelden |
|---|---|
| Toegang en identiteit | Account voor een nieuwe medewerker, wijziging van rechten, roltoewijzing, account deblokkeren, vertrek |
| Hardware en materiaal | Laptop, smartphone, scherm en randapparatuur, vervangtoestel |
| Software en licenties | Software-installatie, licentietoewijzing, toegang tot een applicatie, abonnement |
| IT-diensten en infrastructuur | VPN-toegang, gedeelde mailbox, distributielijst, cloudresource, netwerktoegang |
Hoe groot bij de start? Kleiner dan de meeste teams denken:
| Fase | Scope |
|---|---|
| Start | Alleen de meest gevraagde items, doorgaans 15 tot 25, elk met een geteste procedure en een haalbare SLA |
| Uitbreiden | Nieuwe items wanneer de ticketdata een terugkerende aanvraag via e-mail of telefoon toont |
| Onderhouden | Een driemaandelijkse review: ongebruikte items schrappen, procedures bijwerken, SLA's toetsen aan de realiteit |
Kan het team zich niet vastleggen op een doorlooptijd, dan is het item niet klaar om te publiceren. Een correcte catalogus van twintig items doet meer voor de adoptie dan een volledige catalogus waarvan de helft van de procedures verouderd is.
Waarom selfserviceportalen mislukken (en hoe u de adoptie herstelt)
De catalogus spreekt IT, niet gebruiker
De categorieën volgen de IT-organisatie, niet wat gebruikers zoeken. Niemand zoekt "levenscyclus van eindgebruikersassets" als hij een nieuwe laptop nodig heeft.
Formulieren vragen te veel
Lange, vaste formulieren vragen informatie die de gebruiker niet heeft. Dynamische formulieren die stap voor stap alleen het nodige vragen, worden wel ingevuld.
Geen zicht na het indienen
Wie niet ziet waar zijn aanvraag staat, volgt op via e-mail of telefoon, en het portaal verliest zijn nut.
Niemand onderhoudt het
Items stapelen zich op, procedures verouderen, SLA's schuiven en gebruikers keren terug naar informele kanalen. Selfservice is een kwestie van dienstontwerp en governance, geen toolinstelling.
Hoe SMC Consulting uw aanvraagproces inricht
Request management is evenveel dienstontwerp als platformconfiguratie. Wij richten het native in in de tool die uw team al gebruikt, op elk van de 10 ITSM-platformen waarop wij werken; ligt een toolwissel op tafel, dan is HaloITSM onze keuze voor de meeste middelgrote organisaties. Ons advies is onafhankelijk. Kiest u HaloITSM, dan kunnen wij ook de licenties leveren als gecertificeerde partner, en dat zeggen wij u vooraf.
Ontwerp van de servicecatalogus
Items gedefinieerd, gestructureerd en geprioriteerd met de IT-stakeholders, geschreven in de woorden van de gebruikers, elk met een SLA, goedkeuringsketen en procedure.
Selfserviceportaal
Logische categorieën, dynamische formulieren, duidelijke status en mobiele toegang. Adoptie volgt gebruiksgemak, niet interne communicatiecampagnes.
Goedkeuringsworkflows
Goedkeuringen op meerdere niveaus in het platform, met termijnen, escalatie en audittrail, in plaats van e-mailthreads die niemand beantwoordt.
Automatisering van de afhandeling
Provisioning in de directory, endpointbeheer, identiteits- en cloudintegraties: elke geautomatiseerde stap is een manuele taak minder.
Koppeling met assetbeheer
Hardware en software die via een aanvraag geleverd worden, maken of werken het assetrecord bij op het moment van levering, niet weken later met de hand.
Rapportering en verbetering
Doorlooptijd per item, SLA-overschrijdingen, knelpunten in goedkeuringen en meest gevraagde diensten, besproken om te beslissen wat u daarna automatiseert.
De levenscyclus van een aanvraag in 6 stappen
Van de klik van de gebruiker tot het afgesloten dossier. Elke stap is een configuratiekeuze in de tool; ze op de standaardinstelling laten is waar de meeste aanvraagprocessen beginnen te ontsporen.
Indienen
De gebruiker kiest een item in de catalogus; een dynamisch formulier vraagt precies wat de afhandeling nodig heeft, in begrijpelijke taal.
Validatie en routering
De aanvraag wordt gecontroleerd, geclassificeerd en gerouteerd: standaarditems gaan rechtstreeks naar afhandeling, andere naar de juiste goedkeurder.
Goedkeuring
Goedkeuring door manager, security of financiën waar nodig, met termijnen en escalatie ingesteld in het platform.
Afhandeling
De gedocumenteerde procedure wordt gevolgd, waar mogelijk geautomatiseerd, en toegewezen aan het juiste team terwijl de SLA-klok loopt.
Melding en bevestiging
De gebruiker wordt bij elke stap op de hoogte gehouden en bevestigt dat de aanvraag is afgehandeld.
Afsluiting en rapportering
Een volledig dossier voedt de rapporten die tonen welke items u daarna verbetert of automatiseert.
Een portaal dat niemand gebruikt, of goedkeuringen die vastzitten in mailboxen?
In een gratis audit van 30 minuten overloopt een senior consultant met u uw catalogus, portaal en aanvraagworkflows, en u krijgt uw drie prioriteiten.
Wat er verandert voor gebruikers en voor IT
- EĂ©n plek om alles aan te vragen wat IT levert, met de verwachte levertijd vooraf zichtbaar
- Aanvragen die volledig binnenkomen, zonder heen-en-weer
- Goedkeuringen in de tool, met een spoor
- Incidenten en aanvragen in aparte wachtrijen, elk met een gehaalde SLA
- Minder manuele afhandeling voor de servicedesk
- Cijfers die tonen wat gebruikers vragen en waar tijd verloren gaat
Automatisering en AI voor aanvragen
De afhandeling automatiseren
Accounts aanmaken, toegangsrechten, softwaredistributie en meldingen zijn de eerste kandidaten. Zet de procedure recht en automatiseer ze dan.
AI bij de registratie
AI classificeert aanvragen, ziet ontbrekende informatie vóór het indienen en beantwoordt routinevragen over de status via chat of spraak.
Verder dan IT
Hetzelfde catalogusmodel werkt voor aanvragen bij HR, facilitair beheer en financiën, zodra de IT-catalogus goed draait.
Voor wie
Servicedeskmanagers
Wier team de dagen vult met repetitieve aanvragen die onvolledig binnenkomen via e-mail en telefoon.
IT-managers en CIO's
Die voorspelbare levertijden en een duidelijk zicht willen op wat de business aan IT vraagt.
Proces- en catalogeigenaars
Die een catalogus, goedkeuringen en SLA's nodig hebben die ook na de livegang correct blijven.
KPI's voor service request management
| KPI | Wat hij u vertelt |
|---|---|
| Doorlooptijd per item | De gemiddelde tijd tussen indienen en levering, gemeten per catalogusitem in plaats van als Ă©Ă©n globaal gemiddelde. |
| SLA-naleving | Het aandeel aanvragen dat binnen de beloofde tijd geleverd wordt; een blijvende kloof betekent dat de SLA, de bezetting of de goedkeuringen werk vragen. |
| Selfservice-adoptie | Het aandeel aanvragen dat via het portaal binnenkomt in plaats van via e-mail of telefoon. |
| Afhandeling in Ă©Ă©n keer | Aanvragen geleverd zonder herwerk of extra vraag om verduidelijking; een lage score wijst op onvolledige formulieren. |
| Gebruikerstevredenheid (CSAT) | Hoe gebruikers de ervaring bij afsluiting beoordelen: de indicator die de business als eerste ziet. |
Definities en dashboardvoorbeelden vindt u in onze gids over servicedesk-KPI's.
Service request management: veelgestelde vragen
Wat is het verschil tussen een serviceaanvraag en een incident?
Een incident is een ongeplande onderbreking die triage en diagnose vraagt. Een serviceaanvraag is een vooraf bepaalde behoefte die IT routinematig afhandelt, met een vooraf gekend pad. Beide in dezelfde wachtrij afhandelen schaadt beide. Zie incident management voor hoe ze samenhangen.
Wat is een servicecatalogus en waarom is hij belangrijk?
De gestructureerde lijst van diensten die IT levert, elk met een procedure, een SLA en een goedkeuringsketen. Zonder catalogus wordt elke aanvraag ad hoc behandeld en weten gebruikers niet wat IT voor hen kan doen. Een gepubliceerde, onderhouden catalogus is ook de belangrijkste motor van portaaladoptie.
Hoe groot moet een servicecatalogus zijn bij de start?
Begin met de meest gevraagde items, doorgaans 15 tot 25, elk met een geteste procedure en een SLA die het team kan halen. Voeg items toe wanneer de ticketdata een terugkerende aanvraag buiten het portaal toont. Juistheid weegt zwaarder dan volledigheid.
Hoe verhogen we de adoptie van het selfserviceportaal?
Maak het portaal sneller en eenvoudiger dan een e-mail: items die gebruikers in een paar klikken vinden, korte formulieren en een status die ze zonder navraag kunnen volgen. Houd daarna de catalogus correct. Kost het portaal meer moeite dan de alternatieven, dan redt geen enkele communicatiecampagne de adoptie.
Hoe vermindert automatisering de IT-werklast bij serviceaanvragen?
Door manuele stappen weg te halen uit frequente, eenvoudige aanvragen: accounts aanmaken, toegangsrechten, softwaredistributie, licentietoewijzing en meldingen. Elke geautomatiseerde stap maakt tijd vrij voor werk met meer waarde. Lees meer over ITSM-automatisering en -orkestratie.
Hoe hangt service request management samen met IT-assetbeheer?
Hardware en software die via een aanvraag geleverd worden, moeten het assetrecord aanmaken of bijwerken op het moment van levering. Platformen die aanvragen en assets native koppelen, doen dat automatisch. Zie IT-assetbeheer.
Hoe lang duurt het om een aanvraagproces in te richten?
Dat hangt af van het aantal catalogusitems, de goedkeuringen en de integraties. De basiscatalogus, het portaal en de goedkeuringsworkflows komen eerst; automatisering van de afhandeling en integratie met de directory volgen. De diagnose van twee weken in onze methode geeft u een gedateerd plan op basis van uw eigen ticketdata.
Werkt u alleen met HaloITSM?
Nee. Wij richten request management in in de tool die u al gebruikt, op elk van de 10 ITSM-platformen waarop wij werken. HaloITSM is onze keuze wanneer een toolwissel op tafel ligt.
IT-aanvragen zijn voorspelbaar. Hun afhandeling zou dat ook moeten zijn.
Boek uw gratis ITSM-audit van 30 minuten. Een senior consultant overloopt uw catalogus, portaal en workflows en geeft u uw drie prioriteiten.
Recente artikelen
De HaloITSM CMDB automatisch vullen met Lansweeper discovery-data
Ontdek hoe een HaloITSM Lansweeper-integratie discovery-data koppelt aan HaloITSM voor zuiverdere CMDB-records, snellere triage en betere change-beslissingen.
Read more →
ServiceNow migratie cutover-plan: data, integraties en risicobeheer
Een praktisch ServiceNow migratie cutover-plan helpt risico's te beperken, de servicecontinuĂŻteit te beschermen en een zelfverzekerde ITSM-modernisering te ondersteunen.
Read more →