Use case
Nobody should have to learn the organisation chart to ask for a laptop.
Most internal requests begin with a harder question than the request itself: whose job is this? The answer is usually found by asking somebody who probably knows, which is how requests end up in direct messages and disappear.
What it costs
Requests that travel by reputation.
- The same person gets asked everything. Whoever answered helpfully once becomes the route for all of it, whether or not it is their job.
- Nothing is measurable. If requests arrive as messages, there is no count, no queue and no median response time, so nobody can say whether the service is working.
- Requests vanish on holiday. A request sent to one person stops moving when that person does.
- Nobody knows what is on offer. Services that exist go unused because the people who would benefit never hear about them.
- Expectations are never set. Without a stated response time, a request that is progressing normally and one that has been forgotten look identical to the person waiting.
What changes
A catalogue, and a team that answers it.
A service team holds a bundle of services and answers requests from the rest of the organisation. The requester picks what they need from a list written in their own words, and never has to know which department owns it.
What the requester sees
- A catalogue of what the organisation actually offers, grouped by what the request is for rather than by who provides it.
- The responsible team named on the card, so the request has an owner before it is sent.
- The expected response time, stated up front rather than discovered by chasing.
- A short form, asking only what answering the request genuinely needs.
- The request in My Work, showing which step it has reached, until it is closed.
What the service team sees
- A queue on the team page, with new and claimed requests separated.
- Claiming, so two people do not answer the same request and no request is assumed to be somebody else's.
- Internal notes that the requester never sees, kept alongside the reply that they do.
- Statistics: received, claimed, closed, and how long each stage is taking.
- Their own service definitions, written by the team that answers them rather than by an administrator.
What it is worth
At each level.
For the organisation
Services become visible and measurable.
What is offered, who answers it and how long it takes are facts on a page rather than impressions. Demand can be seen before it becomes a complaint.
For the team
A queue instead of interruptions.
Requests arrive in one place with the information needed to answer them, and the team decides what it offers and how it describes it.
For the person
Ask without knowing who to ask.
Pick the thing you need. The route, the owner and the expected response time come with it, and progress shows up in My Work.
Being clear about it
What this is not.
- It is not a full ITSM suite. There are no change advisory boards, no configuration database and no incident hierarchy. If your organisation needs those, it needs a service management product.
- It is not only for IT. Facilities, finance, HR and legal are service teams too, and usually the ones with no route in at all.
- Services need a licence. The service catalogue and the workflow behind it are gated modules.
Give people a way in.
Tell us what your teams get asked for most often and who currently absorbs it. That is usually the first service worth publishing.