Service request management and the service catalog

Not everything users ask for is a fault. Every day, people need a password reset, access to a system, a new laptop, a software license, a meeting room set up or an answer to a question. These predictable, routine requests often make up the largest share of a service desk's volume. Service request management makes them easy to ask for and efficient to fulfill. In plain words, its purpose is to support the agreed quality of a service by handling all predefined, user-initiated service requests in an effective and user-friendly way.

What a service request is

ITIL describes a service request as a request from a user or a user's authorized representative that initiates a service action which has been agreed as a normal part of service delivery. The key words are predefined and agreed. A service request is something the provider has already decided it will do, has a known procedure for and, usually, has standard approvals and targets for. That is what distinguishes requests from incidents (something has gone wrong) and from changes that need individual assessment (something new or risky).

Typical categories of request include requests for a service delivery action (provide a report, replace a toner cartridge), requests for information (how do I do this, what is the status of my order), requests for provision of a resource or service (a laptop, access to an application, a mailbox), requests for access (permissions to a shared folder), feedback, compliments and complaints. Some organizations also treat certain low-risk, pre-authorized changes as service requests, such as installing approved software; lesson 7 explains how these relate to standard changes.

Standardizing requests

The heart of service request management is standardization. Each request type should have a defined workflow: what information is needed from the user, what approvals are required, which teams or systems fulfill it, what the target time is and how the user is kept informed. These workflows can be simple or complex, but they should be designed once and reused, not reinvented for each request.

Standardization brings several benefits. Users know what to expect. Fulfillment teams can plan and measure their work. Approvals that are genuinely necessary are built in, while unnecessary ones can be identified and removed. Automation becomes possible because the steps are known. ITIL-120's guiding principles apply directly: keep it simple and practical, optimize and automate, and focus on value.

The service catalog

Users need a place to see what they can ask for. The service catalog is structured information about all the services and service offerings of a provider that are relevant to a specific audience. ITIL treats service catalog management as a separate practice, but service request management depends on it, because the requestable items in the catalog are the entry point for most requests.

A good catalog is written in the user's language, not the provider's. "Get access to the shared finance drive" is better than "NAS share provisioning – FIN01". Items are grouped the way users think about their needs, such as by life event (starting a job, changing role, leaving), by device or by business task. Each item shows what the user will get, what it costs if chargeback applies, who must approve, how long it will take and what information is needed. Different views can serve different audiences: employees see requestable items, managers see team-related items, and technical staff see a more detailed technical catalog.

Self-service and portals

Most organizations now offer requests through a self-service portal, often combined with a knowledge base and status tracking. A well-designed portal lets users find what they need in a few clicks or a search, submit a request with the right information the first time, see its progress and receive notifications. Virtual agents can guide users through common requests conversationally. Self-service reduces service desk load and cost, but only if the portal is easy to use. A confusing portal simply moves frustration and generates phone calls asking how to use the portal.

Good portal design draws on user experience research: test with real users, use plain language, minimize the number of fields, pre-fill what is already known (such as the user's department), and offer a way to reach a person when the portal does not fit. Accessibility is a legal and ethical requirement. Public sector portals in Canada must meet accessibility standards under the Accessible Canada Act and provincial laws such as Ontario's AODA, and in the United States under Section 508 and, increasingly, the ADA rules for state and local government websites. Most refer to the Web Content Accessibility Guidelines (WCAG).

Approvals

Approvals protect the organization, but each one adds delay. Many request workflows accumulate approvals over time because each incident or audit finding adds one more check, and nobody removes them. Service request management should review approvals regularly and ask whether each one is still needed, whether it can be delegated or pre-approved by role, and whether it can be done automatically using data the organization already has (for example, checking that the requester is in an eligible job role).

Automation

Because service requests are predictable, they are prime candidates for automation. Password resets, account unlocks, group membership changes, software installation from an approved catalog, mailbox creation and many cloud resource requests can be fully automated. Others can be partly automated, such as ordering a laptop automatically while a person handles delivery. The guiding principle optimize and automate reminds us to simplify the workflow first; automating a bad workflow just produces bad results faster.

The program below compares two years of costs for a request type before and after automation, including the one-time cost of building the automation and an ongoing maintenance cost. It reports the payback period and the change in average fulfillment time. All figures are illustrative.

# Automation business case for a request type (illustrative figures)
requests_per_month = 900
manual_minutes = 12          # agent time per manual request
manual_wait_hours = 6.0      # average time to complete, mostly queueing
agent_rate = 42.0            # loaded cost per agent hour, in dollars
build_cost = 18000.0         # one-time cost to build and test the automation
run_cost_month = 400.0       # maintenance, subscriptions and monitoring
auto_share = 0.85            # share of requests the automation completes alone
auto_wait_hours = 0.1        # time to complete when automated

manual_cost_month = requests_per_month * manual_minutes / 60 * agent_rate
after_cost_month = (requests_per_month * (1 - auto_share) * manual_minutes / 60 * agent_rate
                    + run_cost_month)
saving = manual_cost_month - after_cost_month
payback = build_cost / saving
avg_wait_after = auto_share * auto_wait_hours + (1 - auto_share) * manual_wait_hours

print(f"manual cost per month:     ${manual_cost_month:,.0f}")
print(f"cost after automation:     ${after_cost_month:,.0f}")
print(f"monthly saving:            ${saving:,.0f}")
print(f"payback period:            {payback:.1f} months")
print(f"two-year net benefit:      ${24 * saving - build_cost:,.0f}")
print(f"average completion time:   {manual_wait_hours:.1f} h -> {avg_wait_after:.2f} h")

manual cost per month:     $7,560
cost after automation:     $1,534
monthly saving:            $6,026
payback period:            3.0 months
two-year net benefit:      $126,624
average completion time:   6.0 h -> 0.99 h

The financial case pays back in a few months, but the bigger benefit for users is the drop in average fulfillment time from hours to under an hour. Business cases for automation should count both. They should also count the risk side: an automation that grants access without proper checks could create a security problem, so automated access requests should still verify eligibility and log every action for audit.

Fulfillment targets and measurement

Each request type should have a target fulfillment time, agreed through service level management and published in the catalog. Measurement then tracks the share fulfilled within target, average and percentile fulfillment times, the share completed by automation, the share of requests rejected or returned for missing information, and user satisfaction. Requests returned for missing information are a useful signal: they usually mean the form asks the wrong questions or the catalog description is unclear.

Requests that span teams

Some requests touch many teams. Onboarding a new employee may involve HR, facilities, IT, security and the hiring manager: a desk, a badge, a laptop, accounts, training and an introduction. Offboarding reverses all of these and has security consequences if anything is missed, such as an account left active after someone leaves. Organizations increasingly design these as enterprise service management value streams, using the same request tools and practices beyond IT. ITIL-130's value stream mapping is the right technique for improving them.

Connections to other practices

Service request management works with the service desk (which receives and routes requests), service catalog management (which defines what can be requested), service level management (which agrees targets), change enablement (which pre-authorizes standard changes that are fulfilled as requests), information security management (which defines access rules), IT asset management (which tracks devices and licenses issued), knowledge management (which answers information requests) and relationship management (which hears what users want added to the catalog). Requests also reveal demand: a surge in requests for a particular tool may signal an opportunity for a new standard service.