Examples of how to set up services
There's no single right way to fill a service catalogue, and that is what makes it hard to start. This page shows how a few common setups could look, so you can find one that resembles yours and borrow from it. The names are only examples; use the words your own people use.
If you are new to services, read these first: what a service is and its offerings, and how dependencies work.
[!NOTE] Setting up services needs the Service Configuration plugin and the Service Manager role (or Administrator). See who can use services.
Three questions that settle most choices
- Would someone call for help with it by that name? “Email doesn't work” and “I can't get on the VPN” are services. “Exchange Online connector 2” isn't; it is a part of one.
- Does one person answer for it, and one team fix it? If the owner or the team is different, it is usually a service of its own. If they are the same and only the flavour differs, it is an offering.
- Would its outage hurt other services? Then it is worth adding as a technical service and pointing the others at it with Depends on, so the desk can show the chain when it breaks.
[!TIP] Stop when you reach the level one team owns. Servers, databases and network switches belong in a CMDB, which this catalogue doesn't try to be.
How to read the examples
Each example shows:
- the business services people use in the top row;
- the technical services they depend on in the rows below, with a line for each depends on;
- offerings inside their service, with their team when it differs.
In Help, point at a service to see everything it relies on and everything that relies on it.
BIZ- Offering
TECHwhat the business service needs to work
Office work on Microsoft 365 or Google Workspace
Most companies' first services. Microsoft or Google runs the platform; you run the setup, the accounts and the support.
MAIL- Shared mailboxes
- Email archiveCompliance
TEAMSFILESIDPsign-in, MFA, accounts (Entra ID or Google)
M365Why this way: people ask for help with email, chat and files, so those are the business services. The tenant and the sign-in are what they all share; when sign-in fails, all three show it in If IDP has a problem. The archive is an offering because it belongs to email, but another team looks after it.
A web shop
A customer-facing shop with a front end, an API, payments through a provider, and a database.
SHOP- B2B portalB2B team
TRACKCHECKOUTSEARCHe.g. Elasticsearch or OpenSearch
CDNe.g. Cloudflare or Fastly
PAYORDERSthe API and its database
DBe.g. PostgreSQL or MySQL
Why this way: customers only know “the shop” and “tracking my order”. Under that, each piece a different team owns, or a supplier runs, is its own technical service. Follow the chain from the bottom: if the database platform has a problem, the order platform, checkout, the online store and order tracking can all be affected, and the service page for DB lists every one of them.
A software product you run for customers (SaaS)
A product your customers sign in to, with an API, running on Kubernetes in a cloud.
APPAPIREPORTSK8SKubernetes clusters
AUTHe.g. Keycloak or Auth0
DWHCICDGitHub Actions or GitLab; nothing customers use depends on it
DBCLOUDWhy this way: the release pipeline is still a service, with an owner and a team, but nothing customer-facing depends on it, so its outage doesn't spread. Tiers follow what customers feel: reports can wait, sign-in can't.
Remote access and the network
A classic infrastructure setup, where one service has clear variants.
VPN- Remote user VPN
- Site-to-site VPNNetwork engineering
WIFIINETFWIDPISPNETswitching and routing
Why this way: users and other companies both use the VPN but get very different help, so they are offerings of one service with one owner. If NET has a problem shows firewalls, the VPN and its offerings, Wi-Fi and internet access, which is exactly the list of things people will soon call about.
A business system bought as a service
Payroll, CRM or ERP bought from a supplier, with your own integrations.
PAYROLLCRMPAYROLL-SAASIDPINTmoves data between systems
CRM-SAASWhy this way: even when a vendor runs the system, you own the service your people use, the integrations and the first line of support. Keeping the vendor's platform as its own technical service makes it clear where your part ends, which helps both in incidents and when an auditor asks about suppliers.
Workplace and devices
The services an office runs on, often the ones with the most cases.
PC- New starter setup
- Repairs and replacements
MOBILEPRINTMDMe.g. Intune or Jamf
NETIDPWhy this way: new starters and repairs are requests about the same service, handled by the same team, so they are offerings rather than services of their own. That keeps the catalogue short while still letting you count the cases for each.
Common mistakes
| Mistake | Why it hurts, and what to do instead |
|---|---|
| One service per server or application | You end up with hundreds of services nobody asks for by name. Group them under the service people use, and keep the parts in their own tools. |
| Dependencies on everything “just in case” | The chain then flags half the catalogue for every problem. Add a dependency only when an outage really passes through. |
| A service without an owner | Someone has to answer for it, keep its record right and confirm it once a year. |
| Teams as services | “Network team” isn't a service; “Core network” is. The team goes in Support team. |
| Waiting for the perfect catalogue | Start small (below). |
[!TIP] Start with the ten services you get most cases about. Add the technical services under them as incidents show you where the chains run.