Service catalogue and request fulfilment: why a form list is not a catalogue

Most teams believe they have a service catalogue because they have a list of forms in a portal. A form list tells people what they can ask for. A catalogue tells them what they will get, how quickly, who owns it, and what it costs — a different artefact with a different purpose, and the difference determines whether the catalogue reduces work or merely relocates it.

The other half of the pair is request fulfilment: how those requests get delivered once asked. It is the highest-volume, lowest-drama part of a service desk, and it is where nearly all the automatable work lives.

A catalogue entry is a commitment: the service described in the requester’s language rather than yours, who is eligible, what information they must provide, what they receive, how long it takes, who owns it, and what approval is required if any. Everything on that list except the first item is what a form lacks and what makes the entry worth writing.

The eligibility and inputs fields do the most work. "Request a laptop" with a free-text box produces a conversation. "Request a laptop" with a scoped set of models, a cost centre, and a delivery address produces a fulfilment. Most catalogue redesigns are really the exercise of converting conversations into structured requests, and the measure of success is the proportion of requests that need no clarifying question before work starts.

An incident is unplanned: something that should work does not. A request is planned: a normal, pre-defined part of what the service offers. They look similar in a queue and behave nothing alike. Incidents are prioritised by impact and urgency and worked in whatever order the damage dictates. Requests are worked in a predictable order against a delivery target, and their variance matters more than their speed. Nobody minds access taking four hours. Everybody minds not knowing whether it will be four hours or four days.

Mixing them into one queue under one priority scale produces two specific failures: real incidents queue behind routine requests, and routine requests get escalated by requesters who have learned that calling something urgent is the only way to be seen. Separate the two at intake, give requests a delivery target instead of a priority, and the escalation theatre stops.

This is the part most teams miss. A well-scoped request type — defined inputs, defined eligibility, defined output, deterministic steps — is not merely easier for a human to fulfil. It is a candidate for an allow-listed automated action, because it satisfies the same tests: the steps are known, the inputs are validated, the outcome is verifiable, and the action is reversible.

Which means catalogue design and automation strategy are one project, not two. Every ambiguity you remove from a request type — every free-text field replaced by a constrained choice, every implicit eligibility rule written down — moves that request type closer to something a system can complete unaided. A catalogue full of "describe your issue" boxes cannot be automated at all, whatever tooling you buy, because there is nothing stable to automate against.

Vendor catalogue templates arrive with two hundred entries describing an organisation you are not. They are a trap: the entries you do not need dilute the ones you do, and a catalogue nobody can navigate sends people straight back to direct messages.

Do this instead. Export the last quarter of tickets, strip out the incidents, and count what remains by type. Ten categories will cover most of the volume — access requests, software installs, hardware, onboarding, offboarding, permission changes, licence or expense approvals, environment setup, data exports, and one or two specific to your business. Write proper entries for those ten and nothing else. Everything outside the catalogue keeps a general request route, which doubles as your discovery mechanism: when a general request repeats often enough to be recognisable, it has earned an entry.

The first is clarification rate: how often a request needs a follow-up question before work can start. A rising clarification rate means the entry is under-specified, and it is the leading indicator of everything else going wrong. The second is variance in time to fulfil rather than the average. The average tells you whether you are fast; the variance tells you whether you are trustworthy, and trust is what stops people escalating.

Both numbers double as an automation readiness score. A request type with a near-zero clarification rate and tight variance is a request type a machine could already be completing, and the ones with wide variance are telling you exactly which entry to rewrite first.

A catalogue only works if people use the route it defines, which is why intake matters more than portal design. FlowTux takes requests from Slack, Teams, email, and WhatsApp and turns them into structured tickets, so a request typed into a channel lands in the same queue as one submitted formally. The catalogue work — scoping inputs, defining eligibility, naming the deterministic path — is what makes the next step available: per-category modes let judgement-heavy categories stay in suggest or approve while well-scoped, reversible request types run autonomously, with the full action trail on the ticket timeline. Anything that turns out to need engineering escalates into Jira, Linear, or GitHub with the link kept on the ticket. The catalogue is the specification; the modes are how much of it you have handed over so far.