ServiceNow Service Catalog Optimisation
Service Catalog Optimisation: Request Experience Improvement
Service Catalog optimisation improves how employees request IT services and how requests flow to fulfillment teams. Service Catalog is typically the first experience employees have with ServiceNow: they browse available services and submit requests. Poor catalog experience frustrates employees and creates helpdesk volume. An optimisation engagement addresses issues like: service items aren’t discoverable, request forms are burdensome (too many required fields), fulfillment workflow doesn’t match service delivery, request status updates are missing. The engagement works with service delivery teams and end users to improve catalog organization, streamline request forms, and optimize fulfillment.
Service Item Discovery and Categorization
Employees need to find services they can request. Poor categorization makes discovery hard. We audit catalog: what service items exist, how are they organized, can employees find items they need. Common issues: categories are too technical (IT names) rather than business-focused (employee needs), categories have overlapping items (hard to know which item to click), no search or search doesn’t work well. Reorganization involves: renaming categories to business language (instead of ‘Infrastructure Services’, use ‘Compute, Storage, and Networking’), consolidating overlapping items, adding descriptions helping employees find right item, improving search. Add related items: if employee requests laptop, suggest related requests they might need (software, peripherals, setup support). Better discovery encourages self-service request submissions: employees find services they didn’t know existed.
Request Form Optimization and Data Collection
Request forms must collect necessary information without being burdensome. Common issues: forms ask for fields employees don’t understand (cost center codes, business unit designations), required fields don’t apply to all requests (field appears for everyone but only applies to some), forms are long (employees abandon incomplete requests). Optimization involves: making only truly required fields required, showing fields conditionally (only show relevant questions), grouping related questions logically, using dropdowns/checklists instead of free-form text, providing examples and help text. Test with potential users: ask them to complete request forms, time how long it takes, note where they get confused. Form testing often reveals simple improvements: renaming fields for clarity, reordering questions logically, marking optional fields clearly. Optimized forms result in fewer abandoned requests and higher completion rates.
Fulfillment Workflow Alignment and Task Assignment
After request is submitted, it must flow through fulfillment process. Service Catalog should route requests to correct team and present information team needs to fulfill. Common issues: requests route to wrong team (employee selected wrong category), fulfillment team doesn’t receive request (notification doesn’t reach right people), requests lack context (team doesn’t know why employee needs service). Optimize routing: improve service item mapping to fulfillment queues, configure routing rules based on request details (high-cost requests route to approver, urgent requests prioritize), add escalation for complex requests. Also optimize fulfillment information: include employee information automatically (department, location, manager), show approval status to requestor, provide fulfillment team context (why employee needs service, any constraints, related services already used). Better workflow alignment ensures requests reach the right team faster with complete information.
Request Status Communication and Transparency
Employees want to know status of submitted requests. Service Catalog should provide visibility. Common issues: status doesn’t update automatically (employee doesn’t know progress), fulfillment team doesn’t provide estimated completion (employee doesn’t know when to expect service), no way to follow up on stalled requests. Implement: automated status updates as request moves through workflow, estimated completion dates provided to requestor, escalation if fulfillment is overdue, ability to check status without submitting new request. Also enable communication: allow requestor to add comments, notify team when additional information is needed, provide feedback after fulfillment complete. Transparency improves satisfaction: employees feel less uncertain about their requests.
Service Item Coverage and Fulfillment Options
Service Catalog should reflect services actually available. Common issues: catalog has items nobody fulfills (creates frustration when employee requests service then hears it can’t be delivered), catalog is missing common requests (employees contact helpdesk instead of using catalog), item descriptions are inaccurate. We audit: what items are fulfillable, what items should be decommissioned (nobody uses them, deprecating them), what common requests are missing. We expand catalog: adding missing items for common requests, retiring unfulfillable items, clarifying item descriptions and constraints. We also establish service levels: which requests have SLA (must complete within the agreed service level), which are best-effort, which have cost implications. Clear expectations prevent disappointment: employees know whether service is free or charged, how quickly it will be fulfilled.
Approval Workflows and Delegation Authority
Many requests require approval: expensive requests, policy violations, capacity constraints. We optimize approval workflow: identifying which requests actually need approval (avoid approval for low-risk requests), routing to appropriate approvers (manager approves leave, CFO approves expensive requests), allowing approvers to delegate (if manager is out, can request go to coverage manager), escalating if approval is overdue. Common issues: approvals are slow (managers don’t check requests regularly), delegation doesn’t work (request doesn’t reach coverage manager), approvers aren’t delegating (urgent requests pile up while approver is out). We improve workflow: sending reminders for pending approvals, enforcing approval SLAs (escalate if overdue), testing delegation. Improved approval workflow reduces request hold-up: requests don’t sit waiting for approval.
Mobile Access and Request Submission
Employees work from anywhere. Service Catalog should be mobile-accessible. Assess: is catalog available on mobile, can employees submit requests on mobile devices, are mobile forms usable (not too many fields, not too complex). Common issues: mobile version of catalog doesn’t exist or doesn’t work well, forms are unusable on phone. Optimize: implement mobile-friendly catalog, simplify forms for mobile, test on real devices. Mobile optimization allows employees to submit requests when convenient from phone rather than waiting for desk access.
Fulfillment Team Efficiency and Knowledge Integration
Service Catalog serves fulfillment teams too: they use catalog to understand what they’re responsible for delivering. We optimize: providing team with knowledge articles relevant to each service item (how-to for installation, troubleshooting guide), suggesting template responses, tracking fulfillment metrics per team. We also enable efficiency: allowing team to see all open requests, identifying bottlenecks (which requestor is calling with questions, which items always need follow-up), trending data (new requests per day, fulfillment time by item). Team efficiency reduces fulfillment time and improves quality.
Audit forms by the completion cost of each field
Form optimization often starts with opinions about which fields are unnecessary. A more reliable starting point is to measure what each field costs. A field that requesters skip, leave with a default value, or answer incorrectly is costing completion rate, and the fix is different for each. The audit below classifies every field on the busiest forms before any change is made.
| Field behavior observed | Likely meaning | Usual change |
|---|---|---|
| Left at the default value almost every time | The field does not reflect a real choice | Remove it, or set the value by rule |
| Answered with the same few values | The field should be a controlled choice | Replace free text with a short list |
| Frequently corrected after submission | The wording or the help text is unclear | Rewrite the label and add an example |
| Required, but only relevant to some requests | The field is shown to everyone when it applies to few | Show it only when the earlier answer calls for it |
Consolidating overlapping items without losing history
Overlapping items split demand, so the same need appears under two names and reporting undercounts both. Merging them is worth the effort, but keep the retired item’s historical requests linked to the surviving one so trends stay readable. Keep the old item visible for a short notice period, with a message pointing to the replacement, rather than removing it on the day the merge is announced.
Checking the fulfillment team gets what it needs
Optimization is not finished when the requester completes the form. Ask the fulfillment group which of the answers it used in the last ten requests, and which it had to chase. For the requester side of status updates, see the request status transparency article. Fields that nobody uses are candidates for removal, and questions that always generate follow-up belong in the form itself. Making this check part of each optimization cycle keeps the form honest about its purpose.
Questions to answer before changing a form
- Which fulfillment step reads this field, and what would that step do without it?
- Would a requester know the answer without looking anything up?
- Can the value be taken from the user record or from a previous request?
- Is the field required for every request this item handles, or only some?
- Who will check the change once it is live, and how will they know it worked?
A form change that cannot answer the first question is usually a removal, and one that cannot answer the second is usually a rewrite of the label.
Questions catalog teams ask about form changes
How do we test a form change without disrupting requesters?
Test it in a non-production copy with requester accounts, using the approach in the implementation service, and time how long the form takes to complete before and after the change. Release the change to one item first, and compare the completion rate for a fair period before rolling it out to others.
What if a field is needed for reporting but not for fulfillment?
Move it out of the requester form and populate it from the record or from the fulfillment step. Reporting needs can be met without asking every requester to answer a question that only the analysts use.
Should every change be announced to requesters?
Announce changes that alter what requesters must enter or how they will be notified. Silent changes to labels and help text do not need an announcement, although the knowledge articles that describe them should be checked.
Next step
Choose the three busiest forms and run the field audit on them first.
Frequently asked questions
How many service items should we have in the catalog?
Quality over quantity matters more than number. Start with services your organization actually delivers and employees actually request. Too many items confuse users; too few misses request opportunities. Most effective catalogs keep a focused set of service items per service offering. A long list of items in a single category indicates over-complexity: consider reorganizing into subcategories.
What should we do about requests we can't automatically fulfill?
Service Catalog can capture complex requests that need human approval or evaluation. Provide clear communication: request is in queue, what information team needs from you, estimated completion timeframe. Set expectations that complex requests take longer. Make it easy for fulfillment team to reach out for clarification rather than silently investigating.
How do we know if catalog optimisation is actually improving things?
Track metrics before and after optimization: self-service request volume (is it increasing), request completion rate (are fewer requests abandoned), fulfillment time (is it decreasing), employee satisfaction (survey requestors). Compare helpdesk volume reduction: if catalog improved, helpdesk should see fewer requests for services available self-service. Measure results weeks after optimization launch to allow time for adoption and stabilization.
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