Designing KPIs for ServiceNow Reporting and Dashboards

KPIs for ServiceNow reporting are the few measures that show whether service delivery is working. The core set covers resolution time, customer satisfaction, incident volume and trends, SLA compliance, first contact resolution, service availability, cost and efficiency. Read each metric by priority and category and watch its trend rather than a single figure.

Resolution Time and Mean Time to Resolution

How long does it take to resolve an incident or change request? This metric directly impacts customer satisfaction and operational efficiency. Track: mean time to resolution (MTTR), median resolution time, and percentiles (95th percentile: how long do the slowest incidents take?). Trends matter: is resolution time improving or degrading?

Also segment by priority and category: high-priority incidents should have a much shorter resolution time than routine requests. If resolution time is increasing, investigate why: are incidents more complex, is staffing insufficient, or are approvals slow? Use the metric to identify bottlenecks.

Customer Satisfaction and Net Promoter Score

After an incident is resolved or a request fulfilled, ask the customer: how satisfied are you? Track satisfaction scores and Net Promoter Score (would you recommend our support to others?). Satisfaction correlates with resolution time, but also with communication, technical competence, and politeness. Organisations with good metrics are fast and professional.

Report satisfaction trends quarterly. If satisfaction drops, investigate: did resolution time increase? Did staffing change? Did communication improve or worsen? Use satisfaction as a leading indicator: customers who are unhappy with one ticket might escalate, complain publicly, or churn. Address satisfaction issues early.

Incident Volume and Trends

How many incidents does the organisation handle? Track volume by priority, by category, and over time. Increasing volume might indicate growing IT footprint or increasing adoption of IT services. Decreasing volume might indicate improved system stability or reduced IT usage. Volume itself is not good or bad; trends reveal what is changing.

Also track recurring incidents: if the same incident type appears weekly, it might indicate a root cause that could be fixed (patches, process change, training). Use incident volume reports to identify opportunities for improvement: which categories have the highest volume? Which have the highest customer impact? Prioritise fixing those.

SLA Compliance and Adherence

Service Level Agreements define targets: high-priority incidents respond quickly, resolve within a timeframe appropriate to priority. Track compliance: what percentage of incidents meet their SLA? High compliance rates are typical; rates that consistently lag signal that the service cannot meet its commitments. Investigate gaps: understaffing, complex incidents, or unrealistic SLAs?

Report SLA compliance by priority and category. Some categories might consistently miss SLAs (security incidents) while others exceed targets. This insight helps with staffing and priority setting.

First Contact Resolution

What percentage of incidents are resolved in a single interaction without escalation? High first contact resolution (FCR) reduces customer frustration and operational cost. Track FCR by category: if password reset is resolved quickly on first contact but configuration changes require multiple interactions, that tells you something about process maturity and training.

FCR is not a perfect metric (a wrong resolution is worse than an escalation), but it is a useful signal of how well the organisation understands customer problems.

Service Availability and Uptime

How often are critical systems available? Uptime should be high for business-critical systems. Track availability by service: email availability, network availability, application availability. Also track causes of outages: planned maintenance, hardware failure, software bug, or external cause? This helps predict future outages and plan preventive measures.

Cost Metrics and Efficiency

How much does the service cost per incident resolved? Cost per user supported? Cost per ticket? These metrics help understand whether the organisation is using resources efficiently. If cost per ticket is increasing, either incident volume is dropping or costs are rising. Investigate which. Also compare costs across similar organisations (benchmarking); if your costs are significantly higher, that might signal inefficiency or opportunities for improvement.

Reporting Best Practices

Report metrics to different audiences: executives see high-level trends (uptime, SLA compliance, customer satisfaction). Managers see detailed trends (by team, by category). Individual contributors see their personal metrics (their ticket volume, their SLA compliance rate). Tailor reports to audience and use case.

Also highlight exceptions: incidents that were resolved fast even though priority was high, or incidents that took longer than expected and why. Context helps stakeholders understand the numbers and act on them.

Choosing a measure is choosing the behavior it will reward

A metric on a leadership page changes what people do during the week. If the figure for ticket handling is a count of closures, the queue gets cleared by closing items that are not finished. If customer satisfaction is reported only from surveys sent at closure, the team learns to resolve the easy cases and avoid the difficult ones that need a second visit. None of this is a failure of the people involved. It is what happens when a number is treated as the goal. So the first design question for any KPI is which behaviour it will push, and whether the people being measured would recognize that push as fair.

This is why a useful KPI list is shorter than a catalogue of everything the platform can count. Each candidate should be paired with a counter-measure that stops it being gamed. Resolution time paired with reopen rate is a common example, because it stops a fast closure from looking like a good result when the same issue returns the next day. The pairing is a design decision, and it belongs in the KPI definition, not in a footnote.

A working table for testing each candidate measure

An ordered procedure for building a KPI card

1. Write the business question in one sentence, starting with the decision it informs. A card that cannot state its decision is a decoration.
2. Define the numerator and the denominator in terms of table fields and states, not in prose. Two analysts reading the definition should build the same query.
3. Name the counter-measure and place it on the same card, so a reader sees both figures together.
4. Agree the time basis: the date the record was created, closed or last changed. Each choice moves the trend line differently.
5. Set the review rhythm and name who responds when the figure moves. A metric with no named responder can become wallpaper within a quarter.
6. Run the card against three past periods and check that the movement matches what the team already knows happened. If it does not, fix the definition before publishing.

When a KPI moves and nothing seems to have changed

An unexplained movement is often one of four things, and it is worth ruling them out in order. The first is a change to a state model or a workflow, which alters when a record enters or leaves the count. The second is a backfill, where a data load or a bulk update touched old records and stamped them with new timestamps. The third is a change in the user population, such as a new team inheriting records with a different closure habit. The fourth is a real change in demand, which is the one people hope for but rarely check first. A change log kept beside each KPI card is a cheap habit that answers the first question in any review: what was altered?

Some measures should never reach a leadership page. A figure that depends on a manual field, a survey with a tiny response base, or a count that cannot be reproduced by a second person will generate debate about the number instead of decisions about the service. Those belong in an operational view for the team that can correct them, with a clear label on what they are.

Questions to ask before a KPI goes on the leadership page

Which decision will change if this number goes up or down by a meaningful amount? Who will be blamed if it moves, and is that person the right one to act on it? Can the figure be reproduced from the platform without a spreadsheet step? What would a team do to improve it that the business would not want them to do? If the answers are clear, the measure is probably ready. If they are not, it should wait while the definition is tightened.

Follow-up questions on KPI design

Should a KPI have a target at all?

Only when someone has committed to it. A target that was set by a template and never discussed with the team delivering the work tends to be ignored, or it is met by changing the definition. A measure without a target can still be useful as a trend the owner watches.

How many measures should one leadership page carry?

Few enough that a reader can name what each one is for without scrolling. If a page needs an explanation longer than its own title, some of its measures belong on a drill-down view beneath it.

Can two teams own the same KPI?

They can share the figure, but one of them has to own the definition. When two owners define the same measure differently, the number will be disputed in every review and the dispute will look like a data problem.

What is the difference between a KPI and an operational report?

A KPI answers whether the service is moving in the intended direction and is read at a fixed rhythm. An operational report helps someone act on a queue today. The two can draw on the same data, but mixing them on one page often weakens both.

Performance Analytics indicators are a common way to carry these measures over time, and the performance analytics indicator explained page describes the parts involved. For the broader reasoning on which views should appear on a shared screen, the monitoring dashboard decision design article is a useful companion.

Related guides: ServiceNow Performance Analytics Health Check.