A poorly defined service catalog — or no catalog at all — forces users to guess how to request IT help, creates inconsistent service delivery, and buries your team in redundant tickets. Building a solid service catalog fixes all three problems at once. This guide walks you through every step: what to include, how to structure IT service catalog categories, real service catalog examples, and how to manage it over time.
What Is a Service Catalog?
A service catalog is a centralized, organized list of IT services your organization offers to its users. Each entry describes what the service does, who can request it, how long it takes, and what it costs (if anything). Think of it as the internal equivalent of a product menu — users know exactly what’s available and how to order it.
It’s worth distinguishing three related concepts that often get confused:
- Service catalog: The user-facing list of active, available services.
- Service portfolio: A broader internal view that includes services in planning, active services, and retired services.
- Self-service portal: The interface through which users access the catalog and submit requests. The portal is the delivery mechanism; the catalog is the content.
Service catalogue management — the ongoing process of keeping this catalog accurate, up to date, and aligned with business needs — is a formal discipline in ITIL and an underrated driver of service desk efficiency.
Why Building a Service Catalog Matters
Without a service catalog, requests arrive in whatever format users choose: emails, hallway conversations, Slack messages, or tickets that say nothing more than “my laptop is broken.” The IT team spends time just figuring out what the user needs before they can even start solving it.
A well-built service catalog benefits both sides of the interaction:
- For users: Clear expectations on what’s available, how to request it, and when to expect a response.
- For IT teams: Structured intake that feeds directly into fulfillment workflows, reducing back-and-forth and manual triage.
- For IT managers: Visibility into demand patterns, workload distribution, and service costs.
- For the business: Consistent service delivery that can be measured, improved, and reported on.
IT Service Catalog Categories: How to Structure Your Catalog
Before you list individual services, you need a logical category structure. Users should be able to find what they need in two clicks or fewer. Overly deep category trees increase friction and reduce adoption.
Common IT service catalog categories include:
- Hardware & Equipment: Laptop requests, monitor provisioning, peripheral replacements, mobile device setup.
- Software & Licensing: Application installation, license requests, software upgrades, trial activations.
- Access & Identity: New user provisioning, password resets, VPN access, permission changes, account deactivation.
- Network & Connectivity: Wi-Fi troubleshooting, VPN setup, network drive mapping, firewall rule requests.
- Communication & Collaboration: Email setup, video conferencing tools, shared mailbox requests, Teams/Slack channel provisioning.
- Security: Security awareness training enrollment, MFA setup, endpoint protection, security incident reporting.
- Business Applications: ERP access, CRM support, HR system requests, custom LOB application help.
- Facilities & IT Infrastructure: Conference room AV setup, printer configuration, server provisioning.
Align your categories with how your users think about their needs, not how your IT team organizes its own work. A user looking for “Zoom” shouldn’t have to navigate through “Unified Communications Infrastructure” to find it.
How to Build a Service Catalog: Step by Step
Step 1: Audit Your Current Services
Start by taking inventory of everything your IT team currently delivers. Pull data from your ticketing system: what are the most common request types over the past 6–12 months? Interview team leads in each IT domain. Don’t rely on memory or assumptions — your actual ticket data will reveal services you’re delivering informally that have never been documented.
At this stage, don’t worry about format. You’re building a raw list. Include recurring requests, one-off projects that repeat annually, and anything that currently arrives as an unstructured email.
Step 2: Define Each Service Entry
For each service, document the following fields. This is the core information that goes into the catalog:
- Service name: Clear and user-friendly. “Request a New Laptop” is better than “Hardware Provisioning — End User Compute.”
- Description: 1–3 sentences explaining what the service covers and what it doesn’t.
- Who can request it: All employees, specific departments, managers only, etc.
- How to request it: Link to the form, portal, or contact point.
- Service Level Agreement (SLA): Expected fulfillment time. Be realistic — an overpromised SLA destroys trust faster than no SLA at all.
- Approvals required: Does this require manager sign-off? IT director approval? Automatic approval?
- Cost (if any): Charge-back amounts, cost center allocations, or a note that the service is provided at no charge to the requester.
- Owning team: Which IT group is responsible for fulfilling this service?
Step 3: Separate Incidents from Service Requests
A common mistake when building a service catalog is mixing incidents (something is broken) with service requests (I need something new). These are different ITSM processes with different workflows and SLAs. Your catalog should focus on requests — planned, repeatable fulfillment activities.
Incidents — a server outage, a user locked out unexpectedly, a system crash — are handled through incident management and should have their own reporting pathway. Keeping these separate makes your catalog cleaner and your metrics more meaningful.
Step 4: Design the Request Forms
Every catalog item should have a structured intake form that captures exactly the information needed to fulfill the request without follow-up questions. Over-long forms kill adoption; under-specified forms create rework. A good rule of thumb: ask only what you need, and no more.
For a software license request, you might need: requester name, department, software name, business justification, and required date. For a VPN access request, you need: user ID, device type, and remote location. Map the form fields to your fulfillment checklist so the person receiving the ticket has everything they need from the first submission.
Step 5: Define Fulfillment Workflows
Behind each catalog item is a fulfillment workflow — the sequence of steps that gets the request from submission to resolution. Document these workflows explicitly, even for simple tasks. This serves two purposes: it enables automation, and it ensures consistent service delivery regardless of which technician handles the ticket.
For tools like ServiceNow, Jira Service Management, or InvGate Service Management, these workflows can be built directly into the platform as automated task sequences, approval routing rules, and assignment logic. Even if you’re starting with a simpler setup, having the workflow documented makes future automation much easier.
Step 6: Set SLAs for Each Service
SLAs set expectations and create accountability. For each catalog item, define:
- Response time: How quickly will IT acknowledge the request?
- Fulfillment time: How long will the complete delivery take?
- Business hours vs. 24/7: Does the clock run on business hours or continuously?
Differentiate SLAs by priority or impact. A “new employee onboarding” request has a hard deadline tied to a start date. A “request an additional monitor” is lower urgency. Your catalog should reflect these distinctions so your team prioritizes accordingly.
Step 7: Build the Catalog in Your ITSM Tool
Once you’ve documented your services, forms, workflows, and SLAs, it’s time to configure them in your ITSM platform. Most enterprise ITSM tools — ServiceNow, Jira Service Management, Freshservice, ManageEngine ServiceDesk Plus, InvGate Service Management — have dedicated service catalog modules where you can build catalog items, attach forms, and connect fulfillment workflows.
If you’re building a service catalog in ServiceNow specifically, the platform uses a structured catalog item framework with variables (form fields), catalog categories, and fulfillment flows built in the Flow Designer or legacy Workflow Editor. The architecture is powerful but has a meaningful learning curve — most organizations work with a ServiceNow admin or partner for the initial build.
For teams using simpler tools or even a well-structured spreadsheet as a starting point, the documentation from Steps 1–6 still applies. A spreadsheet service catalog is a legitimate intermediate step — it’s better to have a documented catalog in a spreadsheet than an undocumented one in an expensive platform.
Step 8: Publish and Communicate
A service catalog that users don’t know exists delivers no value. Before launch, communicate the catalog to your user base with a clear message: here’s where to go for IT help, here’s what’s available, and here’s what to expect. Include the catalog link in IT email signatures, onboarding documentation, and your intranet homepage.
Run a short awareness campaign — even a single all-hands message or email — explaining why the catalog exists and how it benefits users. Adoption won’t be instant, but clear communication at launch sets the right expectations.
Step 9: Review and Maintain the Catalog
Service catalogue management is not a one-time project. Services change, new applications get adopted, old ones are retired, and SLAs that made sense a year ago may no longer reflect your team’s capacity. Set a recurring review cadence — quarterly at minimum — to audit catalog items for accuracy, retire services no longer offered, and add new ones that have emerged.
Assign a catalog owner responsible for the overall catalog structure. Without an owner, the catalog gradually drifts out of date, which erodes user trust and ultimately pushes people back to emailing IT directly.
Service Catalog Examples
Seeing concrete examples helps clarify what a well-defined catalog item looks like in practice. Here are three representative examples across common IT service catalog categories:
| Service Name | Category | Who Can Request | SLA | Approval Required |
|---|---|---|---|---|
| New Employee IT Onboarding | Access & Identity | HR / Managers only | 3 business days before start date | Department head |
| Software License Request | Software & Licensing | All employees | 5 business days | Manager + IT approval |
| VPN Access Setup | Network & Connectivity | All employees | 1 business day | Auto-approved |
| Password Reset | Access & Identity | All employees | 15 minutes (self-service) | None |
| Conference Room AV Setup | Facilities & Infrastructure | All employees | 2 business days | None |
A real business service catalogue entry would include more detail — the full description, form fields, fulfillment steps, and the owning team. These examples illustrate the structure; your actual entries should be more granular.
Service Catalog Best Practices
- Write for users, not IT staff. Every service name and description should make sense to someone outside the IT department. Avoid jargon and internal terminology.
- Keep the catalog focused. Don’t list every possible IT interaction — focus on repeatable, requestable services. One-off projects and incidents belong elsewhere.
- Start smaller than you think you need to. A catalog with 20 well-documented services is more useful than one with 80 poorly-defined entries. You can always expand.
- Link SLAs to real capacity. Publish SLAs your team can consistently meet. Missing your own published SLAs consistently is worse than setting longer realistic ones.
- Make it searchable. Users will search before they browse. Ensure your ITSM tool’s catalog search includes common synonyms — “Zoom” should surface the “Video Conferencing Setup” item.
- Assign catalog ownership. Without a named owner, maintenance falls through the cracks. The catalog owner doesn’t need to maintain everything personally — they just ensure it gets done.
Frequently Asked Questions
What is the difference between a service catalog and a service portfolio?
A service catalog is the user-facing subset of the service portfolio — it shows only active, available services. The service portfolio is a broader internal document that includes services in development, active services, and retired services. Users interact with the catalog; IT management uses the portfolio for planning and governance.
What should an IT service catalog include?
Each catalog item should include a clear service name, a plain-language description, eligibility (who can request it), the request process, expected fulfillment time (SLA), any approvals required, and the owning IT team. Optionally, include cost information if your organization uses IT charge-backs.
How do you build a service catalog in ServiceNow?
In ServiceNow, service catalog items are created in the Service Catalog application. You define catalog categories, create catalog items with variables (form fields), and attach fulfillment workflows built in Flow Designer or the Workflow Editor. ServiceNow’s catalog framework is powerful and supports complex approval chains and task sequences, but initial configuration typically requires a certified admin or implementation partner.
How many services should a service catalog have?
There’s no fixed number, but most mid-size IT organizations find 30–60 well-defined catalog items covers the majority of their request volume. The right number depends on your organization’s size, IT scope, and how granularly you want to track different request types. Prioritize quality over quantity — a lean, accurate catalog outperforms a bloated, inconsistent one.
How often should a service catalog be updated?
At minimum, review the catalog quarterly. Review it immediately whenever a major application change occurs, a new service launches, or an existing service is retired. Assign a catalog owner to track these triggers and ensure updates happen promptly rather than accumulating during annual reviews.
Pricing accurate as of the publish date and subject to change. Verify current pricing on each vendor’s official site before purchasing.
Photo by João Victor da Silva Ribeiro on Unsplash
