ServiceNow Request Fulfilment and Service Catalog KPIs and Metrics That Matter

Catalog performance measures cover request volume and trend, time to fulfil, approval rate, catalog adoption and user satisfaction. Each section below defines the measure, names the ServiceNow table and calculation, and the later sections cover misuse, review cadence, a dashboard checklist, how to write a definition card before a metric reaches a dashboard, and how to work through a sudden movement in a number.

Request Volume and Trend

This is the total number of service requests submitted in a period. Track by service, by catalog category, and by requester department. Volume reveals demand and usage patterns. A sudden spike in requests for a particular service may indicate awareness of that service increased, or it may indicate a problem that workaround requests now must be formalised (for example, many requests for access because the normal process is broken).

Data source: Request table in ServiceNow. Calculate: count of records created in the date range, grouped by service or category.

Time to Fulfil (TTF)

Average time from request submission to completion. This should be tracked separately for different request types because a password reset takes minutes, while a hardware order takes weeks. TTF helps assess whether your fulfillment process is efficient. Long TTF may indicate bottlenecks: missing approval steps, staffing constraints, or waiting on third parties.

Data source: Request table, closed_at minus created_date. Typical calculation: sum of (closed_at – created_date) for all closed requests, divided by number of closed requests, in a time range. Do not include open requests; they skew the calculation.

Request Approval Rate

The share of requests approved, out of all requests decided, reveals whether the approval process is functioning as intended. A very high approval rate may indicate that approvals are not being enforced or that requests are not being truly evaluated. A very low approval rate may indicate that the approvals process is too strict or that the catalog is not offering services that users actually want. The target depends on the type of requests and the risk profile of the organization.

Data source: Request table, filtered by approval status. Calculate: count of requests with approved status, divided by total requests.

Catalog Adoption and Utilisation

The ratio of IT requests that go through the service catalog vs. being submitted through other channels (email, phone, walk-in). Higher adoption means more requests are formalised and tracked. Track by service and by department to identify gaps: if a particular department never uses the catalog, their requests may be getting missed or handled ad-hoc.

Data source: Request table, plus manual count of requests handled outside the system. Calculate: count of requests in the catalog, divided by total requests from all channels.

User Satisfaction (CSAT)

The ratio of satisfied customer ratings to total requests completed. Satisfaction ratings are typically collected via survey after request closure. Low CSAT may indicate fulfillment quality issues, poor communication during fulfillment, or unmet expectations about what the service would deliver.

Data source: Survey response field on closed requests. Calculate: count of satisfied ratings, divided by count of surveys sent.

Common Misuse and Pitfalls

A common mistake is measuring request closure time but not accounting for requests that were closed without being fulfilled (e.g., request cancelled by the requester or rejected and closed). This skews TTF downward. Always filter to include only successfully completed requests when measuring fulfillment time.

Another pitfall: not separating requests by type when reporting trends. A single average TTF across all request types (password resets, hardware provisioning, access requests) is less useful than separate averages for each type, because they have different processes and resource requirements.

Review Cadence

Review request metrics weekly for operational troubleshooting (is there a current spike in requests, a fulfillment bottleneck?), monthly for trend analysis (is the service becoming more or less popular?), and quarterly for capacity and resource planning. Share metrics with service owners and stakeholders to align on priorities and identify improvement opportunities.

Metrics Dashboard Checklist

• Total requests submitted this period and trend vs. last period
• Time to fulfil by request type (separate password resets from hardware orders)
• Approval rate and distribution of approvals vs. rejections
• Service catalog adoption percentage
• User satisfaction rating and trend
• Most requested services and their fulfillment performance
• Fulfillment backlog (number of open requests and age)

Calculating and Reporting KPIs Accurately

Accuracy in KPI calculation is critical. Requests that are still open should not be included in fulfillment time calculations, as they skew averages downward. Cancelled or rejected requests should be tracked separately, as they are not true fulfillments. When reporting KPIs to stakeholders, always specify which requests are included in the calculation (closed only, past month only, specific service only) so everyone interprets the metric the same way.

Store historical KPI data so trends can be tracked over quarters and years. A single month’s metrics may be unrepresentative; trends over time show whether the service is improving or degrading.

Writing a definition card before a metric reaches a dashboard

Most arguments about catalog performance are arguments about definitions, not about the service. Two people looking at the same average completion time can be measuring different things, one counting cancelled requests and the other not, and each will reach a different conclusion. A short definition card, written before the metric is published, prevents this. It is worth the few minutes it takes for each measure on the dashboard.

Working through a sudden movement in a number

When a figure moves sharply, resist the urge to explain it with the service. Most sudden movements are caused by the measurement, and the sequence below finds the cause before anyone changes a process.

1. Run the same query again for the same period to rule out a reporting fault or a filter that was changed by accident.
2. Check whether the population changed, such as new items added, retired items removed or a department onboarded during the period.
3. Check whether the definition changed, including which date field the query uses.
4. Split the figure by item and by fulfillment group. One part of the population often explains the whole movement.
5. Only after those steps, ask whether the service itself has changed.

Consider a catalog where average completion time falls sharply in a single month. The cause turns out to be a request type that was cancelled in bulk and now closes almost instantly, so it pulls the average down. Nothing about fulfillment improved, and the right response is a note on the dashboard and an exclusion rule, not a celebration.

Choosing which measure should trigger which action

A measure is only useful if someone knows what they would do when it moves. Pair each question you want answered with a single measure and a named action, so that the dashboard leads to decisions rather than discussion.

When to drop a metric

• When it has not informed a decision in the last two reviews. A measure that never drives a decision is decoration.
• When it measures effort rather than outcome, such as the number of catalog page views, which can rise for the wrong reasons.
• When the team being measured can improve the number without improving the service. Completion time is often vulnerable to this, because closing a task early is easier than finishing it properly.
• When the data source has changed and the historical comparison is no longer valid. Keep the old figure, label the break, and start a new series.

Should a dashboard show a target beside each measure?

Only where the target has been set by the owner of the service and can be defended. A target set by default, from another organization’s figures or from a rule of thumb, invites people to optimize the number rather than the outcome. A trend against the team’s own baseline is often more useful while the reporting is still new.

How should requests reassigned between fulfillment groups be counted?

Count the request once, against the overall time, and show the time spent in each group as a separate measure. That way a group that receives work late is visible without the request being counted twice in volume figures.

Is the survey response rate a measure in its own right?

It is worth watching, because a low response rate means the satisfaction figure describes a small and possibly unrepresentative group. Report the response rate alongside the score, so that readers can judge how much weight the score deserves.

Who signs off a revised definition?

The owner named on the definition card should approve, after consulting the people who use the figure in decisions. A change to a definition should always produce a note on the dashboard and a new series where the change affects the comparison.

Next step

Write the definition cards before touching any figure on the dashboard, since most disputes start there. The incident management measures follow similar logic for a neighboring process, and the audit trail evidence guide covers the explanatory evidence that makes a change record defensible.