ServiceNow Performance Analytics for ITSM: Guides and Services

What Performance Analytics Covers

Performance Analytics is ServiceNow’s analytics framework for the ITSM suite. It provides dashboards and reporting that measure operational effectiveness across Incident Management, Change Enablement, Request Fulfillment, Service Level Management and Problem Management. The module is built on indicators, which are metrics calculated from your operational data, and dashboards, which visualize those indicators over time.

The base Performance Analytics module includes pre-built indicators such as incident volume by priority, average resolution time, change success rate, and fulfillment cycle time. Organizations can use these indicators immediately to understand their service delivery. Indicators can be calculated at different frequencies: daily, weekly, or based on custom schedules. Each indicator can be filtered by business unit, team, or other dimension to provide targeted views.

Using This Section

This section includes guides covering different aspects of Performance Analytics implementation and operation. If you are new to the module, start with foundational guides that explain what Performance Analytics is and how to access standard dashboards. If you are planning an implementation, read guides on how Performance Analytics integrates with your ITSM configuration and what indicators matter for your business. If you are supporting the platform, guides cover how to create custom indicators, audit data quality in your dashboards, and troubleshoot calculation issues.

Each guide is focused on a specific task or decision. You do not need to read them in order. If you have a specific question about Performance Analytics—for example, how to measure customer satisfaction or how to create a dashboard for your IT director—find the guide that matches your question and work through it. Many guides include worked examples using common ITSM scenarios.

How Oblytech Supports Performance Analytics

Oblytech works with organizations to design their Performance Analytics implementation. We help define which indicators matter for your business, configure the calculations, and create dashboards that answer the questions your stakeholders are asking. For organizations implementing Performance Analytics as part of a larger ITSM project, Oblytech can integrate Performance Analytics configuration into the overall design and roadmap.

For running platforms, Oblytech provides managed support for Performance Analytics. This includes monitoring indicator calculations, troubleshooting data quality issues, and helping you interpret your metrics. We can also advise on how your Performance Analytics data connects to other reporting tools you may use, such as your business intelligence platform or executive dashboard system. As your needs evolve, dashboards can be refined to address new questions.

Key Capabilities of the Module

Performance Analytics can measure aspects of ITSM that matter most to your organization. For incident management, you can track response time, resolution time, quality metrics like rework or customer satisfaction. For change management, you can measure approval cycle times, success rates and schedule adherence. For request fulfillment, you can track fulfillment time, availability of self-service options and catalog usage. Each type of measurement gives insight into how well the process is working.

Indicators are flexible. You can calculate most metrics as a sum, average, count or percentage. You can break down metrics by dimension, showing how incident performance differs by assignment group or by business unit. You can set targets and track actual performance against targets. This allows you to understand not just what is happening, but whether performance is meeting business expectations and where to focus improvement efforts.

Common Questions About Implementation

Organizations typically want to know whether they should implement Performance Analytics at the same time as their Incident or Change module, or wait until operations are stable. Most benefit from implementing indicators for the core processes first, then adding more complex metrics later. This allows a period of operational learning before you commit to targets and reporting. Early implementation also helps you understand data quality issues in your incident and change data.

Another common question is whether Performance Analytics requires custom development. Most organizations get significant value from pre-built indicators. Custom indicators are useful for measuring unique business metrics, but only after you understand the standard metrics and your platform is configured correctly. Consider the maturity of your processes before adding custom indicators.

Route each question to the guide that answers it

The right starting point depends on the decision in front of you rather than on your job title. A service owner who has to justify a budget line needs different material from an analyst who is about to rebuild a dashboard. The table gives a routing that avoids reading the wrong guide first.

The routing also reflects a point that is easy to miss. Performance Analytics produces what the underlying records allow it to produce. If the incident, change or request data is inconsistent, the dashboards can be consistent in appearance and wrong in substance. Several of the guides below therefore start with data definitions rather than with charts.

Decide what each indicator is for before you build it

