ServiceNow Service Catalog Managed Support
What a Managed Support Engagement for Service Catalog Covers
A managed support engagement for ServiceNow Service Catalog with Oblytech provides ongoing administration of your service offerings and request workflows. We monitor the catalogue to ensure it reflects current services and that request items are working correctly. We update workflows as approval structures change or new services are added. We provide a contact for users who have questions about available services or problems submitting requests. We perform regular reviews with your business to identify gaps in the catalogue or services that should be added or retired.
Service Catalog is where users interact with IT services. It is critical that the catalogue is complete, accurate and easy to use. Managed support ensures these characteristics are maintained as the business evolves.
Typical Starting Problems and Catalog Quality Issues
Service catalogues often start well but degrade over time. New services are added without retiring obsolete ones, so the catalogue becomes cluttered. Request items break when underlying systems change: an email provisioning item fails when the email system is upgraded. Approvals are assigned to people who left the organisation, so requests hang pending approval forever. Descriptions are written by technical teams and full of jargon that business users do not understand. Users struggle to find what they need or submit requests to the wrong category.
When a request item breaks, it is quickly apparent because users cannot use the catalogue. Users call the service desk or email support when they cannot find what they need or when submitting a request fails. These are escalations you should track and fix immediately. Service Catalog availability is important for self-service success.
Another problem is self-service penetration. A well-designed catalogue reduces service desk volume by allowing users to self-serve. A poorly designed catalogue frustrates users and drives them to call the help desk instead. Many organisations find that they built a catalogue but users do not use it, defeating the purpose.
Catalog Administration and Governance
We manage the day-to-day administration: adding new request items when services are added, retiring items for obsolete services, fixing broken items when systems change. We maintain approval assignments so requests flow to the right people. We track catalogue usage: which items are popular, which are never used and which are broken. Usage data guides improvement priorities.
Governance ensures catalogue changes go through process. New services requested are reviewed for feasibility and added to the catalogue only after approval. Business stakeholders see what is in the catalogue and have opportunity to request additions or modifications. This prevents the catalogue from becoming a dumping ground for every ad-hoc request that might be made.
Request Workflow and Approval Process Management
Each request item has a workflow: collect information, route for approval, provision, and confirmation. We monitor these workflows and fix issues. If approvals are bottlenecks, we streamline approval criteria or enable batch approval. If approval assignments are stale, we update them. If workflows are too long and discourage requests, we simplify them while preserving necessary controls.
Approval assignments are kept current. When someone leaves the organisation, we reassign their approvals. When teams change, we update approval routing. We ensure that all requests get approval attention: some requests should have automatic approval for low-risk services, others require review.
User Experience and Catalog Discoverability
We monitor how users interact with the catalogue. Are they finding what they need? Do they understand how to submit requests? We gather feedback and make improvements. Common improvements include reorganising categories so services are grouped intuitively, adding better descriptions that use business language not IT jargon, and creating service bundles for common multi-step requests.
We also track self-service success. Are more requests coming through the catalogue than the help desk phone? If not, there is opportunity to improve. Popular items tell us what users value. Unpopular items might need better promotion or might represent services users do not actually want.
Integration with Fulfillment and Backend Systems
Service catalogue requests trigger fulfillment workflows that provision services. We monitor these integrations and fix problems. If a password reset request is submitted but not automatically executed, we investigate: is the backend system available, are credentials correct, is the workflow broken. We work with infrastructure teams to keep integrations functional as systems are updated or changed.
As services evolve, we update request items to match. If a service used to be offered one way but now has new capabilities, we update the item to reflect current offerings. If system changes mean the old fulfillment process no longer works, we develop a new process.
Metrics and Continuous Improvement
We track catalogue metrics: request volume, approval turnaround, fulfillment success rate and user satisfaction. These metrics show whether the catalogue is healthy and where improvements are needed. Rising request volume suggests the catalogue is working. Approval delays suggest bottlenecks. Low fulfilment rates suggest the backend systems are not working. These metrics guide improvement efforts.
Separate catalog changes by how much risk they carry
A managed catalog receives a steady stream of change requests, and treating them all the same is the fastest way to slow the service down. A new laptop model and a change to who approves access to a financial system are both catalog changes, but they carry very different risks. Sorting requests into risk classes before they are worked is what makes a managed arrangement sustainable. The table sets out a workable split.
| Change class | Examples | Who decides | Evidence to keep |
|---|---|---|---|
| Wording and content | Clarifying a description, fixing a typo in a help text | Catalog administrator | Before and after text in the change log |
| Form adjustment | Making a field optional, adding a choice to a list | Item owner | Note of which fulfillment step reads the field |
| Routing or approval | Changing the group or approver for an item | Item owner and affected approver | Named approver and effective date |
| New or retired item | Adding an item for a new service, retiring one that is no longer offered | Service owner, after feasibility review | Feasibility note and redirect plan for retired items |
Keeping the classes visible also helps the business. A requester asking for a new item should know that it goes through feasibility review, while a wording fix can take the lighter route.
A weekly routine that keeps the catalog accurate
The managed team’s week is mostly about catching small failures before they become complaints. Owners for each of these checks should be recorded in the roles and responsibilities matrix. Once it settles, this routine stays short, and every step leaves something a reviewer can check afterwards.
- Check the list of items that received requests with errors in the period, and fix any whose failure has a clear cause.
- Review approvals waiting beyond the agreed window, and confirm each approver is still active and still the right person.
- Read the requester feedback received in the period and sort it into wording, form and routing issues.
- Confirm that every change request from the previous week has been applied, tested and recorded.
- Check that knowledge articles linked from items still exist and still describe the current process.
The approval check deserves the most attention. When a manager leaves, their approvals rarely fail with an error. The requests simply wait, and the requester assumes the service is broken.
What to leave out of the managed scope
Managed catalog support should not become a general content service for every department. Writing policy text, deciding which services a business unit may request, and designing the fulfillment process for a new team are decisions for the people who own those things. Agree that boundary in writing, so the managed team can say no to a request without it looking like poor service.
Reporting that a catalog owner can act on
Useful reports answer a question an owner can do something about. A service catalog health check is a structured way to decide which measures matter for a given catalog. Which items are requested most, and does each one still have a current owner? Which approvals are slowest, and which approver is the cause? Which requests are reopened after fulfillment, and what did the requester say the problem was? A report of total requests tells the owner little, while a report of reopened requests by item points straight at the work.
Questions catalog owners ask about managed support
How quickly should a wording change be made?
Wording and content fixes are low risk and should move quickly once the issue is raised. The managed team should be able to make them without a full change cycle, as long as the before and after text is recorded.
What happens when an item owner does not respond?
Escalate to the service owner after a set period, and keep the item unchanged until a decision is made. Do not let the managed team decide for the owner, because the owner is the person who will answer for the outcome.
Should retired items be deleted?
Usually retire them rather than delete them. Retirement hides the item from browsing, redirects any links, and keeps historical requests reportable. Deleting an item can break reporting and leave dead links in knowledge articles.
How is a request for a new item assessed?
Check whether a fulfillment group exists, whether the process is stable enough to automate or standardize, and whether an existing item could cover the need with a variable. Many requests for new items can be met that way without creating a new item.
Who should receive the monthly catalog report?
The service owner and each item owner, each seeing their own items in detail and the overall summary. Sending the full report to everyone encourages people to ignore it.
Next step
Start by sorting last month’s catalog changes into the four classes above.
Related guides: ServiceNow Request Rejections: Find and Fix the Cause.
Frequently asked questions
How do we encourage users to use the service catalogue instead of calling the help desk?
Make the catalogue easier than calling. Self-service for simple requests should be faster than explaining the request to someone over the phone. Provide clear descriptions and guides. Advertise new catalogue items. Make popular items easy to find. Track metrics that show self-service is working: as catalogue usage rises and help desk volume from those requests falls, you know it is working. Celebrate wins with users and leadership to build momentum.
Should we have different catalogues for different user groups?
Yes. Users see only services they are entitled to request. Executives might see procurement services. Developers might see development environment provisioning. End users might see standard office requests. Limiting the catalogue to relevant items makes discovery easier and prevents users from submitting requests they are not authorised for.
How do we handle requests that require custom approval workflows?
Most requests can use standard approval routing, but some require custom logic. A high-cost procurement request might go to leadership. A security-sensitive request might require compliance review. SPM and Service Catalogue support conditional approval routing based on request properties. Build workflows to be simple and standard for most requests, with exceptions only where truly needed.
Related guides
Related Oblytech services
Where this topic turns into delivery work, these are the Oblytech services that cover it.
Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.
Contact us