Broken, or wanted?
The difference from an incident is simple but decisive for how the ticket should be handled.
An incident is unplanned and should be resolved as quickly as possible. A service request is planned, repetitive and should be delivered within an agreed lead time.
Mix them in the same queue with the same priority model and you get either requests crowding out outages, or requests that never get done because something is always more urgent.
The catalog is a promise, not a menu
Every entry in the service catalog is a commitment: you can order this, this is how it works, and this is how long it takes.
That is why the catalog should start small. Ten services that work beat sixty that nobody maintains. Look in your ticket history – the ten most common requests are probably also the ten you should start with.
Write them in the language of the business. An entry called Request for provisioning of license object will not be used. Order Office will.
What each service needs to define
Who may order it. Everyone, or only certain roles.
Who approves it. Line manager, system owner, or nobody at all.
What happens next. A manual step or an automated workflow.
How long it should take. A lead time you can actually meet with your current staffing.
Approvals where they belong – and only there
An approval step should exist where there is a cost, a risk or a permissions question. Everywhere else it only adds waiting time and a person to chase.
If the lead time for a request is four days and three of them are waiting for an approval, the problem does not sit with IT.
The best place to start automating
Service requests are predictable and recurring, which is exactly what automation is good at.
An account that follows the same steps every time rarely needs a human. Onboarding and offboarding give the most back: they are frequent, error-prone and have consequences when done carelessly.
Note also the link to change management. A request that alters something in the environment is often a standard change – pre-approved, logged, but without a risk assessment in each individual case.
The portal decides whether it gets used
For most people in the organization, the self-service portal is the entire IT delivery. It is the only part they see.
It has to be faster than emailing someone you know. Few fields, comprehensible names, and a clear message about what happens next. A portal that feels awkward loses to the shared inbox every time – see service desk and helpdesk.
For MSPs
Here the catalog has a commercial side as well. It shows the client what is included in the contract and what is billed separately, which removes a recurring discussion.
Connected to your PSA system, the request also carries the right contract and the right price all the way to the invoice line.
