Feature
Every internal request starts with a harder question than the request.
Whose job is this? Most people answer it by asking somebody who probably knows, which is how requests end up as direct messages and quietly stop moving.
Why it matters
A request with no route has no owner and no clock.
When requests arrive as messages, nothing about them can be seen: not how many there are, not how long they take, not which ones are stuck. The team absorbing them looks unproductive, because the work they are doing is invisible by construction.
The person waiting has the same problem in reverse. A request that is progressing normally and a request that has been forgotten look exactly alike, so they chase, which makes the queue worse.
How it works
A team publishes what it offers, and answers what is asked.
A service team holds a bundle of services. Anyone in the organisation can browse the catalogue and ask, without knowing who will answer.
Asking
- A catalogue grouped by what the request is for, in the words the requester would use: teams and spaces, access and accounts, files and storage, support, apps and tools.
- Two ways to browse it. Alphabetically, for somebody who knows what the thing is called, or by team, for somebody who already knows who they need.
- The responsible team named on the card, so it has an owner before it is sent.
- The expected response time, stated before the request goes rather than discovered by chasing. Usually within one, two or three working days, per service.
- A short form, asking only what answering genuinely requires.
- Progress in My Work, showing which step the request has reached until it is closed.
Answering
- A queue widget on the service team's own page, separating new requests from claimed ones.
- Claiming, so two people do not answer the same thing and nothing is assumed to be somebody else's.
- Internal notes, visible to the answering team and never to the requester.
- Statistics: received, claimed, closed, and how long each stage takes.
- Their own definitions, written by the team that answers them rather than by an administrator.
Requests run on a workflow with named steps, and a service can give its steps its own words, so a storage request says grant and decline rather than approve and reject.
The limits
What Services is not.
- It is not a full service management suite. No change advisory board, no configuration database, no incident and problem hierarchy, no contractual service levels. A stated response time is an expectation, not an SLA.
- 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.
- It is not a public help desk. It serves people who already have an account on your Nextcloud, not your customers.
Community or licensed
Services and the workflow behind it are licensed modules.
What do your teams get asked for most?
Whatever one person currently absorbs by being helpful is usually the first service worth publishing.