Service Catalog & Intake Design

The service catalog and intake design are the demand-management backbone of IT shared services. The catalog defines what shared services offers — the services, their descriptions, SLAs, and entitlements. The intake design defines how demand enters — the single front door, the routing, the prioritisation. Together, they make demand visible, governable, and improvable.

Without a single front door and a governed catalog, demand leaks in through every channel — email, phone, direct messages to staff — and shared services loses control of what it works on, in what order, and at what cost. The catalog and intake are what turn shared services from a reactive responder into an accountable, demand-managed organisation.

This page covers the service catalog, the single front door and intake design, request vs incident classification, SLA tiers and prioritisation, self-service intake, and treating the catalog as a product.

The service catalog is the definitive list of what shared services offers. Each catalog entry defines a service: its description (what it does, in business terms), its inputs and outputs, its SLA, its entitlement (who can request it), its cost (for showback or chargeback), and its owner. The catalog is the contract between shared services and its customers, made explicit and governable.

A well-designed catalog is the foundation of demand management. When every request must map to a catalog service, demand becomes visible (you can count what is requested), governable (you can set entitlements and approvals), and improvable (you can see which services are costly and why). A service not in the catalog is either out of scope or a gap to close — both are visible, where ungoverned demand is neither.

The catalog has two audiences. Customers use it to understand and request services; shared services uses it to manage, cost, and improve them. The catalog must be written in business terms for customers ('Provision a new virtual server') and mapped to operational detail for delivery. This dual language — customer-facing and operational — is the discipline of catalog design.

The single front door is the principle that all demand enters shared services through one governed channel — the service management platform's portal, email-to-ticket, or phone-to-ticket. Demand that enters through side channels (direct messages, personal calls) is uncontrolled: invisible, ungoverned, and unimprovable. The single front door makes all demand visible and accountable.

Intake design defines what happens at the front door: how requests are captured, classified, routed, prioritised, and approved. Good intake is fast for the customer (low friction to submit) and structured for shared services (enough information to route and prioritise). The tension is real — too much friction and customers bypass the door; too little and shared services cannot manage what arrives.

The mature pattern is guided intake: a portal that presents the catalog, captures the needed inputs per service, applies routing and approval rules automatically, and confirms the SLA. Guided intake is low-friction for the customer (they pick a service and answer a few questions) and high-structure for shared services (the request arrives classified and routed). Self-service deflection (covered in the Knowledge topic) extends this further.

Requests (planned — 'I want something new') and incidents (unplanned — 'something is broken') have fundamentally different flows but should enter through the same front door. Requests follow a fulfilment flow with SLAs based on the catalog; incidents follow a restore flow with SLAs based on impact and urgency. Mixing them — treating an incident as a request, or vice versa — distorts both metrics and service.

The ITIL distinction is the standard. A service request is a user's request for something to be provided (access, a new device, a standard change); an incident is an unplanned interruption to a service or reduction in quality. The front door captures both, classifies them, and routes to the appropriate flow. The classification is automated where the intake is guided, manual where it is not.

The metric implication is significant. Request SLAs measure fulfilment time; incident SLAs measure restore time and are often paired with MTTR. Reporting them together obscures both; reporting them separately makes each manageable. A shared services organisation that cannot separate request from incident performance cannot improve either.

Not all demand is equal, and SLA tiers encode the difference. A critical production incident must be restored faster than a standard access request; the SLA tiers make that explicit and govern prioritisation. The standard model prioritises by impact (how many users/business processes affected) and urgency (how time-critical), producing a priority matrix that drives SLA and routing.

SLA tiers must be calibrated to business reality. An SLA that promises faster than the business needs (or than shared services can deliver) undermines credibility; one that is looser than the business needs undermines service. The calibration is a business-IT conversation: what is the real impact of each service's unavailability, and what restore/provision time does that justify? SLAs set without this calibration are guesses.

The prioritisation must be enforceable, not advisory. A priority matrix that is applied manually is applied inconsistently; one encoded in the service management platform, applied automatically from impact and urgency, is applied consistently. The discipline is to encode the rules so prioritisation is a function, not a judgment — and to reserve human judgment for genuine exceptions the rules do not cover.

Self-service intake extends the single front door: customers request services through a portal without human mediation, with routing and approval automated. Done well, self-service reduces cost-to-serve (the request is processed without an L1 agent) and improves customer experience (the request is submitted and tracked without waiting). Done poorly, it adds friction that drives customers to side channels.

The success factors are catalog clarity (the customer can find the right service), input simplicity (only the necessary questions), and fulfilment automation (the request is processed without manual handling for standard services). Self-service that requires the customer to fill a long form and then waits for an agent to action it delivers neither benefit. The value is in automating the fulfilment, not just the submission.

Self-service and deflection are related but distinct. Self-service is the customer requesting through the portal; deflection is the customer resolving without requesting (via knowledge). Both reduce demand on L1, but deflection removes the request entirely while self-service processes it. A mature shared services organisation does both — deflects what the customer can self-resolve, and self-serves what they can request — leaving L1 for what genuinely needs human handling.

The service catalog is not a static document; it is a product with an owner, a lifecycle, and releases. Services are added (new needs), retired (obsolete), and revised (SLA or cost changes). Without this lifecycle, the catalog drifts from what shared services actually delivers, and the contract with customers becomes unreliable. The catalog must be maintained as living, not published once.

Treating the catalog as a product means owning it: a named owner accountable for its accuracy, a review cadence (quarterly for most), and a change process (new and retired services go through governance, not ad hoc). The owner also owns the customer experience of the catalog — is it easy to find, request, and track? A catalog no one can navigate is not adopted, regardless of its accuracy.

The catalog also evolves with the business. New business capabilities create new service needs; retiring systems retire services. The catalog that tracks the business stays relevant; the one that does not becomes a fossil that customers bypass. Linking catalog review to business planning is what keeps the catalog aligned to demand over time.