Every indicator on a dashboard should have a named decision it supports. Ask the owner what they would do differently if the number went up or down, and by how much. An indicator that prompts no action is a reporting cost with no return. This test removes most of the clutter that accumulates in the first year, and it also shows which indicators need a target and which only need a trend line. The distinction between a target and a trend is worth settling early, because a target can invite the behavior the measure is meant to detect. The explainer on how indicators are defined and calculated is the place to check the detail.

Sequence the build so the early results can be trusted

1. Pick the process with the cleanest data, usually the one that has been stable for the longest, and build its indicators first. Early wins on messy data can erode trust in the rest of the program.
2. State each indicator’s definition in one sentence that names the start, the stop and the records counted. Put the definitions where the audience can read them.
3. Run the indicators in parallel with the existing report for a period, and investigate every difference before retiring the old report.
4. Agree the first targets only after a baseline period, and state in writing that early targets are provisional.
5. Add breakdowns, such as assignment group or service, one at a time, checking each against a manual sample before the next is added.

Cases where the dashboards should wait

Some organizations should delay the dashboards. If the core process has changed recently, the baseline is not yet meaningful, and the first dashboards will show the transition rather than performance. If the team has no one who can explain the calculations, the platform will become a black box that people either trust blindly or ignore. Under those conditions, a period of disciplined data capture is the better first step, with fields that are mandatory where they matter and a clear owner for each definition. The dashboards can follow once that foundation is in place.

Questions that come up when the first dashboards go live

Why does the same indicator show different values in two places?

Usually because the two views use different filters, time windows or breakdown dimensions. Check the time zone and the period boundary first, then the filter on the source records. A difference of a few records near a month-end is normally a boundary effect rather than a fault.

Can we use Performance Analytics to compare teams?

You can, with care. Comparisons work best when teams handle similar work, so the indicators are measuring like with like. Compare a team with a different mix of request types and the result says more about the mix than the team. Segment first, then compare.

Do we need a separate reporting tool for executives?

Not necessarily. Many organizations use a small set of platform dashboards for executives and reserve other tools for financial or cross-system reporting. The deciding question is whether the executive audience needs data from outside the service platform. If it does not, a second tool adds a reconciliation burden without adding insight.

How often should the indicator set be reviewed?

Review on a cadence your service owner can defend, more often in year one. Review each indicator against the decision it supports, and retire any that no one has used in a business review since the last review.

Choosing the first indicators

Bring the list of decisions your leaders make each month and the reports they rely on now, and the discussion can focus on which measures earn a place on the dashboard. The guide to reporting and analytics on the ServiceNow platform is the page to check for wider context on how these reports sit beside other platform reporting.

ITSM analytics in ServiceNow works best when Performance Analytics and standard reports each do their own job

ITSM analytics in ServiceNow uses two tools. Standard reports query live records each time someone opens them, while Performance Analytics collects scores on a schedule and stores them, so trends survive even when the underlying records change. Use reports for the current queue, and Performance Analytics for trends, targets and comparisons over time.

The difference decides which tool answers a given question:

The last row catches teams out. A stored score reflects the data as it stood when the collection job ran, so correcting records afterwards does not alter old scores. When an indicator definition changes, plan a historical collection so the trend line uses one definition throughout, and say on the dashboard when the definition changed.

In most implementations the sensible split is simple. Operational dashboards for team leads use reports, because they need the queue as it is now. Management dashboards use Performance Analytics, because they need movement against a target. Putting both on one page confuses readers, since the two can disagree for good reasons.

The reporting and dashboards guides cover the report side, and the dashboard explainer shows how the pieces sit on a page. To see how stored indicators connect to other tools, read the integration patterns guide.

Is Performance Analytics the same as a ServiceNow dashboard?

No. A dashboard is a page that displays content. Performance Analytics supplies stored indicator scores that a dashboard can show. A dashboard can also display ordinary live reports with no Performance Analytics behind it.

Can a standard report show trend history?

Only as far as the records allow. A report can chart records by created or closed date, but it cannot show a score as it stood last quarter if the underlying data has since changed.

What does a data collection job do?

It runs on a schedule, calculates each indicator from the records at that moment, and stores the result as a score. The stored scores form the trend line that dashboards display.