Service Catalogue Management

A service catalogue is a structured repository of information about IT services available to users, containing enough detail for consumers to understand what each service provides, how to request it, and what service levels apply. This task covers the procedures for creating service definitions, organising them into a coherent catalogue structure, publishing the catalogue for user access, and maintaining accuracy through regular review cycles.

The catalogue serves two distinct audiences with different information needs. Business users require descriptions in non-technical language explaining what outcomes a service enables, who can access it, and how to request it. Technical staff require architectural details showing component dependencies, support responsibilities, and integration points. A well-structured catalogue addresses both views while maintaining a single source of truth.

Service

A means of delivering value to users by facilitating outcomes they want to achieve without ownership of specific costs and risks. In practical terms, a defined set of IT capabilities with documented scope, support arrangements, and access mechanisms.

Service catalogue

The subset of the service portfolio containing services currently available to users. Excludes services in development (pipeline) and retired services.

Service portfolio

The complete set of services managed by IT, including pipeline services not yet available, catalogue services currently offered, and retired services no longer offered.

Service offering

A specific variant of a service configured for a particular user segment or use case. A single service can have multiple offerings with different features, support levels, or costs.

Prerequisites

Before beginning service catalogue development, verify these requirements:

You need read access to existing documentation including architecture diagrams, support procedures, vendor contracts, and any previous service descriptions. Gather access credentials for the ITSM tool if one exists, as service desk data reveals actual service usage patterns.

Identify three to five stakeholders per service: the service owner who holds accountability, technical staff who operate the service, and business representatives who consume it. Schedule 30-minute interviews with each during the documentation phase.

Procedure

Define the catalogue structure

1. Establish the top-level service categories that organise the catalogue. Categories should reflect how users think about IT services rather than how IT is organised internally. A charity providing health programmes might use categories like “Communication and Collaboration”, “Programme Delivery Systems”, “Finance and Administration”, and “Security and Access” rather than mirroring internal teams like “Infrastructure” or “Applications”.

   Create between 4 and 8 top-level categories. Fewer than 4 forces unrelated services together; more than 8 makes navigation difficult. Each category should contain between 3 and 15 services in the final catalogue.

2. Define the service portfolio stages that track service lifecycle:

   +------------------+     +------------------+     +------------------+
   |                  |     |                  |     |                  |
   |     PIPELINE     |---->|    CATALOGUE     |---->|     RETIRED      |
   |                  |     |                  |     |                  |
   |  Services in     |     |  Services        |     |  Services no     |
   |  development or  |     |  available to    |     |  longer offered  |
   |  planning        |     |  users today     |     |                  |
   |                  |     |                  |     |                  |
   |  Not visible to  |     |  Visible to      |     |  Visible for     |
   |  users           |     |  users           |     |  reference only  |
   |                  |     |                  |     |                  |
   +------------------+     +------------------+     +------------------+

Figure 1: Service portfolio stages showing progression from pipeline through catalogue to retirement

Only catalogue-stage services appear in the user-facing catalogue. Pipeline services remain internal until launch. Retired services may remain visible with clear “no longer available” status to help users understand historical references.

3. Create the service record template that standardises what information each service entry contains. Store the template in your documentation system with field definitions and completion guidance.

   Required fields for every service:

   service_record:
     # Identity
     service_id: "SVC-001"          # Unique identifier
     service_name: "Email Service"  # User-friendly name
     category: "Communication and Collaboration"
     status: "catalogue"            # pipeline | catalogue | retired

     # Ownership
     service_owner: "Jane Smith"
     service_owner_email: "j.smith@example.org"
     support_team: "IT Service Desk"
     escalation_contact: "Systems Administrator"

     # Description
     description: |
       Organisation email including mailboxes, calendars, and contacts.
       Accessible via web browser, desktop client, and mobile devices.

     # Access
     eligible_users: "All staff and long-term consultants"
     request_method: "Automatic provisioning on joining"
     access_url: "https://mail.example.org"

     # Service levels
     availability_target: "99.5%"
     support_hours: "Monday-Friday 08:00-18:00 local time"
     response_time: "4 hours for service affecting, 8 hours for individual"

     # Relationships
     depends_on: ["SVC-012", "SVC-015"]  # Identity, Internet Access
     supports: ["All business services"]

     # Metadata
     created_date: "2024-01-15"
     last_reviewed: "2024-06-01"
     next_review: "2024-12-01"

