Request-to-Fulfill(R2F)
From a request in the service portal to confirmed delivery: how the request-to-fulfill process runs, how it is measured and where standard requests wait longer than they should.
Also known as: R2F · Request to Fulfill · Request-to-Fulfil · Service request management · Request fulfilment
What is Request-to-Fulfill?
Request-to-fulfill (R2F) is the end-to-end process from a request for an IT service to its confirmed delivery. It covers choosing an offering in the service catalogue or self-service portal, business and, where needed, financial approval, fulfilment – such as access rights, hardware, software licences or the IT equipment for new joiners, partly via purchasing – handover with confirmation by the requester, and closing the request. The IT4IT value stream model and the ITIL practice of service request management describe this flow; in day-to-day work it determines how quickly employees are able to do their jobs.
Starts with
An employee or manager requests a service from the service catalogue.
Ends with
The service is delivered, confirmed by the requester and the request is closed.
Typical phases
- 1
Request via service catalogue
In the self-service portal, the requester selects a catalogue offering and fills in its form. The catalogue item and form define which data, approvals and fulfilment steps follow.
- Catalogue offering selected
- Request submitted
- Request completed
- Request categorised
- 2
Approval
Depending on the service, line managers, cost centre owners or data owners approve the request. Critical access rights require additional checks.
- Approval requested
- Query raised
- Request approved
- Request rejected
- 3
Fulfilment
Fulfilment tasks are routed to the responsible teams or run automatically: granting access, deploying software, issuing a device from stock or procuring it through a purchase order.
- Fulfilment task created
- Task assigned
- Access granted
- Purchase order triggered
- Device configured
- 4
Handover & closure
The service is handed over, the requester confirms delivery and the request is closed – with a satisfaction survey where required.
- Service handed over
- Delivery confirmed
- Request closed
Business objects and systems
These are the objects the process leaves in the source systems – with timestamps, owners and relationships to each other.
- Service request
- The request with requester, catalogue offering, priority, SLA and a status from submitted to closed.
- Catalogue offering
- An item in the service catalogue with its form, approval rule and defined fulfilment flow.
- Approval
- Approval or rejection by a responsible person, with time and reason.
- Fulfilment task
- A work step for a team or an automation, with assignment, waiting time and outcome.
- Purchase order
- Procurement of hardware or licences when the need cannot be met from stock.
- Configuration item
- The delivered device, licence or access right as recorded in the CMDB.
Typical source systems
- IT service management platforms (e.g. ServiceNow, Jira Service Management, BMC Helix)
- Identity and access management
- Software distribution and endpoint management
- ERP or procurement system for purchase orders
KPIs that can be measured
- Cycle time per catalogue offering
- Time from the submitted request to confirmed delivery.
- SLA compliance
- Share of requests fulfilled within the agreed service time.
- Approval duration
- Waiting time between requesting an approval and the decision.
- Automation rate
- Share of fulfilment tasks that run without manual intervention.
- Reopen rate
- Share of requests reopened or reworked after closure.
Typical problems
Waiting for approvals
Multi-level approvals and queries often account for most of the cycle time, even though the actual fulfilment would be done quickly.
Manual work on standard requests
Recurring requests such as access rights or software installations go through manual tasks and team hand-offs despite clear rules.
Procurement as a black box
As soon as a device has to be ordered, the service desk loses sight of the request. How long the purchase order, delivery and goods receipt take is recorded in another system.
Inconsistent paths per catalogue offering
Forms are submitted incomplete, tasks are passed between teams or steps are done outside the tool – the same service runs differently every time.
How Noreja analyses Request-to-Fulfill
A service request breaks down into approvals, several fulfilment tasks and sometimes a purchase order in the procurement system – each with its own timestamps and owners. A flat event log with the request as its case ID only shows the overall duration. Noreja connects request, tasks, purchase order and configuration item in the event knowledge graph, revealing whether time is lost in approval, in the fulfilment team or in delivery.
For each catalogue offering, the intended fulfilment flow is modelled as the expected order. This highlights where approvals are skipped, tasks are created twice or requests are closed before the service is actually available.
Questions Noreja answers
- Which catalogue offerings miss their SLAs most often?
- How much of the cycle time is spent on approvals and queries?
- Which standard requests are suitable for full automation?
- How long do requests involving procurement wait for ordering and delivery?
- Where are tasks passed back and forth between teams?
- How reliably is the IT equipment for new joiners ready on their first day?
Matching agents from the Minerva Agent Library
Frequently asked questions about Request-to-Fulfill
What is the request-to-fulfill process?
Request-to-fulfill (R2F) is the end-to-end process from a request for an IT service to its confirmed delivery. It covers the request via the service catalogue, approval, fulfilment – such as access rights, hardware or software – handover and closure.
What is the difference between request-to-fulfill and issue-to-resolution?
Request-to-fulfill handles planned requests for a standard service, such as a new laptop or an access right. Issue-to-resolution covers incidents and customer service tickets, where something does not work and has to be restored.
Which KPIs matter in request-to-fulfill?
Typical KPIs are cycle time per catalogue offering, SLA compliance, approval duration, the automation rate of fulfilment tasks and the reopen rate.
Can process mining be used in IT service management?
Yes. Requests, approvals, tasks and status changes leave timestamps and assignments in the ITSM platform, purchase orders in the ERP. Process mining shows the actual flow per service, waiting times between teams and candidates for automation.
Demo cases with a worked-through analysis
End-to-end processes we have played through with findings, causes and measures – some of them touching Request-to-Fulfill.
Understand your process causally — talk to us
Join companies that are redefining growth and efficiency with intelligent process analysis.