Service Request Management

Handling the routine things users ask for — access, equipment, information — through a service catalog, standard request models, approvals and automation.

What a service request is

A service request is a request from a user, or someone acting for them, for something that is a normal, expected part of service delivery. Nothing has failed: the user simply wants something the service already offers. Typical kinds at Kestrel Energy:

  • Information: "How do I connect to the VPN from home?" or "When is the next billing maintenance window?"
  • Access: read access to the billing system for a new analyst, membership of the outage map editors group.
  • Equipment and software: a laptop, a second monitor, a headset, a licensed drawing tool from the approved list.
  • Standard changes: a new virtual machine from an approved template, extra storage on a team share, both pre-authorized changes that users can order.
  • Feedback and complaints, which many organizations also log as requests so they are not lost.

Service requests reach the same service desk as incidents, often through the same portal. Telling them apart is one of the first skills a new service desk analyst learns.

Why requests are not incidents

A user who asks for a new laptop because the current one is getting old is not reporting an interruption. Treating that as an incident would cause three problems:

  • Different urgency. Incidents compete for attention by priority; requests are planned work with agreed lead times. Mixing them makes it look as if the laptop order is competing with an outage.
  • Different handling. A request follows a known, repeatable set of steps, often with an approval. An incident needs diagnosis; nobody knows the steps in advance.
  • Different numbers. If requests are counted as incidents, incident reports show hundreds of "incidents" that were never failures, and trends in real failures disappear in the noise.

The border is not always obvious. "My password expired" is usually handled as a request (reset it); "I cannot log in and I did not change anything" is an incident until proven otherwise, and may even be a security incident. For more on incidents, see incident, service request or problem.

The service catalog

A service catalog is the organized, up-to-date list of the services and requestable items a provider offers, with the information users need to request them: what it is, who may ask, what approval is needed, how long it takes and what it costs. For users it usually appears as the request section of a self-service portal, much like a web shop.