4. Map the relationship between business services and technical services. Business services describe outcomes users care about: “I can send and receive email.” Technical services describe IT components that enable those outcomes: mail servers, identity systems, network connectivity, backup systems.

   +-----------------------------------------------------------------------+
   |                        BUSINESS SERVICE VIEW                          |
   |                     (What users see and request)                      |
   +-----------------------------------------------------------------------+
   |                                                                       |
   |  +-------------------+  +-------------------+  +-------------------+  |
   |  |                   |  |                   |  |                   |  |
   |  |  Email Service    |  |  File Storage     |  |  Video Meetings   |  |
   |  |                   |  |                   |  |                   |  |
   |  +--------+----------+  +--------+----------+  +--------+----------+  |
   |           |                      |                      |             |
   +-----------------------------------------------------------------------+
               |                      |                      |
               v                      v                      v
   +-----------------------------------------------------------------------+
   |                       TECHNICAL SERVICE VIEW                          |
   |                    (What IT manages and operates)                     |
   +-----------------------------------------------------------------------+
   |                                                                       |
   |  +-------------+  +-------------+  +-------------+  +-------------+   |
   |  |             |  |             |  |             |  |             |   |
   |  | Mail Server |  | File Server |  | Video       |  | Identity    |   |
   |  | (Exchange/  |  | (SharePoint/|  | Platform    |  | Provider    |   |
   |  | Google)     |  | Nextcloud)  |  | (Teams/     |  | (Entra/     |   |
   |  |             |  |             |  | Jitsi)      |  | Keycloak)   |   |
   |  +------+------+  +------+------+  +------+------+  +------+------+   |
   |         |                |                |                |          |
   |         +----------------+----------------+----------------+          |
   |                                   |                                   |
   |                          +--------+--------+                          |
   |                          |                 |                          |
   |                          |  Network        |                          |
   |                          |  Infrastructure |                          |
   |                          |                 |                          |
   |                          +-----------------+                          |
   |                                                                       |
   +-----------------------------------------------------------------------+

Figure 2: Business services map to multiple technical services; technical services support multiple business services

Document these relationships in the service records. When a technical service experiences issues, the relationships identify which business services are affected.

Document individual services

1. Inventory existing services by reviewing multiple information sources. Service desk tickets reveal what users actually request and what IT actually provides, which sometimes differs from official documentation. Review the last 6 months of tickets, extracting service names and categorising by type.

   Review infrastructure and application inventories. Each production system likely supports one or more services. Vendor contracts identify externally provided services. Interview IT staff about undocumented services they operate.

   Create a working list with one row per identified service:

   Service Name	Source	Owner (if known)	Status
   Email	Infrastructure list, tickets	IT Manager	Active
   Programme Database	Application inventory	Programme Director	Active
   Legacy Finance System	Vendor contract	Finance Manager	Active, retiring 2025
   Staff WiFi	Infrastructure list	IT Manager	Active

2. Prioritise documentation order. Start with services that have the highest user impact and request volume. A service handling 50 requests per month needs documentation before one handling 2 requests per month.

   Assign priority scores:

   Factor	Weight	Scoring
   User request volume	40%	High (>20/month)=3, Medium (5-20)=2, Low (<5)=1
   Business criticality	35%	Mission-critical=3, Important=2, Supporting=1
   Documentation gap	25%	None exists=3, Partial=2, Complete=1

   Calculate weighted score and sort descending. Document the top 10 services first to establish patterns before tackling the remainder.

3. Conduct service owner interviews using a structured question set. Schedule 30 minutes per service. Record answers directly into the service record template.

   Interview questions:

   SERVICE OWNER INTERVIEW GUIDE

   Service: ________________________________
   Owner: ________________________________
   Date: ________________________________

   SCOPE AND PURPOSE
   - What does this service enable users to do?
   - Who is eligible to use this service?
   - What is explicitly excluded from this service scope?

   ACCESS AND REQUEST
   - How do users request access to this service?
   - What approvals are required?
   - How long does provisioning take?

   SUPPORT AND SERVICE LEVELS
   - What hours is support available?
   - What is the target response time for issues?
   - What availability target applies?
   - Who provides first-line support?
   - Who handles escalations?

   DEPENDENCIES
   - What other services must be working for this service to function?
   - What other services depend on this one?

   COSTS (if applicable)
   - Is there a cost associated with this service?
   - How is it charged (per user, flat rate, usage-based)?

   PLANNED CHANGES
   - Are any significant changes planned in the next 12 months?
   - Is this service being retired or replaced?

