ServiceNow Scorecard Explained

Definition in Plain Language

A Scorecard in ServiceNow is a visual dashboard that displays key metrics and performance indicators for a specific area of the business. It collects data from various ServiceNow modules (Incident Management, Change Management, Request Fulfilment, etc.) and presents them in an easy-to-understand format: numbers, charts, and trends that show how well that area is performing.

The key insight is that Scorecards are business-oriented, not technical. A Scorecard shows “How many critical incidents do we have open?” and “What is our average time to resolve?” rather than “What is the CPU utilisation of the server?” Scorecards are designed for leaders who need to understand performance at a glance, not technicians who need deep technical data.

Scorecards differ from dashboards by being more structured and standardised. A dashboard is customisable and ad-hoc; a Scorecard follows a defined format with established KPIs (Key Performance Indicators) that are tracked consistently. Scorecards are often used for governance and reporting to executives; dashboards are used for day-to-day operational monitoring.

How It Lives in the Platform

Scorecards are configured in ServiceNow through a dedicated Scorecard module. You define a Scorecard by selecting KPIs (incident count, change success rate, request fulfillment time), setting targets for each KPI (incident count should be under 10 for critical incidents), and configuring how data is retrieved and displayed. ServiceNow automatically populates the Scorecard with current data as records are updated in the system.

Scorecards can be restricted to specific audiences through role-based permissions. An IT Director might see a Scorecard of overall IT health; a specific team might see a Scorecard for their area only. A customer or business stakeholder might see a simplified Scorecard showing only the services they care about.

Scorecards update automatically as data changes, so they always show current performance. Some Scorecards update in real-time (as incidents are created); others update periodically (daily, weekly) depending on configuration. Scorecards can also be scheduled to generate alerts (if critical incidents exceed threshold, send an alert to the manager).

A Worked Example

Imagine an IT operations team that wants to track health of the customer-facing email service. They create a Scorecard showing: total incidents affecting email this month (target: under 3), average incident response time (target: under 30 minutes), change failure rate for email (target: a low share of changes), and user satisfaction with email support (target: above 4 out of 5). Each KPI pulls from ServiceNow data automatically.

The Scorecard displays visually: incident count as a green number if below target, red if above. Response time as a trend (is it improving or degrading?) with an arrow. Change failure rate as a percentage bar. User satisfaction as a star rating. A manager looking at this Scorecard in 30 seconds understands email service health and whether action is needed.

The team reviews this Scorecard in a weekly operations meeting. If incident count is trending up, they investigate what is changing. If response time is slowing, they ask whether staffing is adequate. If change failure rate is high, they implement process improvements. The Scorecard drives conversation and decision-making based on real data.

Common Misunderstandings

A frequent confusion is treating Scorecards as performance management tools for blaming individuals. If a Scorecard shows low customer satisfaction, the question should not be “who is responsible?” but “what is broken?” A Scorecard shows system performance; fixing it usually requires process changes, not personnel changes. Teams that fear being blamed for poor Scorecard numbers will game the metrics (close incidents too quickly, mark changes as successful when they are not).

Another misunderstanding is creating Scorecards with too many KPIs. A Scorecard with 20 KPIs is hard to digest and drives behaviour in too many directions. A good Scorecard has 3-7 KPIs that focus on what truly matters for that area. Start with the most critical metrics; add more later if needed.

A third confusion is assuming Scorecards are for executives only. Team-level Scorecards are valuable for day-to-day operations. A team Scorecard might track tickets closed per day, average handle time, quality metrics (first-contact resolution rate). Teams use these to optimise their own performance without waiting for management reviews.

Scorecard Design and Selection of Metrics

Good Scorecard design balances multiple perspectives. Include lagging indicators (what already happened: incident count, resolved incidents) and leading indicators (what predicts future performance: approved changes, staffing level). Include efficiency metrics (cost per incident) and quality metrics (customer satisfaction). Include output metrics (what was delivered) and outcome metrics (what business value was achieved).

Scorecards should drive desired behaviour. If you include “incident count” as a KPI, teams will focus on closing incidents (good). If you only include “incident count” without quality metrics, teams might close incidents prematurely (bad). Include both volume and quality to balance the incentives.

Start with the decision the scorecard has to support

A scorecard that nobody acts on is a decoration, and many scorecards that fall into that state were built by starting with the available data rather than the decision. The useful first question is narrower: what will the service owner do differently in the next review because this scorecard exists? If the honest answer is nothing specific, the scorecard should be deferred until there is one. A scorecard for a quarterly service review needs a different set of measures from one used in a weekly operations meeting, even when the underlying data is the same, because the people reading it are looking for different kinds of movement.

