Back to Service Catalog

Service Catalog Schema v1.0 Implementation Guide

Complete implementation guide for the Service Catalog Schema. This schema provides a structured approach to IT service management, enabling organizations to document, publish, and manage their IT services with clear ownership, support structures, and service level commitments.

📖 30 min read 📋 Service Catalog v1.0 💎 Pro Tier 🎯 8 Object Types

Executive Summary

The Service Catalog Schema provides a structured approach to IT service management, enabling organizations to document, publish, and manage their IT services with clear ownership, support structures, and service level commitments. This schema aligns with ITIL Service Catalog Management practices.

Target Organizations

  • IT departments formalizing their service offerings
  • Organizations implementing ITIL Service Catalog
  • Teams seeking to improve service request fulfillment
  • Companies building self-service portals

Business Value Delivered

Benefit Impact
Service Visibility Clear catalog of what IT provides
Defined SLAs Consistent service level expectations
Clear Ownership Accountability for every service
Self-Service Enablement Users find answers without tickets
Faster Request Routing Requests go to the right team

Schema Capabilities

  • Service categorization and organization
  • Service level agreement definitions
  • Support team assignment and escalation
  • Service offering and request type management
  • Knowledge article linking for self-service

Related Documents

Schema Architecture

ITIL Service Catalog Alignment

The Service Catalog Schema supports ITIL Service Catalog Management:

ITIL Concept Schema Support
Service Portfolio Business Service with Status lifecycle
Service Catalog Published services with offerings
Service Level Management Service Level object type
Request Fulfillment Service Request Type and Service Offering
Knowledge Management Knowledge Article linked to services

Object Type Hierarchy

The schema organizes into four tiers:

Tier 1 - Organization:

  • Service Category, Support Team, Service Owner
  • Provides structure and accountability

Tier 2 - Services:

  • Business Service, Service Level
  • Core service definitions with SLAs

Tier 3 - Offerings:

  • Service Offering, Service Request Type
  • What users can request

Tier 4 - Knowledge:

  • Knowledge Article
  • Self-service documentation

Reference Types

