ServiceNow Performance Analytics for ITSM: Roles, Responsibilities and RACI

Performance Analytics Authority and Governance Structure

Performance Analytics in ServiceNow measures IT service management effectiveness through dashboards, KPIs, and trend analysis. Unlike transaction modules, analytics requires coordination between business stakeholders (who define what to measure), IT operations teams (who ensure data quality), data analysts (who build reports), and IT leadership (who act on insights). The RACI structure defines clear authority to prevent analytics initiatives from stalling due to unclear accountability.

Metric Definition and Business Alignment

Effective performance analytics begins with defining what metrics matter to the business. The RACI for metric definition is shown below.

The business owner (usually a service manager or director) determines what metrics drive decisions. Response time to incidents? Cost per incident resolved? User satisfaction? Different organisations prioritise differently. IT must collaborate to ensure proposed metrics are achievable and based on reliable data.

A critical rule is that metrics should drive action. If a metric shows performance is declining, someone must be accountable for improving it. If metrics exist but no one acts on them, analytics becomes a reporting exercise without impact. The business owner must be willing to make decisions based on analytics data.

Dashboard Design and Implementation

Once metrics are defined, dashboards visualise them for stakeholder review. Dashboard design requires user experience consideration, technical implementation, and ongoing maintenance.

Effective dashboards are focused. A dashboard showing twenty metrics overwhelms users. Dashboards should highlight the most critical metrics, with drill-down capability for deeper analysis. Design dashboards for the audience: an executive dashboard shows trends and high-level status; a team dashboard shows operational details.

Refresh rates affect utility and performance. Performance Analytics indicators are collected by scheduled jobs, typically daily, so a dashboard built on them is as fresh as its last collection; live figures come from standard reports rather than from faster collection. Choose refresh rates based on decision-making needs. Use standard reports or interactive filters for operational teams that need current records, and collected indicators for trend review by management.

Data Quality and Metric Accuracy

Analytics are only as good as underlying data. Incorrect data produces misleading metrics. Data quality governance ensures ServiceNow data is reliable enough for analytics.

Common data quality issues in ITSM include: incidents missing priority (how can you calculate SLA compliance if priority is not recorded?), incidents without assignments (cannot analyse team performance), change records with incomplete impact fields, and knowledge articles never marked as published. Operations teams who enter data must understand that data quality affects analytics and decisions made based on them.

Escalation and Alert Management

Analytics should trigger alerts when performance degrades. Questions about escalation focus on what metrics warrant alerts, who receives alerts, and what actions result.

Define alert thresholds based on your SLAs and targets. An alert might be: if incident SLA breach rate is increasing steadily, notify the incident manager. If incident response time is trending longer than typical, notify the service manager. Clear alert definitions prevent alert fatigue (too many alerts ignored) and missed problems (alerts set too high).

Trend Analysis and Continuous Improvement

Beyond current dashboards, analytics should help identify trends and improvement opportunities. A trend showing incident volume increasing steadily suggests need for more staff or process improvement. A trend showing MTBF (mean time between failures) declining indicates reliability issues.

Analytics should be reviewed regularly, ideally in business reviews with stakeholders. Use analytics to identify what is working well and what needs attention. This discipline ensures analytics drives action rather than sitting unused.

Role descriptions that say what each person must not do

Role descriptions for analytics usually list what someone is responsible for. They rarely say what that person must stay away from, and that is where many problems start. An analyst who can edit the measure they are being judged on, or a service owner who can change the target they report against, will eventually face the temptation to tidy a figure before it is shown. Writing the prohibitions into the role itself is a plain control, and it costs little.

The catalog below gives a working set of roles for an ITSM analytics team. It is a starting point. Small organizations often combine two of these roles in one person, and that is workable as long as the prohibitions for both roles are respected by that person.

The fourth column matters as much as the first. Each role has a moment at which the knowledge sits with one person, and the handover at that moment is where the measure silently changes meaning.

Handing over a measure without losing its meaning

1. Write down the current definition as it is actually calculated, not as it was first described, and have the outgoing owner sign it.
2. Walk the incoming owner through three recent records, showing which fields the measure reads and how the result is produced.
3. List every open dispute, data correction or pending change request connected to the measure, with the person who raised it.
4. Transfer edit rights only after the incoming owner has read the definition and confirmed it in writing.
5. Record the handover date in the decision log, so any change in the trend can be placed against it.

Teams often skip the third step. An unresolved dispute left in an inbox becomes a surprise months later, and it usually resurfaces at the moment a figure is most visible.

Cover for absence and on-call duty for figures

A dashboard that breaks on a Friday evening can be left until Monday if its figures are only reviewed weekly. A dashboard that feeds a leadership pack needs someone who can answer for it during the week of the review. Name a covering person for each measure, and agree what that person is allowed to do in the owner’s absence. A reasonable limit is to confirm that a figure is correct or to flag that it is not, without changing the definition or the source records. Changes wait for the owner.

Keep the cover list short enough that each person can realistically hold it. A covering person who holds many measures is unlikely to notice a fault in any of them.

Where roles overlap and where they should not

Overlap is normal between the metric owner and the data steward, and between the dashboard builder and the platform administrator. It is a problem when the same person both defines a measure and corrects the data behind it, because they can settle a disagreement in their own favor without anyone else seeing it. Where that overlap is unavoidable in a small team, require that corrections to source data are logged and reviewed by someone who does not own the measure. The guidance on governing assignment groups covers a similar question of ownership in the operational setting.

Team leads should not hold edit rights on the measures they are reviewed against. They can and should comment, and their comments should be recorded, but the definition belongs with the metric owner.

Signs the role model is not being followed

• A measure has changed definition and nobody can say who approved the change.
• The person who builds a dashboard is also the only person who knows what it measures.
• Team leads are asking for changes to the views of their own teams.
• A role has been empty for a cycle and the work has quietly stopped.
• Access to analytics has been granted through a personal request rather than group membership.

Questions about who does what

Can one person hold several roles?

Yes in a small team, provided their prohibitions are respected and a second person reviews any correction to a source record. The combination to avoid is metric owner and sole data steward for the same measure.

Should the platform administrator decide which measures are built?

No. The administrator builds what the metric owner has specified and approved. Asking the administrator to choose measures moves a business decision into a technical role that is not accountable for its outcome.

What happens when a service owner leaves mid-cycle?

The handover steps above apply, and the acting owner should not change any target until the incoming owner has confirmed the existing one. A target set by someone who has left is still a target, and it should be treated as such until someone with authority changes it.

How do we keep these roles visible to new staff?

Include them in the onboarding material for the analytics team, and link each measure in the register to its owner, so a new person can find who to ask without searching.

Agreeing the role model for your team

If your analytics roles exist in people’s heads but not on paper, drafting the catalog is a useful first conversation. Once roles are agreed, the wider team needs a way to learn them, and the user adoption and training service describes what that service covers.