4. Write user-facing service descriptions that non-technical staff can understand. Avoid jargon and acronyms. Focus on what the service enables rather than how it works technically.

   Poor description: “Microsoft 365 E3 licensing providing Exchange Online, SharePoint Online, and Teams with Azure AD P1 integration.”

   Good description: “Organisation email, calendar, and contacts accessible from any device. Includes 50 GB mailbox storage, shared calendars for scheduling meetings, and address book with all staff contacts. Works in web browsers, Outlook desktop application, and mobile email apps.”

5. Document technical details in a separate section or linked technical view. Include architecture components, dependencies, configuration parameters, and operational procedures. This information serves IT staff, not end users.

   technical_details:
     platform: "Microsoft 365"
     licence_type: "E3"
     tenant_id: "example.onmicrosoft.com"

     components:
       - name: "Exchange Online"
         purpose: "Mailbox hosting"
         admin_url: "https://admin.exchange.microsoft.com"
       - name: "Azure AD"
         purpose: "Authentication and directory"
         admin_url: "https://entra.microsoft.com"

     dependencies:
       - service_id: "SVC-012"
         service_name: "Identity Provider"
         dependency_type: "hard"  # Service fails without this
       - service_id: "SVC-015"
         service_name: "Internet Connectivity"
         dependency_type: "hard"

     backup:
       method: "Native Microsoft retention"
       retention: "14 days deleted items, 30 days soft delete"
       restore_procedure: "KB-0234"

     monitoring:
       availability: "Azure Service Health"
       alerts: "Service degradation triggers P2 incident"

     documentation:
       runbook: "RB-EMAIL-001"
       architecture: "ARCH-EMAIL-2024"
       vendor_support: "Microsoft Premier Support Case Portal"

6. Complete service records for each service following the template. Validate completeness by checking every required field is populated. Have a second person review for clarity and accuracy.

Organise the catalogue hierarchy

1. Assign services to categories. Each service belongs to exactly one category. If a service spans multiple categories, either refine the category definitions or split the service into distinct offerings.

   Review assignments with business stakeholders. IT’s categorisation may not match how users think about services. A “Programme Database” might fit IT’s “Applications” category but users might expect it under “Programme Delivery”.

2. Define service offerings where a single service has variants. Email might have standard and premium offerings with different storage limits. File storage might have offerings for personal files versus team collaboration versus programme data.

   SERVICE: File Storage (SVC-008)
   |
   +-- OFFERING: Personal Storage
   |   - 10 GB per user
   |   - Automatic provisioning
   |   - No approval required
   |
   +-- OFFERING: Team Storage
   |   - 100 GB per team
   |   - Manager approval required
   |   - Provisioning within 2 business days
   |
   +-- OFFERING: Programme Data Storage
       - 500 GB per programme
       - Director approval required
       - Data classification review required
       - Provisioning within 5 business days

3. Establish the navigation structure for the published catalogue. Users should reach any service within 3 clicks from the catalogue home page: home → category → service.

   Create a catalogue map showing the complete hierarchy:

   SERVICE CATALOGUE
   |
   +-- Communication and Collaboration
   |   +-- Email Service
   |   +-- Video Conferencing
   |   +-- Team Messaging
   |   +-- File Storage
   |   +-- Intranet
   |
   +-- Programme Delivery Systems
   |   +-- Programme Database
   |   +-- Mobile Data Collection
   |   +-- Beneficiary Registration
   |   +-- Case Management
   |
   +-- Finance and Administration
   |   +-- Finance System
   |   +-- HR System
   |   +-- Procurement Portal
   |   +-- Expense Claims
   |
   +-- Security and Access
   |   +-- Password Reset
   |   +-- VPN Access
   |   +-- Multi-Factor Authentication
   |   +-- Access Requests
   |
   +-- Devices and Connectivity
       +-- Laptop Provisioning
       +-- Mobile Device
       +-- Internet Access
       +-- Printing

