Request Management
Not everything that reaches a service desk is an incident — most of it is a request: a new laptop, access to a system, a password reset, onboarding a joiner. Request Management turns these into structured, approvable service catalog items so every ask follows the same governed path from intake to fulfilment, instead of being improvised over email or chat. Each catalog item carries its own form, eligibility, approval chain, fulfilment steps and SLA targets, so a request arrives complete and ready to action the moment it is submitted.
Built for the way request management should work
Not everything that reaches a service desk is an incident — most of it is a request: a new laptop, access to a system, a password reset, onboarding a joiner. Request Management turns these into structured, approvable service catalog items so every ask follows the same governed path from intake to fulfilment, instead of being improvised over email or chat. Each catalog item carries its own form, eligibility, approval chain, fulfilment steps and SLA targets, so a request arrives complete and ready to action the moment it is submitted.
Inside ServiceCore, a request moves through a defined lifecycle: it is raised against a catalog item, validated against required fields, routed for the approvals that item demands, and then handed to the fulfilment team or an automated workflow. Conditional forms collect only the data a given request needs, and dynamic routing assigns the record to the right team, group or person without manual triage. Because approvals, ownership and timers are attached to the catalog item rather than the individual ticket, governance is consistent across every submission and there is nothing to remember or re-key.
Request Management shares the same data model as the rest of ServiceCore, so requests are not an island. Intake flows in from the Service Desk / Interaction Management layer, where a call or email can be converted into a request in one step; fulfilment tasks are tracked through Task Management with their own worklogs and effort; and SLA targets are measured by the same Service Level engine that governs incidents. Requests that touch infrastructure link to CIs in the CMDB, and changes to a service can be raised straight from a request, keeping the catalog, the asset estate and the approval trail in one connected picture.
The result is fulfilment that is predictable and auditable rather than ad hoc. Self-service intake lets users find and submit the right request from a published catalog; approvers act on a clear, in-context queue; and fulfilment teams work from a record that already holds everything they need. Every approval, status change and SLA breach is timestamped against the request, giving managers a measurable view of demand, throughput and cost to serve across the whole catalog.
- Service request catalog
- Approval workflows
- Standard request templates
- Self-service intake
- Fulfilment tracking
- SLA targets
What you can do with it
Service Request Catalog
Publish requestable services as structured catalog items, each with its own form, eligibility rules, approvals, fulfilment steps and SLA targets.
Approval Workflows
Attach single or multi-stage approval chains to a catalog item — sequential, parallel or conditional — so the right managers and budget owners sign off before fulfilment begins.
Conditional Request Forms
Standard templates collect exactly the data each request needs, with fields that appear or become mandatory based on earlier answers so records arrive complete.
Self-Service Intake
Users browse the published catalog and submit the correct request themselves, cutting misrouted tickets and back-and-forth clarification.
Dynamic Routing & Fulfilment Tracking
Requests assign automatically to the right team, group or person and break into trackable fulfilment tasks so progress is visible end to end.
SLA Targets per Item
Each catalog item carries its own response and fulfilment timers measured by the shared Service Level engine, with breach alerts and pause rules.
Why teams adopt it
Predictable Fulfilment
Standardized catalog items mean every request follows the same governed path, so delivery times and outcomes are consistent rather than improvised.
Built-In Governance
Approvals, eligibility and audit trails are enforced by the catalog item itself, so spend and access are controlled without manual policing.
Lower Desk Load
Self-service intake and conditional forms cut misrouted, incomplete tickets, freeing agents from triage and chasing missing details.
Measurable Demand
Every request, approval and SLA outcome is recorded against the catalog, giving managers a clear view of volume, throughput and cost to serve.
Where it fits
Employee Onboarding
A joiner request bundles laptop provisioning, system access and account setup into one catalog item with manager approval and parallel fulfilment tasks.
Software & Access Requests
Users request access to an application; the catalog item routes for line-manager and data-owner approval before the access is granted and recorded.
Hardware Provisioning
A new-laptop request captures model and cost-center on the form, triggers budget approval, and links the delivered device to the CMDB asset record.
Routine Self-Service
Common asks like password resets or distribution-list changes are fulfilled from self-service templates with little or no agent involvement.
Common questions
Incidents restore service after an unplanned disruption, while requests fulfil standard, expected asks such as access or equipment. Request Management adds a published catalog, approval chains and per-item fulfilment workflows on top of the shared data model, so the same desk handles both record types in their correct ITIL 4 lifecycles.
Part of these solutions
Related modules
See Request Management in action.
Book a demo and we'll show request management working alongside the rest of the platform — on one shared data model.