Most IT professionals know that the service request process looks good… on paper. A request comes in, someone approves it, IT fulfills it, and the ticket closes, voilà. But the truth is far from this.
When you run the workflow with real people and real systems, hiccups are bound to happen. If you’ve been there, this guide shows you how to build a service request management process that still works when the request stalls, changes hands, or fails. You’ll finish with a process specification your team can configure in an AI-native ITSM platform like Ravenna and test before it reaches employees.
What is service request management?
Before we get started, let’s go over some of the basics. The core idea behind service request management is to automate repetitive, time-consuming requests that follow a set resolution path in a consistent, user-friendly way.
Now that we know the basics, how do we actually automate these requests?
1. Choose one request to standardize first
Start with one request your team sees often and understands well; do not pick the request type that’s the hardest or takes the most time to resolve fully. We’ve covered how to pick the candidates for automation here.
A good first candidate has:
A clear outcome
Known eligibility rules
Repeatable fulfillment steps
One team that can own the result
Enough volume to make the work worthwhile
We’ll use a software access request for editor access to an approved SaaS application throughout this guide. Why? Because it has a defined requester, application, permission level, eligibility rule, and an outcome you can verify.
2. Define what you need before work starts
A form should collect information the requester knows. Your systems should supply the rest.
For the SAR, ask the employee which approved application they need, the access level, why they need it, and how long they expect to need it. Pull their department, manager, group membership, and current access from connected systems when that data already exists.
Every field needs a reason to exist. Use it to decide eligibility, route work, fulfill the request, or prove completion. If a field does none of those jobs, remove it.
In Ravenna, forms support system and custom fields, conditional visibility, default ticket values, audience controls, and a draft state for review before publication. A form submission can also start a workflow, with its field values available to later actions.
Your specification for each input should include:
Input | Source | Required | Used for |
|---|---|---|---|
Requester | Identity record | Yes | Eligibility and communication |
Application | Request form | Yes | Policy and fulfillment path |
Access level | Request form | Yes | Policy and provisioning path |
Manager | Directory or HRIS | When approval applies | Approval routing |
Business reason | Request form | For elevated or exception access | Approval and expiry |
3. Give every state an owner and an exit condition
A status is useful only when it tells everyone what must happen next.
Map the request from intake to closure. For each state, name the owner, the exit condition, and the evidence the process must retain.
State | Owner | Exit condition | Evidence |
|---|---|---|---|
Submitted | Service desk | Required inputs are present | Completed form |
Eligibility check | IT workflow or agent | Policy returns allowed, denied, or review | Policy result |
Waiting for approval | Named approver | Approval, decline, or timeout | Decision and timestamp |
Fulfillment | Identity team, application owner, or workflow | Provisioning action returns a result | Workflow run, application, and access level |
Verification | Service desk or workflow | Requested role is confirmed in the target system | Identity-provider or application response |
Completed | Service desk | Requester is notified and outcome recorded | Completion message |
The ticket should keep one accountable owner even when several people perform tasks. Ravenna tickets distinguish the requester, assignee, followers, and stakeholders, while task templates can assign repeatable work inside a ticket. That gives you a way to coordinate handoffs without making ownership disappear between teams.
Custom statuses can also separate “Waiting on requester” from “Waiting on approval.” Both pause work, but they point to different people and should trigger different reminders.
4. Write the approval rule before adding an approver
Approval is a policy decision, so write the rule in plain language first:
Employees in an eligible group can request standard access to approved applications. Privileged access, access outside their role, or a longer duration requires the application owner or Security to review it. The requester cannot approve their own exception.
Now you know when the approval stage exists, who can decide, and what happens when the request does not qualify.
Ravenna approvals support single or multiple rounds, sequential and parallel stages, and policies where any, all, or a threshold of approvers can approve. A workflow can pause for the decision and continue through approved, declined, or timeout paths. That timeout path matters because an unanswered request is still an outcome the process needs to handle.
Set a backup approver and decide when to remind or escalate. Don’t leave the workflow waiting forever because the person named in the first version changed roles six months later.
5. Design the failure paths before you automate
Most process diagrams hide errors in a box labeled “exception.” That box is where the work lives.
Write down the likely failures before you build the workflow:
Required information is missing: Ask for the specific field and move to Waiting on requester.
Duplicate request is detected: Keep one record, preserve context, and close the duplicate.
Approver does not respond: Remind, route to backup, then escalate or expire.
Requester already has the access: Confirm the current entitlement, record the no-change result, and close.
Provisioning action times out: Check the target system before retrying.
Provisioning fails: Record the error, notify IT, and move to manual handling.
If a user encounters a timeout, it does not mean that the action failed. Check the target system before you retry, especially when repeating the action could create duplicate access, duplicate accounts, or conflicting changes.
Ravenna records each workflow run with step inputs, outputs, duration, and errors. Runs can finish as completed, completed with errors, failed, or cancelled. The run history supports retries from the failed step or from the beginning, and workflow attribution on the ticket connects automated changes to the run that made them. Failure alerts can go to email or Slack, which gives the team a defined place to pick up work automation could not finish.
6. Verify the outcome before closing the request
Define completion from the requester’s point of view. For this example, the identity provider or target application must confirm the requested role, the employee must receive a completion message, and the ticket must retain the action result.
Use this definition of done:
The request matched the eligibility rule
Every required approval has a recorded result
The fulfillment action finished
The target system confirms the expected state
Any failed step has an owner
The requester received the outcome and next step
Ravenna tracks time to first response, resolution, and closure as separate SLA targets. Our SLA guidance also supports business schedules and pause statuses, so time spent waiting on the requester does not have to count as active fulfillment time.
7. Test the process and improve one request at a time
Test the expected route and the failure routes before launch. For an AI-assisted intake, Ravenna’s Testing Mode can match rules, present forms, call tools, and show debug data while simulating actions that would change production data.
Your test set should cover:
Eligible employee requesting standard access
Ineligible employee
Privileged access that needs Security review
Missing access level or business reason
Approver timeout
Requester already has the requested access
Fulfillment action failure
Duplicate submission
After launch, review the process by request type. Track volume, fulfillment time, time spent waiting, SLA outcome, reopens, and failed workflow runs. Ravenna analytics can group ticket data by form, status, assignee, priority, SLA, and other fields, while workflow-run data shows completion and failure patterns.
Don’t combine a 10-minute standard access grant with a five-day privileged-access review and call the result “average fulfillment time.” Segment the metric by request type or it will tell you almost nothing.
A reusable service request process template
Use this specification for each request you standardize:
Request name: What the employee is asking IT to provide
Outcome: The observable state that proves completion
Audience: Who can submit the request
Inputs: What the requester supplies and what systems provide
Eligibility: Rules that return allowed, denied, or review
Owner: The person or team accountable for the result
Tasks: The fulfillment steps and their assignees
Approvals: When approval applies, who decides, and the timeout path
Waiting states: What pauses work, who must act, and whether the SLA pauses
Failure paths: Response, owner, requester message, and retry rule
Completion evidence: What the target system must confirm
Measures: Volume, fulfillment time, waiting time, reopens, failures, and SLA outcome
Review date: When the owner checks whether the process still matches policy and systems
Build one process this way, run it with real requests, and fix what the logs show. Then move to the next request. That is how service request management becomes an operating system for the desk instead of a catalog full of forms nobody trusts.
If you want to see how Ravenna handles forms, approvals, workflows, and service desk reporting in one place, we’re happy to walk you through it.
Frequently Asked Questions
What is the difference between a service request and an incident?
A service request asks IT to provide something predefined, such as access to an approved application, folder, or role. An incident reports that an existing service is unavailable or performing worse than expected. Requests follow planned fulfillment paths; incidents usually begin with diagnosis.
Does every service request need approval?
No. Requests that already meet a documented policy can move directly to fulfillment. Add approval when a person must judge cost, risk, entitlement, or an exception the policy cannot decide.
What should you automate first in service request management?
Start with routing, data lookup, notifications, and fulfillment steps that have clear inputs and reversible outcomes. Keep a person involved where the request needs judgment, and define what happens when an automated action fails before you turn it on.
Which service request metrics should you track?
Track volume, fulfillment time, waiting time, reopen rate, SLA outcome, and automation failures by request type. Segmenting matters because different requests have different work and delivery times.
