Service Catalogs for Internal Shared Services

What a service catalog is

A service catalog is a structured list of the services a team offers, written from the customer’s point of view. For an internal shared service, it answers a simple question: “What can I ask this team for, and how?” It is not a list of the team’s tasks or internal processes. It is a menu of outcomes that customers can request.

Without a catalog, customers often discover what a team does by accident, or by asking around. Requests arrive in different forms, are sent to the wrong people, and lack the information needed to act on them. The team spends time asking questions that a well-written entry would have answered. A catalog reduces that friction, and it also gives the team a clear statement of what falls within its remit.

Catalogs are common in IT service management, where an established framework often describes them in detail, but the idea applies equally to finance, HR, procurement and other shared functions.

Customer view and team view

It helps to distinguish two perspectives.

• The customer-facing view lists services in the customer’s language: “Set up a new supplier,” “Change an employee’s pay details,” “Request a laptop.” This is what business units read.
• The internal view records what the team needs behind each service, such as the steps, systems, staff and cost. This supports planning and charging but is not necessarily shown to customers.

Mixing them tends to produce a catalog that is either too technical for customers or too thin for the team. Many organizations keep the customer-facing entries short and link to more detailed procedures elsewhere.

What a good entry contains

A practical entry usually includes:

1. Name. A plain, specific title that a customer would recognize. “Supplier onboarding” is clearer than “Vendor master data activities.”
2. Description. One or two sentences on what the service delivers and why someone would use it.
3. Who can request it. The roles or groups eligible, and any approval needed, such as a manager’s sign-off.
4. How to request it. The route to use, whether a form, a portal or an email address, so that requests arrive in a consistent form.
5. Inputs required. The information or documents the requester must provide. Listing these prevents the back-and-forth that slows many requests.
6. What the customer receives. The output or result, in concrete terms.
7. Expected turnaround. A realistic time frame, ideally linked to the internal service levels agreed with customers. State when the clock starts and what delays it.
8. Hours and availability. When the service operates.
9. Cost or charging information, if applicable, including whether the service is covered by a general allocation or billed per use.
10. Service owner and contact. A role, not just a name, who is accountable for the service.
11. Exclusions. What the service does not cover, to avoid assumptions.

Not every service needs every field. Simple services may need only a few lines. The principle is that a customer can decide whether to use the service and make a complete request without asking for help.

A short illustrative entry

The following is an invented example to show the format.

Service: New starter payroll setup Description: Sets up a new employee on the payroll so they are paid correctly from their start date. Who can request: Line managers, with HR confirmation of the hire. How to request: Submit the new starter form through the internal request portal. Inputs required: Signed contract, bank details, tax and identification details as required locally, and start date. Output: Employee record created and confirmation sent to the manager. Turnaround: Within a set number of working days before the next pay cut-off, provided the form is complete. Exclusions: Changes to existing employees, which are a separate service.

The turnaround is deliberately left generic; a real entry would state a figure the team can meet.

Organizing the catalog

As the list grows, structure matters. Common ways to group services include:

• By function, such as finance, HR, IT and facilities.
• By customer need or life event, such as “starting a new employee” or “buying something.”
• By type of request, such as standard requests, changes and problems.

A search facility helps if the catalog is large, but the first test is whether a newcomer can find the right service without prior knowledge. Using plain naming and avoiding internal jargon matters more than the layout.

It also helps to distinguish standard services, which are repeatable and predictable, from bespoke or project work, which needs discussion and scoping. Putting both in the same format can mislead customers about how quickly bespoke work can be done.

Building the first version

A reasonable approach is incremental:

1. List what the team actually does, using records of past requests. They often reveal activities that nobody had described.
2. Group related activities into services a customer would recognize.
3. Draft entries with the team members who carry out the work, since they know the real inputs and delays.
4. Test with customers. Ask a few of them to find and request a service using only the catalog and note where they get stuck.
5. Publish in one accessible place and tell people where it is.

Starting with the highest-volume services is often more useful than trying to be complete from the outset.

Keeping it current

A catalog that is out of date is worse than none, because it misleads. To keep it reliable:

• Assign an owner to the catalog as a whole, and an owner to each entry.
• Review on a schedule, such as annually, and when a service changes.
• Link changes to a simple change process, so that new, altered or withdrawn services are reflected.
• Use feedback. Questions and repeated mistakes from customers show where entries are unclear.
• Retire services that are no longer offered, rather than leaving them listed.

Entries can also be paired with knowledge base articles that cover how-to questions, keeping the catalog itself short.

Limits and cautions

A catalog can create the impression that everything is available on demand and at a fixed speed. If the team cannot deliver what the catalog promises, trust drops. It can also feel bureaucratic if every small favor must be formally listed. And a very detailed catalog takes effort to maintain, so the level of detail should match the value it delivers. A modest, accurate catalog that people consult is better than a comprehensive one that nobody trusts.