4. Link services to request catalogue items. Each service that users can request should connect to the corresponding request fulfilment workflow. Document the relationship:

   Service	Request Catalogue Item	Fulfilment Process
   Email Service	New mailbox request	Auto-provision on HR feed
   VPN Access	VPN access request	REQ-VPN-001, manager approval
   Programme Database	Database access request	REQ-PROGDB-001, programme director approval
   Laptop Provisioning	New laptop request	REQ-LAPTOP-001, IT approval, procurement

Publish the catalogue

1. Select the publishing platform based on user access patterns and available tools. Options include:

   Service portal with integrated request management: Tools like ServiceNow, Freshservice, or Zammad display the catalogue alongside request submission. Users browse services and submit requests in one interface. This approach provides the best user experience but requires ITSM tool investment.

   Intranet or wiki publication: SharePoint, Confluence, or MediaWiki can host catalogue content accessible to all staff. Simpler to implement but requires separate request submission mechanism. Suitable for organisations without dedicated ITSM tools.

   Static documentation site: Markdown-based documentation (MkDocs, Docusaurus) generated from YAML or Markdown source files. Version-controlled, searchable, but requires technical skills to maintain.

   For organisations with limited IT capacity, start with wiki publication. Migrate to integrated service portal when ITSM tooling is implemented.

2. Design the catalogue layout for usability. Each category page lists services with brief descriptions. Each service page provides complete details.

   Category page structure:

   [Category Name]

   [Category description: 2-3 sentences explaining what services
   belong here and who typically uses them]

   SERVICES IN THIS CATEGORY

   [Service Name]
   [50-word description]
   [Link to full service page]

   [Service Name]
   [50-word description]
   [Link to full service page]

   ...

Service page structure:

   [Service Name]

   [Service description: what it does, who can use it]

   HOW TO GET THIS SERVICE
   [Access method, request link, approval requirements]

   SUPPORT
   [Support hours, contact method, response times]

   SERVICE LEVELS
   [Availability target, key commitments]

   RELATED SERVICES
   [Links to related services]

   TECHNICAL DETAILS (collapsed by default)
   [Technical information for IT staff]

3. Implement search functionality. Users frequently arrive at the catalogue knowing what they need but not how IT names it. Search must handle synonyms: “Zoom” should find “Video Conferencing”, “wifi” should find “Wireless Network Access”.

   Configure search synonyms in your platform:

   video: video conferencing, zoom, teams, meetings
   email: mail, outlook, mailbox, calendar
   laptop: computer, device, hardware
   wifi: wireless, network, internet
   password: credentials, login, authentication

4. Publish initial catalogue and announce availability. Send communication explaining what the catalogue contains, where to find it, and how to provide feedback.

   Sample announcement:

   Subject: New IT Service Catalogue Now Available

   The IT team has published a service catalogue describing all IT
   services available to staff.

   ACCESS THE CATALOGUE: [link]

   The catalogue helps you:
   - Find out what IT services are available
   - Learn how to request access to services
   - Understand service levels and support hours
   - Submit service requests

   We welcome your feedback on the catalogue. If you notice missing
   services, unclear descriptions, or have suggestions for improvement,
   please contact [email] or use the feedback link on any catalogue page.

5. Create feedback mechanism for users to report issues with catalogue content. A simple email address or feedback form connected to a monitored inbox suffices. Review feedback weekly during the first month after launch, then monthly.

Maintain the catalogue

1. Establish the review schedule. Each service record requires review at least annually to verify accuracy. High-change services (those with frequent updates or known upcoming changes) require quarterly review.

   Create review calendar:

   Q1 (Jan-Mar): Communication services, Security services
   Q2 (Apr-Jun): Programme systems, Finance systems
   Q3 (Jul-Sep): Device services, Infrastructure services
   Q4 (Oct-Dec): All services (annual verification)

Assign review tasks to service owners 2 weeks before the review period begins. Provide checklist of what to verify.

