Common ServiceNow Request Fulfilment and Service Catalog Mistakes and How to Avoid Them

This guide sets out common mistakes in ServiceNow request fulfilment and service catalog design. Each mistake is described by its symptom, its root cause and a prevention step. Examples include catalog items with too many required fields, catalog and CMDB records that drift apart, and approval chains that make simple requests wait for weeks.

Mistake: Overly Complex Catalog Items

Symptom: Users submit incomplete requests. Fulfillment teams spend time contacting users asking for missing information. Many requests are rejected. Users become frustrated and stop using the catalog, reverting to email or phone.

Root cause: Catalog items have too many required fields or conditional logic that confuses users. Users do not understand what information is needed or get lost in complex forms. The form was designed for what IT needs to know, not for what users need to fill in.

Prevention: Design catalog items for the user, not for fulfillment. Ask only for information that is essential. Group related fields and label them clearly. Test the form with actual users before publishing. Use conditional logic to hide fields that are not needed based on the user’s answers. Keep forms short; if an item requires more than ten fields, consider breaking it into multiple simpler items.

Mistake: Disconnected Service Catalog and CMDB

Symptom: A user requests a software license and the license is provisioned, but the software is not added to the CMDB. Later, an audit finds inconsistency between what the CMDB shows and what is actually installed. The compliance team becomes concerned about software license compliance.

Root cause: The request workflow and the asset creation workflow are separate. When a license is provisioned, the request is closed but no one created the corresponding asset record. The two systems are out of sync.

Prevention: Design the fulfillment workflow to create CMDB records automatically. When a license is provisioned, a workflow should create a software record in the CMDB linked to the user and the license record. When hardware is delivered, the receiving workflow should update the CMDB. Integrate the service catalog and CMDB so they stay synchronized. Periodically audit to ensure they match.

Mistake: Too Many Approval Layers

Symptom: A simple request takes weeks to get approved. Users wait days or weeks for responses from approvers. Approvers are overwhelmed with approval notifications and miss some. High-value requests are approved while low-value requests languish in queues.

Root cause: The approval workflow requires multiple levels of approval when a few would suffice. Three or four approval steps were added over time as different departments wanted visibility or control. No one removed them when they were no longer needed.

Prevention: Limit approval layers to the minimum necessary. Most requests need one approval: a manager, a team lead, or a budget owner. Only complex requests or high-cost requests need multiple approvals. Use conditional approval: a low-cost request might need only a manager’s approval, while a high-cost request needs manager and finance approval. Regularly review approval workflows and remove layers that are no longer necessary.

Mistake: Inconsistent Request Status and Communication

Symptom: A user submits a request and never hears back. They do not know whether it was approved, whether it is being fulfilled, or whether it is stuck somewhere. They submit follow-up requests or email the help desk asking about status.

Root cause: The request fulfillment workflow does not keep users informed. Status changes are not communicated automatically. Users have to log in and check status manually, which most do not do.

Prevention: Implement automatic notifications at key points: request received, request approved, fulfillment started, fulfillment complete, request closed. Include a link to the request so users can check status anytime. Make notifications clear and non-technical. If a request is delayed, send a proactive update explaining why and when the user can expect completion. This communication prevents follow-up requests and reduces help desk volume.

Mistake: Rigid Service Catalog That Does Not Adapt

Symptom: New types of requests come in that the catalog does not cover. Users call the help desk or email requesting things not in the catalog. IT staff handle these ad hoc, and there is no record of them. The catalog becomes increasingly out of date relative to actual demand.

Root cause: The catalog was designed once and never updated. As the organization’s needs change, the catalog does not evolve. New services are added, but old catalog items that are rarely used are not retired.

Prevention: Review the service catalog quarterly. Look at requests that came in outside the catalog—these are candidates for new catalog items. Look at catalog items with very few requests—these might be candidates for retirement or consolidation. Update descriptions based on feedback from users and fulfillment teams. Announce changes to users so they know what is available.

Mistake: No Measurement or Feedback

Symptom: The service catalog has been live for two years and no one knows whether it is working well or poorly. There are complaints about slow fulfillment, but no data on how long requests take. There is no feedback from users about catalog quality.

Root cause: No one measured the service catalog against goals. No one collects user feedback. Changes are made based on complaints, not data.

Prevention: Define success metrics: how long should a request take to fulfill, what percentage should be fulfilled on first try without follow-up, what satisfaction level should users report. Track these metrics continuously. Send satisfaction surveys after request closure, asking whether the user got what they needed and how satisfied they are. Use this data to drive improvements. When the catalog is working well, celebrate it. When it is not, investigate and fix the root cause.

Reading a failing catalog from its own records

A catalog that is already live keeps evidence of its own failures, and that evidence is often more reliable than the complaints that reach the service desk. Before changing any item, pull the records that show what happened to it. Requested Item records show where requests were cancelled, reopened or closed as rejected. Catalog task records show which fulfillment group held each piece of work, how long it sat unassigned and whether it was reassigned. Approval records show who decided and whether the decision changed anything. Reading these together tells you where the item is failing, which is a different question from why users are unhappy.

A triage sequence for a live catalog

Work on one item at a time. Trying to fix several at once makes it impossible to tell which change helped.

1. Choose the single item with the most reopened or cancelled requests in the period under review, and set the others aside.
2. Read ten recent requests from start to finish, including ones that closed without trouble, so you see the path requesters actually took rather than the path the design assumed.
3. For each cancelled request, note the point at which it stopped. That point is usually a field the requester did not understand, or a choice they could not make without asking someone.
4. Check whether any catalog task sat unassigned for longer than its group expects, and confirm that the group named on the task still exists and still has members.
5. Compare the approvals that were rejected with the ones approved unchanged. A chain where every request passes untouched is a control in name only.
6. Change one thing, then watch the same measures for the same item before you touch another.

Matching symptoms to first checks

The table below links what you can see in the records to the cause often behind it. Each first check is something you can finish in a short sitting, and each one points at a single component of the item rather than the catalog as a whole. The parts that make up a catalog item are a useful map when you are deciding which component to inspect.

When the catalog is not the problem

A catalog can look broken when the work behind it has changed and the item has not. Consider a team whose access requests stall for weeks. The item is well built, but the approver list still names two people who moved to other roles, so every request waits for someone who never sees it. Fixing the form would achieve nothing. The first check in that situation is usually the people and groups the item depends on, and the item itself is the last thing to examine. The design tasks that sit behind an item are the place to look for the design side.

How often should I pull the failure records for a live item?

Often enough to notice a change within a short time of making it. Many teams review the records after each change they make to an item, and then at a regular cadence once the item is stable. The frequency matters less than the habit of comparing before and after on the same measures.

Should a reopened request count as a new request in reports?

Report it as a reopened request linked to the original, rather than as a fresh submission. Counting it twice inflates demand for the item and hides the fact that the first fulfillment did not stick. Keep the link so the reason for the reopening can be read later.

Is it better to fix the form or to retrain requesters?

Fix the form whenever a question is consistently misunderstood, because the same confusion may recur with every new requester. Retraining is appropriate for a question that is clear but that people routinely skip, usually because it looks optional when it is not.

How should cancellations made by the requester be treated?

Separate them from cancellations made by fulfillment staff. A requester who cancels within minutes of submitting has often realized they picked the wrong item, which is a signal about item titles. A cancellation made after work has started points at a different problem, often a delay that frustrated the requester.

Next step

A live item that keeps producing reopened requests is best examined through its records before anyone edits the form. The request fulfillment KPIs show which measures confirm that a fix worked.