Reference Type Color Purpose Example
Categorized As Blue (#0052CC) Service organization Service → Category
Owned By Green (#00875A) Business ownership Service → Service Owner
Supported By Purple (#6554C0) Technical support Service → Support Team
Documented In Orange (#FF8B00) Knowledge linking Service ← Knowledge Article

Object Type Reference

Object Type 1: Service Category

Purpose and Business Context

The Service Category object type organizes services into logical groups for easy navigation. Categories appear in service portals and help users find relevant services.

Why Service Category records matter:

  • Portal Navigation: Users browse services by category
  • Reporting: Service metrics by category
  • Governance: Category-level ownership
  • Organization: Logical grouping of related services

Attribute Reference

Attribute Type Required Description
Category Name Text Yes Display name for the category (e.g., "Infrastructure Services")
Description Textarea No What services belong in this category
Icon Text No Icon identifier for portal display
Display Order Number No Sort order in portal (lower = first)
Status Select Yes Active or Inactive

Implementation Best Practices

Category Design Principles:

  1. Limit to 5-10 top-level categories
  2. Use user-friendly names (not IT jargon)
  3. Align with how users think about services
  4. Consider future growth

Recommended Categories:

Category Description Example Services
Getting Started New employee services Account Setup, Equipment Request
Hardware Physical equipment Laptop, Monitor, Mobile Device
Software Applications and tools Software Request, License
Access & Security Permissions and access Password Reset, VPN Access
Communication Email, collaboration Email Distribution List, Teams
Support Help and troubleshooting General IT Support, Report Issue

Real-World Example

Category Name: Software & Applications
Description: Request software installations, licenses, and application access
Icon: application
Display Order: 3
Status: Active

Object Type 2: Service Level

Purpose and Business Context

The Service Level object type defines SLA tiers that can be assigned to services. Each level specifies availability, response, and resolution targets.

Why Service Level records matter:

  • Expectations: Clear commitments to service consumers
  • Prioritization: Higher SLAs get faster response
  • Measurement: Track performance against targets
  • Pricing: Different SLA tiers may have different costs

Attribute Reference

Attribute Type Required Description
Level Name Text Yes SLA tier name (e.g., "Gold", "Standard")
Description Textarea No What this level includes
Availability Target Text No Uptime commitment (e.g., "99.9%")
Response Time Text No Initial response target (e.g., "15 minutes")
Resolution Time Text No Resolution target (e.g., "4 hours")
Support Hours Select No 24x7, Business Hours, Extended Hours
Status Select Yes Active or Deprecated

Standard SLA Tiers

Level Availability Response Resolution Support Use Case
Platinum 99.99% 5 min 1 hour 24x7 Mission-critical
Gold 99.9% 15 min 4 hours 24x7 Business-critical
Silver 99.5% 1 hour 8 hours Extended Standard production
Bronze 99% 4 hours 24 hours Business Non-critical

Real-World Example

Level Name: Gold
Description: High-priority support for business-critical services with 24x7 coverage
Availability Target: 99.9%
Response Time: 15 minutes
Resolution Time: 4 hours
Support Hours: 24x7
Status: Active

Object Type 3: Support Team

Purpose and Business Context

The Support Team object type represents teams that provide operational support for services. Support Teams are assigned to services for incident routing.

Why Support Team records matter:

  • Incident Routing: Tickets go to the right team
  • Escalation: Clear escalation paths
  • On-Call: Know who's available when
  • Communication: Team contact information

Attribute Reference

Attribute Type Required Description
Team Name Text Yes Team identifier (e.g., "Platform Engineering")
Email Email No Team distribution list
Slack Channel Text No Slack channel for team communication
On-Call Schedule URL No Link to on-call rotation
Escalation Path Textarea No Who to escalate to and when
Status Select Yes Active or Inactive

Implementation Best Practices

Team Design:

  • Align with organizational structure
  • Include contact methods used during incidents
  • Document escalation paths clearly
  • Keep on-call schedule links current

Escalation Path Format:

Level 1 (0-30 min): On-call engineer via PagerDuty
Level 2 (30-60 min): Team Lead - Jane Smith (jane@company.com)
Level 3 (60+ min): Engineering Director - John Doe (john@company.com)
After hours: Follow on-call rotation

Real-World Example

Team Name: Platform Engineering
Email: platform-team@acme.com
Slack Channel: #platform-support
On-Call Schedule: https://pagerduty.com/schedules/platform
Escalation Path:
  L1: On-call engineer (PagerDuty)
  L2: Platform Lead - Sarah Chen (30 min)
  L3: VP Engineering - Mike Johnson (60 min)
Status: Active

Object Type 4: Service Owner

Purpose and Business Context

The Service Owner object type represents individuals accountable for services. Service Owners make decisions about service scope, priorities, and investments.

Why Service Owner records matter:

  • Accountability: Single point of accountability per service
  • Decisions: Who approves changes to the service
  • Communication: Contact for service discussions
  • Governance: Service review participation

Attribute Reference

Attribute Type Required Description
Full Name Text Yes Owner's full name
Email Email Yes Work email for communication
Department Text No Business department
Phone Text No Direct phone number
Status Select Yes Active or Inactive

Service Owner Responsibilities

Responsibility Description
Service Strategy Define service direction and roadmap
Prioritization Prioritize enhancements and fixes
Budget Manage service budget and costs
SLA Accountability Accountable for meeting SLAs
Stakeholder Communication Communicate service status
Review Participation Participate in service reviews

Real-World Example

Full Name: Jennifer Martinez
Email: jennifer.martinez@acme.com
Department: Product Management
Phone: +1-555-0123
Status: Active

Object Type 5: Business Service

Purpose and Business Context

The Business Service object type is the core of the service catalog - representing IT services available to the organization. Business Services are what users consume.

Why Business Service records matter:

  • Service Catalog: What IT offers to the business
  • SLA Commitments: Service level promises
  • Impact Analysis: Understanding service dependencies
  • Status Communication: Current service health

Attribute Reference

Attribute Type Required Description
Service Name Text Yes User-facing service name
Description Textarea No What the service provides
Category Object (Service Category) No Service category for organization
Service Level Object (Service Level) No SLA tier for this service
Owner Object (Service Owner) Yes Business owner accountable
Support Team Object (Support Team) No Team providing support
Criticality Select Yes Critical, High, Medium, Low
Status Select Yes Operational, Degraded, Outage, Maintenance, Retired

Criticality Definitions

Criticality Definition Examples
Critical Business stops without this Payment processing, Core ERP
High Major business impact CRM, Email
Medium Efficiency impact Reporting, Analytics
Low Convenience services Training platform

Status Values

Status Meaning Portal Display
Operational Fully functional Green indicator
Degraded Partial functionality Yellow indicator
Outage Completely unavailable Red indicator
Maintenance Planned downtime Blue indicator
Retired No longer available Hidden from catalog

Real-World Example

Service Name: Email & Collaboration
Description: Microsoft 365 email, calendar, and Teams collaboration platform
Category: Communication
Service Level: Gold
Owner: Jennifer Martinez
Support Team: Platform Engineering
Criticality: High
Status: Operational

Object Type 6: Service Offering

Purpose and Business Context

The Service Offering object type represents specific things users can request within a service. Offerings are the "menu items" in your service catalog.

Why Service Offering records matter:

  • Request Clarity: Users know exactly what they can request
  • Fulfillment Process: Standard process per offering
  • Pricing: Optional cost information
  • Approval: Different offerings need different approvals

Attribute Reference

Attribute Type Required Description
Offering Name Text Yes What users can request
Description Textarea No Details about the offering
Service Object (Business Service) Yes Parent service
Price Text No Cost if applicable
Fulfillment Time Text No Expected delivery time
Request URL URL No Link to request form
Approval Required Select No Yes or No
Status Select Yes Available, Coming Soon, Retired

Offering Examples by Service

Email & Collaboration Service:

  • New Distribution List (Fulfillment: 1 day, No approval)
  • Shared Mailbox (Fulfillment: 1 day, Manager approval)
  • Teams Channel Creation (Fulfillment: Same day, No approval)
  • Guest Access Request (Fulfillment: 2 days, IT Lead approval)

Hardware Service:

  • Standard Laptop (Fulfillment: 3 days, Manager approval)
  • Developer Laptop (Fulfillment: 5 days, IT Lead approval)
  • External Monitor (Fulfillment: 3 days, Manager approval)
  • Mobile Device (Fulfillment: 5 days, Manager approval)

Real-World Example

Offering Name: New Distribution List
Description: Create a new email distribution list for your team or project
Service: Email & Collaboration
Price: No charge
Fulfillment Time: 1 business day
Request URL: https://jira.acme.com/servicedesk/portal/5/DL-REQUEST
Approval Required: No
Status: Available

Object Type 7: Knowledge Article

Purpose and Business Context

The Knowledge Article object type represents self-service documentation linked to services. Knowledge articles help users resolve issues without creating tickets.

Why Knowledge Article records matter:

  • Self-Service: Users solve problems independently
  • Ticket Deflection: Fewer routine tickets
  • Consistent Answers: Standard solutions documented
  • Service Context: Articles linked to relevant services

Attribute Reference

Attribute Type Required Description
Title Text Yes Article title for search
URL URL Yes Link to the knowledge article
Article Type Select Yes How-To, FAQ, Troubleshooting, Policy, Reference
Service Object (Business Service) No Related service
Last Updated Date No Content freshness date
Views Number No View count for popularity
Status Select Yes Published, Draft, Archived

Article Type Guidelines

Type Purpose Example Title
How-To Step-by-step instructions "How to Reset Your Password"
FAQ Common questions answered "VPN Frequently Asked Questions"
Troubleshooting Problem resolution guides "Outlook Not Syncing - Troubleshooting"
Policy Rules and requirements "Software Installation Policy"
Reference Technical documentation "Supported Browser Versions"

Real-World Example

Title: How to Set Up Outlook on Mobile
URL: https://confluence.acme.com/kb/outlook-mobile-setup
Article Type: How-To
Service: Email & Collaboration
Last Updated: 2026-01-15
Views: 1,247
Status: Published

Object Type 8: Service Request Type

Purpose and Business Context

The Service Request Type object type defines the types of requests that can be made for each service, with expected SLAs and approval requirements.

Why Service Request Type records matter:

  • Request Classification: Categorize incoming requests
  • SLA Assignment: Different types get different SLAs
  • Approval Routing: Route for appropriate approvals
  • Reporting: Request volume by type

Attribute Reference

Attribute Type Required Description
Request Type Name Text Yes Type of request
Description Textarea No When to use this request type
Service Object (Business Service) Yes Parent service
Expected SLA Object (Service Level) No SLA for this request type
Approval Required Select No None, Manager, IT Lead, Multiple
Form URL URL No Link to request form
Status Select Yes Active or Inactive

Common Request Types

Request Type Approval Typical SLA
New Access Manager Silver
Access Removal None Bronze
Configuration Change IT Lead Silver
Incident None Per criticality
Information Request None Bronze

Real-World Example

Request Type Name: New User Access
Description: Request access to the Email & Collaboration platform for a new team member
Service: Email & Collaboration
Expected SLA: Silver
Approval Required: Manager
Form URL: https://jira.acme.com/servicedesk/portal/5/NEW-ACCESS
Status: Active

Implementation Phases

Phase 1: Foundation (Week 1-2)

Objectives:

  • Deploy schema
  • Define service categories
  • Establish SLA tiers

Activities:

  1. Deploy Service Catalog Schema
  2. Create Service Category records (5-10 categories)
  3. Define Service Level tiers (3-5 levels)
  4. Document governance model
  5. Identify initial service owners

Deliverables:

  • Deployed schema
  • Category structure
  • SLA definitions

Phase 2: Support Structure (Week 3)

Objectives:

  • Document support teams
  • Assign service owners

Activities:

  1. Create Support Team records
  2. Document escalation paths
  3. Create Service Owner records
  4. Link to existing identity systems if applicable

Deliverables:

  • Support team directory
  • Owner assignments

Phase 3: Core Services (Week 4-5)

Objectives:

  • Document major services
  • Assign SLAs and owners

Activities:

  1. Identify top 10-20 business services
  2. Create Business Service records
  3. Assign categories, SLAs, owners, support teams
  4. Document service descriptions

Deliverables:

  • Core service catalog
  • Owner and support assignments

Phase 4: Offerings & Requests (Week 6-7)

Objectives:

  • Define service offerings
  • Create request types

Activities:

  1. For each service, identify offerings
  2. Create Service Offering records
  3. Create Service Request Type records
  4. Link to request forms

Deliverables:

  • Service offerings published
  • Request types defined

Phase 5: Knowledge & Portal (Week 8+)

Objectives:

  • Link knowledge articles
  • Enable self-service portal

Activities:

  1. Create Knowledge Article records
  2. Link articles to services
  3. Configure service portal
  4. Train support teams
  5. Launch to users

Deliverables:

  • Knowledge base linked
  • Self-service portal live

Integration Patterns

Service Desk Integration

Pattern: Service catalog drives request routing and SLA application

Implementation:

  1. Service Request Type determines routing
  2. Service Level determines SLA targets
  3. Support Team receives assignments
  4. Service Owner notified of escalations

Status Page Integration

Pattern: Business Service status feeds status page

Implementation:

  1. Service status changes trigger webhook
  2. Status page updates automatically
  3. Subscribers notified of changes

Knowledge Base Integration

Pattern: Knowledge articles suggested based on service context

Implementation:

  1. User selects service for request
  2. Related Knowledge Articles displayed
  3. User may self-resolve without ticket
Back to Template
Service Catalog Overview
Next Document
Forms Specification