Service Request

What is a service request?

A service request is a formal ask from a customer or employee for a standard, pre-approved service or item. It's the way someone says "please give me this thing you already offer": access to a system, a new piece of equipment, a password reset, a copy of an invoice, or an answer to a routine question. The defining feature is that nothing is broken. The person is asking for something normal to happen, not reporting that something has gone wrong.

The term comes from IT service management (ITSM), where service requests flow through a defined process: a catalogue of available services, and a request that moves through approval and fulfilment. You'll also see "service request" on city and government portals, where residents report a pothole or book a bulky-waste collection. In a business support context the meaning is narrower and more useful: a routine, expected demand that your team fulfils to an agreed standard.

Because the outcome is known in advance, service requests lend themselves to consistency. The steps to grant access or issue a refund can be written down once and followed every time, which makes them faster to fulfil and easier to hand to self-service or automation.

Service request vs incident

The cleanest way to understand a service request is to set it against its opposite, the incident.

• A service request asks for something standard: "I'd like access to the analytics dashboard."
• An incident reports something broken: "The analytics dashboard I already use won't load."

The distinction matters because the two need different handling. An incident is about restoring a service that has failed, so it's judged on speed of recovery and often carries real urgency. A service request is about delivering a service that is working as intended, so it's judged on whether it was fulfilled correctly and within the expected time. Mixing the two makes reporting misleading: a spike in "tickets" could be a run of routine access requests or a serious outage, and you can't tell them apart until they're categorised.

Getting the category right at the point of intake is what lets you set the right ticket priority and send the work to the right place. A broken checkout is not the same kind of problem as a request for a second user seat, and they shouldn't sit in the same lane.

How to handle service requests well

Good service request handling rests on a few habits.

Define what you offer. A short catalogue of the standard requests you accept, and what each one involves, removes ambiguity for both sides. People ask for the right thing, and your team knows exactly how to fulfil it.

Route by type, not by luck. Once a request is identified, ticket routing should send it straight to whoever, or whatever, can fulfil it, rather than letting it drift in a shared support queue until someone picks it up.

Automate the repeatable. The most common service requests, password resets, plan changes, document requests, follow the same steps every time. These are ideal candidates for self-service, so the customer gets an instant answer and your team never has to touch them.

Track fulfilment time separately. Because requests aren't emergencies, measuring them against the same clock as incidents distorts both. Give service requests their own turnaround expectation and report against that.

Handled well, service requests become the quiet, predictable backbone of your support operation: high in volume, low in drama, and increasingly something customers can complete on their own.