2. Define change triggers that require immediate catalogue updates rather than waiting for scheduled review:

   • New service launched: Add catalogue entry before service goes live
   • Service retired: Update status to retired, add retirement notice
   • Service owner change: Update contact information within 5 business days
   • SLA change: Update service level information before change takes effect
   • Access method change: Update request procedures before change takes effect

3. Execute periodic reviews by sending service owners a review checklist:

   SERVICE CATALOGUE REVIEW CHECKLIST

   Service: ________________________________
   Service Owner: ________________________________
   Review Date: ________________________________

   Verify each item and mark complete:

   [ ] Service description accurately reflects current capabilities
   [ ] Eligibility criteria are current
   [ ] Request method and link are correct
   [ ] Support contact information is accurate
   [ ] Service level targets match current commitments
   [ ] Dependencies are correctly documented
   [ ] Technical details reflect current architecture
   [ ] No planned changes require pre-emptive updates

   Changes needed (describe):
   _________________________________________________
   _________________________________________________

   Reviewer signature: ________________ Date: ________

4. Track catalogue health metrics to identify maintenance issues:

   Metric	Target	Measurement
   Review completion rate	100% of scheduled reviews completed	Reviews completed / reviews scheduled
   Review timeliness	90% completed within scheduled period	On-time reviews / total reviews
   User feedback volume	<5 accuracy complaints per month	Feedback tickets tagged “catalogue accuracy”
   Stale service rate	0% of services past review date	Services past due / total services

5. Archive retired services rather than deleting them. Users may reference historical services or need to understand what replaced a retired service. Mark retired services clearly and provide forwarding information:

   [SERVICE RETIRED]

   Legacy Finance System was retired on 2024-09-30.

   This service has been replaced by:
   - Cloud Finance System (for all finance functions)
   - Expense Claims (for expense submission)

   Historical documentation is available in the IT archive.
   Contact IT Service Desk if you need assistance with the
   replacement services.

Verification

After completing catalogue implementation, verify successful deployment:

Catalogue completeness check: Compare the published catalogue against the service inventory. Every active service should have a catalogue entry.

# If using YAML-based catalogue
# Extract service IDs from inventory
cut -d',' -f1 service_inventory.csv | sort > inventory_services.txt

# Extract service IDs from catalogue
grep 'service_id:' catalogue/*.yaml | cut -d'"' -f2 | sort > catalogue_services.txt

# Find services in inventory but not in catalogue
comm -23 inventory_services.txt catalogue_services.txt
# Output should be empty; any listed services are missing from catalogue

Link validation: Test all links in the catalogue, including request submission links, support contact links, and documentation links. Broken links undermine user confidence.

Search functionality: Test search with common user terms including synonyms. Search for “email” should return the email service. Search for “zoom” should return video conferencing.

User acceptance: Ask three to five representative users to complete specific tasks using only the catalogue:

• Find how to request VPN access
• Identify the support contact for the finance system
• Determine the availability target for email
• Submit a request for a new laptop

Record any confusion or failure to complete tasks. Adjust catalogue content or structure to address issues.

Service owner confirmation: Send each service owner their published service entry and request confirmation that information is accurate. Document confirmations for audit purposes.

Troubleshooting

Service definition workflow

The complete workflow from identifying a new service through publication follows this sequence:

+-------------+     +-------------+     +-------------+     +-------------+
|             |     |             |     |             |     |             |
|  Identify   |---->|  Document   |---->|  Review     |---->|  Publish    |
|  Service    |     |  Service    |     |  and        |     |  to         |
|             |     |             |     |  Approve    |     |  Catalogue  |
+------+------+     +------+------+     +------+------+     +------+------+
       |                   |                   |                   |
       v                   v                   v                   v
  - Service need      - Complete         - Service owner     - Add to
    identified          template           reviews             catalogue
  - Owner assigned    - Interview         - Business          - Link to
  - Category            stakeholders       stakeholder         requests
    determined        - Write user         reviews           - Announce
                        description      - IT governance       availability
                      - Document           approves
                        technical
                        details

Figure 3: Service definition workflow from identification to publication

Each stage has defined inputs and outputs:

See also

• Request Fulfilment
• Service Catalogue
• SLA Management
• Cost Allocation
• Service Management Framework