Whether a live view or a scorecard fits the decision is a separate question, and the guide to monitoring dashboard decisions sets out the difference. Write the decision down as a sentence before any measure is chosen. For example, the owner decides whether to add capacity to a queue, whether to pause a change category, or whether to escalate a supplier. Each measure on the scorecard should then be traceable to one of those decisions. Measures that cannot be traced are often there because someone asked for them once.

Measure types and the trap in each

Measures group into families, and each group has a typical way of misleading the people who read it. Knowing the trap in advance is cheaper than discovering it in a review.

Measure family	Good for	Trap to watch for	Test before adding it
Volume of work arriving	Explaining demand and staffing needs	A rise can look like poor performance when it reflects a successful launch elsewhere	Can the owner name the demand source behind each spike?
Elapsed time to completion	Showing how long the customer waits	Averages hide a long tail of stuck items	Is the distribution shown, not only the mean?
Share of work within a target	Setting a service commitment in plain terms	Targets are often set on a whim and never tested against history	Does the baseline period support the target?
Rework or reopened items	Revealing quality problems behind closure figures	Reopening rules differ between teams, so the number is not comparable	Is the reopening rule written down and applied the same way everywhere?
Satisfaction responses	Hearing the customer’s view directly	Response rates can be too low to read, and the sample skews toward extreme experiences	How many responses sit behind the figure, and who did not respond?

The lesson in the table is that no single family is safe alone. A scorecard that combines a volume measure, a time measure and a quality measure gives a fuller picture, and makes it harder for a team to improve one number at the cost of the others.

Setting targets from a baseline you can defend

A target that has no history behind it will be argued about every quarter. The sound approach is to measure the current performance for a representative period first, without any target, and then decide what level the owner is willing to commit to. Use a period that includes the normal peaks, not only a quiet month. If the baseline includes an unusual event, such as a major incident that affected everything, either exclude it with a stated reason or keep it and say so.

Set the target as a commitment the service owner can stand behind, not as an aspiration. A target that is never met teaches people to ignore the scorecard. A target so loose that it is always met teaches the same lesson in the other direction. Put the chosen figure, the period it was derived from and the owner’s name on the scorecard itself, so anyone reading the target can see where it came from.

Changing a measure without breaking its history

Definitions change. A team decides that a ticket should stop the clock while waiting for a customer, or a category is split in two. When that happens, the historical line on the scorecard can jump, and readers may assume performance changed when only the rule did. The safer approach is to version the definition: record the date the change took effect, keep the old series visible for a short overlap, and annotate the chart. Where the change cannot be reproduced on old data, say so rather than back-filling a figure that looks continuous but is not comparable.

The measure dictionary, which holds the agreed definition of every measure, is the place to record these changes. Teams that skip the dictionary often discover the problem only when two scorecards show different values for what everyone believes is the same measure. The guidance on service metric dictionaries covers building a dictionary so that people share the same meaning, scope and source.

A review routine that changes something

A scorecard earns its place when the review it feeds ends with a recorded decision. A practical routine, of the kind set out in the operations review agenda guide, is to start every review with the measures that moved outside their tolerance since the last review, not with the full set. For each one, the owner states whether the movement is explained, whether it needs an action, or whether the definition or target should change. Those three outcomes should be written against the measure itself. Over several cycles, the record shows which measures drive decisions and which are never consulted, and the weakest ones can be removed.

1. Confirm the data behind the scorecard has refreshed, and note the refresh time on the page.
2. Review only the measures that crossed their tolerance, plus any that the owner has flagged in advance.
3. For each flagged measure, record one of three outcomes: explained, action assigned, or definition or target under review.
4. Assign the action to a named person with a date, and link it to the work item where it will be tracked.
5. Remove or replace any measure that has not informed a decision for the last several reviews.

Questions about scorecard governance

How often should the targets on a scorecard be reviewed?

Review them when the service changes materially, such as a new delivery model or a change in who the customers are, and otherwise on a fixed schedule agreed with the service owner. Reviewing targets after every bad month teaches the team that targets move when performance is inconvenient.

Can one scorecard serve both a team and an executive audience?

It is usually better to build two. The team needs measures it can influence within a week, and the executive needs a smaller set that shows whether the service is meeting its commitments. Showing both on one page tends to satisfy neither.

What should happen when a measure looks wrong?

Check the definition, the filter and the data source in that order before deciding the measure is faulty. A measure that looks wrong is often accurate but unexpected, and the review should decide that question explicitly rather than quietly adjusting the figure.

Is a red or green status enough to show on the page?

A status color is a shortcut for the target comparison, but it hides the direction and the size of the gap. Show the trend beside the status, so a measure that is barely failing and falling fast does not look the same as one that is stable and slightly below target.