Service Catalogs and Request Fulfillment
A service catalog helps someone request a supported outcome and understand what will happen next. Request fulfillment turns that choice into an owned workflow with eligibility checks, any required approvals, delivery, and verification. The catalog is useful when the request can actually reach a responsible team.
Begin with a few frequent, bounded requests such as an approved workspace or a standard software installation. Describe the outcome in the requester’s language, then work backward to the information and controls needed to deliver it. A searchable list of tools is inventory; a usable request path needs an operating promise.
TL;DR
- Organize entries around supported outcomes and understandable request language.
- State eligibility, prerequisites, owner, expected delivery conditions, and exceptions.
- Ask only for information needed to route, authorize, or fulfill the request.
- Keep approval, provisioning, verification, and closure distinct.
- Measure delivery and rework across the whole request path.
Quick Example
This complete fictional workflow keeps eligibility, required approval, provisioning, and delivery verification separate. The fields represent trusted test inputs; a real requester cannot grant approval by editing a boolean or status string.
All five transition assertions passed locally. No ticket, account, license, service, approval, or access grant was created. The model illustrates ordering only; real workflows need authorized transitions, audit evidence, exception handling, and integration recovery.
Core Concepts
Service and request type
A service can support several request types. For example, a managed collaboration service might support initial access, a permission change, and removal. Those operations can have different eligibility and approval requirements even when they share an owner.
Request form and workflow
Atlassian documents request types as a way to categorize incoming requests and collect relevant fields. Its guidance recommends requester-friendly language and cautions against excessive granularity. This is one implementation reference, not a requirement to use that product. Request types
Delivery expectation
Distinguish the advertised expectation from its conditions: business hours, complete information, approval waiting, availability, and nonstandard work can affect the path. State the organization’s actual commitment rather than inventing a service-level target for the catalog.
Write a catalog entry that answers the next question
These fields are a proposed starting structure, not a mandatory standard. Add information when it changes the requester’s decision or the team’s ability to deliver. Remove fields that nobody uses, particularly those that collect unnecessary personal or sensitive details.
Describe inclusions and exclusions concretely. If the standard request creates a workspace but does not migrate historical content, say so. Otherwise the requester and delivery team may both believe the request is complete while expecting different results.
Use examples to distinguish similar entries. A user who needs a broken existing account repaired should not have to request a new account to reach support. Provide a clear incident path alongside standard fulfillment where the distinction matters.
Keep the visible description connected to the actual workflow. An entry that promises an approved outcome while routing to a generic inbox creates uncertainty rather than removing it. Confirm that the owner accepts the request type before advertising it.
Design the request path around authority and recovery
Validate the request’s basic shape, determine eligibility, and resolve the approving authority from trusted records. Do not treat the requester’s chosen approver as sufficient proof that the person may authorize the action. Changes to consequential access need the organization’s actual policy and identity controls.
Make approval states explicit: pending, approved, rejected, expired, or returned for information may have different next steps. Record who decided, what scope they approved, and whether the decision remains valid when fulfillment starts. A material request change can require a new decision.
Separate approval from execution. An approved request can still fail to provision, and a provisioning system can complete while the ticket update fails. Use durable operation references and reconciliation where integrations can repeat or time out. Closing a request because an API returned an acceptance response can hide unfinished work.
Verify the intended outcome through an appropriate method. For access, that may include an allowed operation and a relevant denied operation. For an installation, it may include the supported version and a basic functional check. Choose evidence proportionate to the request without exposing credentials or unnecessary content in the ticket.
Plan cancellation and withdrawal. A requester may cancel before work begins, while an operation already in progress may require a separate reversal workflow. Explain the actual state rather than labeling every cancellation immediately complete.
Maintain the catalog as an operating interface
Give each entry a content owner and an operational owner; they may be the same team. Review the entry when the service, eligibility, approval policy, delivery integration, or support hours change. A stale catalog can create repeated avoidable contacts.
Measure where requests wait. Distinguish time awaiting requester information, approval, fulfillment capacity, and external dependencies. End-to-end delivery matters to the requester, while the breakdown helps the team find the constraint. Report both honestly rather than making the total disappear through paused clocks.
Review misrouted requests, abandoned forms, rejected requests, repeated clarifications, and reopened deliveries. These observations can reveal a missing entry, unclear wording, excessive form fields, or a failed verification step. A high closure count alone does not establish useful service.
Retire unsupported entries deliberately. Identify an alternative path, outstanding requests, retained records, and the owner responsible for explaining the change. Removing the catalog link does not cancel already accepted work.
Pilot the catalog with representative requesters and fulfillment staff. Ask them to choose the right entry, supply the needed information, and explain the expected next step. If their interpretation differs from the operating team’s, revise the entry before expanding it.
Best Practices
Start with a bounded service
Choose a request whose outcome and authority are already understood. Demonstrate the path from selection through verified delivery before adding many variants.
Keep exceptions visible
Route nonstandard needs to an owned review path with an honest expectation. Do not force them into a standard entry that cannot satisfy them.
Review the requester’s outcome
Check useful completion and rework alongside queue throughput. Use real request evidence to improve wording and workflow.
Common Mistakes
Bad: A catalog is the list of products the team uses.
Correct: Describe supported outcomes, request paths, owners, and delivery conditions.
Bad: Approved means fulfilled.
Correct: Track execution and verification separately, including partial failures and reconciliation.
Bad: Every request needs the same approval.
Correct: Apply the actual risk and authority policy, and verify who may approve the specific scope.
FAQ
Should every service have a request form?
Only where a supported request path makes sense. Some services need informational guidance, incident support, or an exception review rather than a standard fulfillment form.
How detailed should the catalog be?
Detailed enough to choose the correct outcome and supply necessary information. Too many near-identical entries can make that choice harder.
What is a good first measure?
Useful completion time with a breakdown of waiting and rework. Define the measurement boundary and distinguish commitments from observations.
Related Topics
- Service Desk Operations — Request intake, queues, and user support.
- IT Asset Management — Inventory, ownership, and lifecycle records.
- Authorization Models: RBAC, ABAC, and ReBAC — Authority and verification for access-related requests.