Request-to-Service (R2S) is the horizontal end-to-end process from incoming request to SLA reporting — the service-delivery value chain alongside Order-to-Cash and Source-to-Pay. From over 1,200 Dreher Consulting engagements we know: in the DACH Mittelstand, R2S fails not on missing tools but on an over-dimensioned ITIL role model. Contrary to ITIL textbook framing, R2S is not a pure ITSM topic but the service-side counterpart to O2C and S2P.
What Is Request-to-Service? Definition and Distinction
R2S is the end-to-end process from incoming request through classification, approval and fulfilment to SLA reporting and feedback. The Mittelstand mistake: R2S gets reduced to the service-desk ticket lifecycle and detached from value creation.
Request-to-Service covers all activities from the first request through classification as service request versus incident, approval for cost-relevant requests, standardised fulfilment via a service catalogue, closure, and evaluation against SLA and XLA. The ITIL 4 Service Request Management Practice describes the practice for pre-defined, user-initiated requests — the name change from Request Fulfilment (ITIL v3) to Service Request Management (ITIL 4) is the standard reference.
Methodologically, the APQC Process Classification Framework anchors service delivery in category 5.0 (Deliver Services) as a standalone end-to-end process group — separate from physical-product delivery. ISO/IEC 20000-1:2018 covers service request management as a normative anchor.
Three terms managing directors should keep separate:
- Request-to-Service (R2S) — the horizontal process from incoming request to SLA reporting; the service-side counterpart to O2C and S2P.
- Service Request Management (SRM) — the ITIL 4 practice for pre-defined requests; a building block within R2S.
- Incident Management — the handling of unplanned disruptions; delineated by the ITIL principle „give me something" versus „fix something".
In Porter's value chain (Porter, 1985), R2S horizontally interlocks the primary activity Service with Operations — the stretch on which vertical line organisations most often break.
Why Request-to-Service Matters in the DACH Mittelstand in 2026
Rising service pressure, increasing AI use in self-service and maturity pressure from digitalisation projects make R2S a board-level topic in 2026. Processing service requests in HR, IT and Facility silos loses steering authority over service quality and fulfilment times.
First, service pressure is rising. The Bitkom study Digitalisation of the Economy 2025 shows 53 percent of companies reporting problems managing their digitalisation. These gaps become visible exactly where the R2S process is not documented end to end.
Second, AI adoption is changing request structure. Per the same Bitkom study, around 41 percent of companies actively use AI features. Self-service portals increasingly answer routine requests such as password resets autonomously — human handling shifts to complex, cost-relevant requests. In our R2S engagements with DACH service providers, the self-service rate rises markedly once the catalogue is consolidated to a small number of request types.
Third, the DSAG Investment Report 2026 puts tool discussions under cost-effectiveness pressure. 42 percent of DACH SAP users plan S/4HANA On-Premises, 38 percent grow IT budgets purposefully. Investments follow integrability — the frame for a pragmatic R2S tool decision over a full ITIL build-out.
The R2S Method at a Glance — Four Phases, One Process Owner
We set R2S up in four numbered phases — Intake and Classification, Approval and Triage, Fulfilment and Closure, SLA Reporting and Insight. A single process ownership runs across all four phases: the R2S owner. Without that role, functional boundaries replace the value chain.
In vendor-neutral process and ERP consulting the following four-step approach has proven itself:
- Phase 1 — Intake and Classification. Capture via self-service portal, email or phone; classification as service request or incident; allocation to a catalogue entry. The request data model is decided here. ServiceNow Service Request Management describes this step as a structured intake process.
- Phase 2 — Approval and Triage. Assessment against pre-defined approval processes, escalation to finance or business unit for cost-relevant requests, allocation to an owner. The Atlassian Service Request Management Guide documents this as a standard workflow.
- Phase 3 — Fulfilment and Closure. Standardised processing via automated or manual workflows, provisioning of the service, confirmation, formal closure. In our 1,200+ projects we have seen that more than half of the loss points arise at the service-desk-to-business-unit interface.
- Phase 4 — SLA Reporting and Insight. Evaluation against Service Level Agreements (response time, resolution time, share on time) and Experience Level Agreements (XLA) — three-question micro-feedback at closure, feedback into the KPI chain First Contact Resolution, Mean Time to Fulfil, SLA Compliance, XLA Score. Only when this chain is closed does R2S become a steering basis.
An R2S owner with end-to-end accountability stands across all four phases — typically at board level. The owner question must be resolved before any tool discussion.
Practice Example: Service-Desk Consolidation at a DACH Service Provider
At a Mittelstand IT service provider with around 380 employees, three parallel service desks for IT, HR and Facility had emerged — each with its own ticketing system, catalogue and SLA logic. A typical DACH Mittelstand pattern: not a missing tool but three too many.
In our R2S engagements with DACH service providers, the employee interfaces typically tear at three points — intake-to-classification, triage-to-fulfilment and fulfilment-to-SLA-reporting. The Bitkom finding of 53 percent digitalisation problems reflects this at the macro level.
The provider with 380 employees called us because Mean Time to Fulfil had risen above 4.5 working days and the self-service rate had dropped below 15 percent. The Trovarit ERP in Practice Study 2024/25 confirms: interface maturity remains a core criterion of user satisfaction.
We worked the case in seven weeks: process capture via interviews and ticket analysis, swim-lane modelling, identification of the breakpoints, consolidation onto a single catalogue with three service lines and reduction to 22 request types. Approval workflows were recalibrated with the business-unit heads.
The solution was not a new system. Management named an R2S owner at division-head level who, with the three service-line leads, set a target process. Mean Time to Fulfil fell in two quarters to 1.8 working days; the self-service rate rose to 58 percent. The system update followed afterwards — based on a requirements specification derived from the consolidated process.
What Most Request-to-Service Guides Won't Tell You
Three points rarely spelled out in R2S guides — yet from 1,200+ Dreher engagements regularly the decisive difference between success and abandonment. Contrary to ITIL textbook framing, the critical issues are organisational — not technical.
1. R2S Is the Mittelstand-Specific E2E Business Process — Not a Pure ITSM Topic
In most online guides, R2S is framed as an ITIL practice in a service-desk tool context. That narrowing misses the Mittelstand reality: R2S is horizontally interlocked with Order-to-Cash and Source-to-Pay — approvals run through the ERP, cost postings likewise, customer communication via CRM. APQC PCF and ISO/IEC 20000 back this E2E view. Distinguish R2S explicitly from O2C and S2P before any ITSM tool is selected.
2. Three Breakpoints No Tool Fixes
From our experience, more than half of R2S loss points emerge at functional boundaries. First, intake-to-classification: when service request and incident are not cleanly classified, triage runs wrong. Second, triage-to-fulfilment: without a named owner per service line, requests sit idle. Third, fulfilment-to-SLA-reporting: when service-desk tool and ERP carry separate data models, SLA and cost posting are maintained twice. We work these breakpoints in a workshop with swim-lanes — before any new tool is selected.
3. XLA Instead of Just SLA — Experience Level Agreement as the Metric That Counts
SLAs measure whether the process ran (response time, resolution time). XLAs measure whether the user found the service helpful. In the Mittelstand, this means not an 80-indicator CSAT platform but a three-question micro-feedback at closure. In our projects we have seen XLA data regularly surface request types with green SLA but red user experience — exactly where the next catalogue iteration should adjust.
Our reading
Request-to-Service is an organisational, not a tool, topic. Whoever names the R2S owner, analyses the three breakpoints and complements SLA with XLA has done the hard 80 percent. The ITSM tool selection follows the consolidated requirements specification.
Application Across Dreher Industries
R2S scope differs between IT service providers, manufacturers with field service, and administration or shared-service organisations. We calibrate the four phases industry by industry — short fulfilment cycles and self-service in IT, field-service deployment and spare-parts requisition in manufacturing, Enterprise Service Management across HR, Facility and Legal in administration.
At IT service providers the self-service rate dominates as the central steering metric. In plant and mechanical engineering R2S as a field-service process follows a different logic: request via customer portal, dispatch via Field Service Management, spare-parts requisition via the ERP, closure with a service report — the service business grows here as a pillar of its own alongside new sales. In administration and shared-service organisations R2S broadens into Enterprise Service Management — HR, Facility and Legal run through a shared service catalogue. From our experience this consolidation reduces licence costs and avoids tool sprawl.
Frequently Asked Questions
R2S is the end-to-end service-delivery process from incoming request to SLA reporting and typically covers IT, HR and Facility services. Order-to-Cash is the stretch from order entry to payment receipt. R2S and O2C are horizontal sibling processes with different value-creation logics. The APQC framework separates them into distinct process groups. Equating the two wrongly scopes an R2S project to order processing.
From our 1,200+ engagements we recommend placing the R2S owner at board level or one tier below — operationally often the head of service. The decisive point is end-to-end authority: the owner approves changes to the catalogue, approval workflows and SLA logic. A fragmented owner structure across IT, HR and Facility silos does not work — interfaces tear exactly there. The R2S owner coordinates well with the O2C and S2P owners in a joint process-owner round.
From our R2S engagements with DACH service providers we recommend starting with a catalogue of around 20 entries — not a 200-service CMDB. In the Mittelstand only 20 to 30 request types are used regularly; each extra entry raises maintenance without user-experience gain. We consolidate in the pre-tool phase to a maximum of 25 entries, three priority levels and one process owner — then iteratively extend based on actual request frequency. Contrary to ITIL textbook framing, catalogue size is not a maturity indicator — the self-service rate and XLA score are the defensible steering metrics.
Next Steps
Before any ITSM tool or requirements-specification discussion, a brief clarification pays off: who is the R2S owner, what do the four phases look like today, where are the three typical breakpoints? Skip it and you build a catalogue no one runs.
To deepen these topics, see our process management services and ERP consulting. Complementary wiki entries: Order-to-Cash, Lead-to-Cash and Source-to-Pay. Book an initial conversation via the contact page.
30 minutes with Dreher Consulting
A structured pre-clarification of your Request-to-Service — the R2S owner, the four phases and the three typical breakpoints, vendor-neutral and drawn from over 1,200 projects in the DACH Mittelstand.