Catalog item Who can request Approval Target
Password reset Every employee, for themselves None (identity verified) Immediate, self-service
Software from the approved list Every employee None; license cost charged to department 1 day
Billing app access (read) Managers, for their staff Manager and application owner 2 days
Standard laptop Managers, for their staff Manager (budget) 5 days
New employee onboarding HR Hiring manager Ready on start date (10 working days' notice)

User view and technical view

The same catalog has two audiences. The user view shows items in plain business language: "Access to the billing system", "I'm starting a new colleague". The technical view, used inside IT, shows what each item depends on: the directory group that grants billing access, the identity management system that creates accounts, the laptop stock, the supplier contract for phones, the team that does each task. Users should never need the technical view to find what they want; IT needs it to know what a catalog item actually involves.

Request models

A request model is the predefined set of steps, approvals, responsible teams and timelines for fulfilling one type of service request. Because the steps are agreed in advance, a request does not need to be figured out each time; the ITSM tool creates the tasks automatically when the request is submitted.

Simple items have simple models: a software install has one automated step. Others involve several teams. When Kestrel hires Emeka as a network engineer, HR submits one onboarding request with his start date and role. The model behind it looks like this:

The onboarding request model. HR submits a new employee request. The hiring manager approves it. Then four tasks run in parallel: account and mailbox, laptop and phone, building badge, and billing app role. When all four are done, the employee is ready on day one. HR: new employee Manager approves Account and mailbox Laptop and phone Building badge Billing app role Ready on day one
One request, several teams: the identity team, workplace support, facilities and the billing application owner each get their own task, and the request is fulfilled only when all four are done.

The requester sees one request with one status; behind it, each team works on its own task with its own deadline, counted back from the start date. Without a model, onboarding at many organizations is a series of emails, and new employees spend their first week without a laptop or without access to the systems they were hired to use.

The billing role is a good example of access that follows the employee's job: the model grants it from a role definition, and the matching offboarding model removes it when the employee leaves. Joiners, movers and leavers are covered from a security angle on access control.

Approvals

Some requests need someone's permission before they are fulfilled. Two kinds are common:

  • Financial approval: someone with a budget agrees to pay, for example a manager approving a laptop or a paid software license.
  • Functional approval: someone responsible for the data or system agrees that the person needs it, for example the billing application owner approving access to customer contracts. This is also a security control, related to least privilege.

Every approval adds waiting time, so each one should earn its place. Many catalog items are pre-approved: anyone in a given role may request them without anyone signing off, because the cost is low and the risk acceptable. A manager approving a free PDF reader adds delay and no control.

Automation and self-service

Because service requests are predictable, they are the easiest work in IT to automate. The most common examples:

  • Password reset and account unlock through a self-service portal, after the user proves who they are with multi-factor authentication. At many service desks this used to be the single largest type of call.
  • Software installation from an approved list: the user clicks "install", the device management system deploys the package, and the license is recorded.
  • Access requests: after approval, the identity management system adds the user to the right group, and the access is reviewed periodically.
  • Information requests: answered by knowledge articles and, increasingly, by AI assistants in the portal; see AI in service management.

Automation is only as good as the model behind it: automating a confusing process gives a fast confusing process. Start with frequent, simple items, measure how many requests are completed without a person touching them, and expand from there.

Fulfillment and its measures

Request fulfillment is carrying out an approved service request: delivering the item, access or information, confirming with the user and closing the request. Its typical measures are:

  • Fulfillment time per catalog item, against the target published in the catalog.
  • User satisfaction, from a one-question survey after closure.
  • Share of requests through self-service and the share fulfilled fully automatically.
  • Backlog: open requests, and how old the oldest ones are.

The program below checks a week of Kestrel requests against the catalog targets, counting calendar days from submission to fulfillment: 

from datetime import date

# (request, catalog item, target in calendar days, submitted, fulfilled)
requests = [
    ("REQ-2201", "Software install", 1, date(2026, 4, 1), date(2026, 4, 1)),
    ("REQ-2202", "Standard laptop", 5, date(2026, 4, 1), date(2026, 4, 7)),
    ("REQ-2203", "Billing app access", 2, date(2026, 4, 2), date(2026, 4, 3)),
    ("REQ-2204", "Standard laptop", 5, date(2026, 4, 6), date(2026, 4, 10)),
    ("REQ-2205", "Billing app access", 2, date(2026, 4, 8), date(2026, 4, 13)),
    ("REQ-2206", "Software install", 1, date(2026, 4, 9), date(2026, 4, 10)),
]

met = 0
for number, item, target, submitted, fulfilled in requests:
    days = (fulfilled - submitted).days
    ok = days <= target
    met += ok
    result = "met" if ok else f"missed (+{days - target} d)"
    print(f"{number}  {item:<18}  took {days} d, target {target} d  {result}")

print(f"\nWithin target: {met} of {len(requests)} ({met / len(requests):.0%})")
REQ-2201  Software install    took 0 d, target 1 d  met
REQ-2202  Standard laptop     took 6 d, target 5 d  missed (+1 d)
REQ-2203  Billing app access  took 1 d, target 2 d  met
REQ-2204  Standard laptop     took 4 d, target 5 d  met
REQ-2205  Billing app access  took 5 d, target 2 d  missed (+3 d)
REQ-2206  Software install    took 1 d, target 1 d  met

Within target: 4 of 6 (67%)

met += ok works because True counts as 1 in Python. REQ-2205 was submitted on a Wednesday and fulfilled the next Monday, so the weekend counts against it. Whether targets use calendar days or working days is a choice to write down in the catalog or the service level agreement; measuring one way and promising the other leads to arguments. When the access requests keep missing their target, the next step is to look where they wait: often at an approver, not at IT.

Common mistakes

  • A catalog nobody can understand. Three hundred items named after internal systems ("AD-GRP-ADD-RO") send users back to email and phone. Name items in the user's words, keep the list short and searchable, and retire items nobody orders.
  • Approvals for everything. Waiting two days for a signature on a free tool teaches users to work around IT.
  • No visible status. A user who cannot see where a request is will call to ask, which costs the service desk more than showing the status would.
  • Onboarding without offboarding. Access granted by a request model must be removed by a matching model, or old accounts pile up as a security risk.