A service catalogue should help people get an outcome
An IT service catalogue is useful when a person can recognise their need, choose a clear route, provide the right information and understand what happens next. A technical inventory relabelled as a portal forces users to know the organisation before they can ask for help.
Design the public catalogue around business services and user intents, while linking each entry to technical components, owners and support records behind the scenes. “I need access to the finance service” is a usable request; a list of server and application names is not.
Keep the catalogue governed. Every service needs an accountable owner, eligibility, scope, channels, hours, dependencies, request and incident paths, measures and review date. An entry without operating ownership becomes a promise nobody can reliably fulfil.
| Element | Visitor question | Owner evidence |
|---|---|---|
| Purpose | What outcome does this service support? | Service statement |
| Access | Who can use it and how? | Eligibility and approval |
| Support | What if it fails or I need help? | Channels and priorities |
| Delivery | What information and time are involved? | Workflow and expectations |
| Ownership | Who decides and improves it? | Named accountable role |
Separate business services, requests and components
A business service provides an outcome such as workplace access, customer support, payments or collaboration. A request is something a user asks for within it. Applications, infrastructure and integrations are supporting components. Preserve these relationships without presenting them as one flat list.
One component can support several services, and one service can use many components. Model the relationship so a supplier incident or planned change can reveal affected user outcomes. Avoid copying the same application into multiple entries with different, inconsistent ownership.
Use stable service identifiers and visitor-facing names. Teams may change tooling without changing the service people recognise. This makes the catalogue more durable and reduces the tendency to design the user journey around the current vendor.
Research the language people use
Review support searches, tickets, chat requests, onboarding guides and user interviews. Group intents such as get access, report a problem, request software, obtain data, change equipment or leave the organisation. Do not force every phrase into a separate catalogue item.
Test navigation with people who do not work in IT. Ask where they would go and what they expect after selecting an entry. If users choose several plausible routes, simplify labels or add guided questions rather than blaming them for incorrect classification.
Provide synonyms and context without turning titles into keyword strings. The entry should explain when it applies, common examples and when another route is better. Clear boundaries reduce reassignment and make demand data more meaningful.
Define request data and approval proportionately
Ask only for information needed to route, decide and fulfil the request. Prefill trusted identity and organisation data where appropriate. Explain why sensitive or unusual information is needed and avoid collecting passwords, unrestricted documents or broad free text by default.
Design approvals around real authority and risk. Routine low-risk requests may use policy-based automation, while privileged access or material spend needs evidence and accountable review. More approval steps do not automatically create more control.
Show status and next action in terms users understand. If another team or supplier owns the next step, keep responsibility for the overall service visible rather than making the requester navigate internal boundaries.
Connect incidents, requests and knowledge
Separate a service failure from a standard request but allow a user to begin with their observed problem. Guided questions can route appropriately without requiring them to know operational terminology. Preserve the ability to identify widespread incidents from repeated reports.
Place concise, task-specific knowledge near the request and inside support responses. Measure whether guidance helps people complete the work, not only whether an article received views. Retire or update knowledge when configuration changes.
Use the site’s service desk management pathway to connect channels, priorities, escalation and recurring improvement. The catalogue is a front door to that operating system, not a standalone documentation project.
Set expectations from evidence
Publish support hours, response targets, fulfilment expectations, prerequisites and planned exceptions only when the operating model can support them. Distinguish acknowledgment, first response, decision and completion. One time promise rarely fits every request.
Use ranges or target classes based on historical and capacity evidence. State what pauses the clock and what the user must do. Avoid precise commitments that rely on an unverified supplier or approval path.
Design priority from impact and urgency, with examples. Let support teams correct a user-selected priority transparently. A catalogue should reduce ambiguity, not invite every request to describe itself as critical.
Instrument outcomes and failure demand
Measure successful completion, reassignment, missing information, approval delay, abandonment, reopen, repeat contact and user understanding. Volume alone shows demand, not whether the service worked. Segment by entry, role and channel to locate friction.
Review failure demand: contacts created because an earlier service, form, communication or process failed. Treat recurring password confusion, unclear access, status chasing and repeated data correction as improvement evidence rather than inevitable ticket load.
Connect service measures with application, integration and supplier signals. A portal can close a request while the user still lacks the outcome. Sample end-to-end journeys and reconcile completion with observable service state.
Govern the catalogue as a product
Assign a catalogue product owner and service-entry owners. Create a lightweight standard for naming, scope, accessibility, forms, approvals, expectations and measures. Review new entries for duplication and user need before publishing them.
Set review cadence by change and demand. Trigger updates after supplier, process, role, policy or integration changes. Archive obsolete entries with working redirects and a clear replacement path so bookmarked links do not become dead ends.
Test the catalogue at mobile and desktop widths, with keyboard and assistive technology. Forms, tables and status views must remain understandable. Accessibility is part of fulfilment because a blocked requester cannot access the service at all.
Launch one service family and learn
Choose a coherent family with visible demand, such as access and onboarding. Map existing routes, owners, forms, knowledge and measures. Remove duplicates, build the visitor journey and connect the technical service records behind it.
Pilot with new starters, occasional users, managers, support analysts and fulfilment teams. Observe classification, form completion, approval, handoff, status and outcome. Fix the points where people need private explanation to proceed.
Expand only after the first family has governance and evidence. A small catalogue that reliably connects needs to owners is more useful than hundreds of imported entries. The long-term goal is a trusted service interface and an accurate map of how demand moves through operations.
Use service standards as prompts, not borrowed promises
The GOV.UK Service Standard connects user need, whole journeys, accessibility, multidisciplinary ownership, security, measurement and reliable operation. It is designed for government services, but these themes provide useful questions for catalogue governance in other organisations.
Use GOV.UK guidance on defining success and performance data to challenge whether each catalogue entry has a measurable outcome and baseline. Adapt the publication expectation to the organisation’s confidentiality and audience rather than exposing internal data automatically.
For every new entry, ask which whole problem it solves, how users discover it, who operates it and which measure would show improvement. If the answer is only “this team offers it”, the catalogue is still organised around internal structure instead of service value.
