OBLYTECH Logo
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Service Metrics: Build a Metric Dictionary

ServiceNow service metrics become useful when people share the same meaning, scope, source, timing, owner, and limitation. A metric dictionary prevents teams from comparing numbers that appear similar but describe different work or conditions.

For service and reporting owners who need shared definitions for ServiceNow measures used in operational decisions..

ServiceNow service metricsmetric definitionsreporting dictionary

Guide map

Recording what each service metric measures

Start with the decision the metric supports

A metric is only worth defining when someone will act on the number it produces.

Define formula, scope, source, and timing

Two teams can report the same metric name and mean different things by it.

Assign an owner and explain limitations

Every definition needs a named owner who can explain the number and correct it.

The practical framework

Build a ServiceNow service-metric dictionary with name, purpose, formula, source, scope, timing, owner, limitation, audience, and review evidence.

Start with the decision the metric supports

State the decision, audience, service, and action the metric should support. A measure may inform service review, incident response, change planning, demand, or improvement. If it does not change interpretation or action, its place in the reporting set should be questioned.

The ServiceNow monitoring-dashboard route is the relevant internal destination when measures appear in operational views.

Define formula, scope, source, and timing

Record the calculation, included and excluded records, source fields, time window, refresh condition, unit, and treatment of missing or late data. A definition should help a reviewer reproduce the meaning without guessing.

The ServiceNow data-quality route provides an internal path when source quality affects interpretation.

Assign an owner and explain limitations

Name the owner who can explain the metric, correct its source, approve a definition change, and communicate limitations. State what the metric cannot show. A measure can be accurate within its boundary and still be unsuitable for a broader decision.

The ServiceNow service-owner route is relevant when accountability and evidence need review.

Prevent competing versions of the same measure

Compare names, formulas, filters, time windows, and source systems before creating another metric. Retire or clearly distinguish definitions that no longer apply. Keep related measures separate only when their decisions or boundaries genuinely differ.

The ServiceNow process-automation route supports controlled reporting changes.

Review whether the metric still helps

Review user interpretation, data changes, service changes, exceptions, and decisions made from the metric. Update the definition when the underlying process changes, and record the reason, owner, effective date, and affected views.

For service metric dictionary work, the ServiceNow continuous-improvement route provides the next internal path.

Common questions

Questions teams ask about service metrics

Is a metric definition just a formula?

No. It also needs purpose, scope, source, timing, unit, owner, limitations, audience, and handling of missing or exceptional data.

Who should own a service metric?

The owner should be able to explain its meaning, confirm the source, approve changes, and address a problem that could make the measure misleading.

The research-grounded boundary

Service metrics are only as dependable as the practice behind them. A configured report can exist long before anyone maintains it, so the important distinction is between a configured path and a dependable operating practice. The second needs a maintained owner, clear dependencies, and reviewable evidence. Use those three checks as the stopping point for the dictionary, rather than a general statement that the platform can report the measure.

Start with the decision a metric has to support

A metric dictionary is only as useful as the decisions it supports. Where the measures roll up into a scorecard, the same rule applies at each level. Before recording a formula, the service reporting lead should be able to say who will read the number, what they will do differently if it rises or falls, and how long the value stays meaningful. Measures that change no action tend to survive because they look important, and they then compete for attention with the measures that do. A dictionary with a long list of entries nobody reads is less useful than a short one that every review relies on.

The fields every entry needs

FieldWhat it must answerCommon gap
NameWhat the measure is called in every report and dashboardTwo dashboards use the same name for different calculations
Purpose and decisionWhich action the number informsWritten as a description of the chart rather than the decision
Formula and inclusionsWhich records count, which are excluded, and how the value is calculatedExclusions for paused, canceled or reopened records are left implicit
Source and timingWhich table or feed supplies the data, the time window and the refresh ruleLate or backfilled records change historical values without notice
Owner and limitationWho answers for the number and what it cannot tell the readerOwner is a team name, so nobody answers the question

The limitation field is one teams often leave blank, and a reviewer needs it most. A measure of resolution time, for example, cannot separate a fast fix from a record closed to clear a backlog unless the closure rule is stated alongside it.

Define the calculation so a second person can reproduce it

A reviewer should be able to rebuild a value from the definition without asking the author. That means naming the table, the state values that count as complete, the time zone used to assign records to a period, and how the calculation treats a record that moves between teams during its life. Write down what happens when a source field is empty. Without that line, two analysts will produce two different numbers from the same data, and both will be defensible.

A procedure for adding or changing a metric

  1. Write the decision the metric will inform and the person who will act on it. A periodic operational intelligence review, which traces a path from source observation to action, is one forum in which to test that decision.
  2. Draft the formula, inclusions, exclusions and source, then test it against a small set of records a reviewer can check by hand.
  3. Compare the result with any existing report that claims to measure the same thing, and record why the two differ if they do.
  4. Assign an owner who can answer questions about the number, and publish the entry where the reporting audience can find it.
  5. Log every change to the formula with the date, the reason and the approver, and keep the previous version available.

Common ways a dictionary drifts

  • A dashboard is cloned, a filter is edited, and the new view quietly measures a different population while keeping the original title.
  • A team changes how it closes records, which shifts the meaning of a metric without anyone updating the entry.
  • A metric is removed from the dashboard but still runs in a scheduled report that a manager relies on.
  • Targets are set against a value whose definition has changed since the target was agreed. Where the target is a service level, the SLA design guide covers translating a service commitment into conditions the platform can measure and a team can act on.

How to tell the dictionary is doing its job

The dictionary is working when two people in different roles can reproduce the same figure, when a question about a number is answered by pointing to an entry rather than convening a meeting, and when the review agenda contains fewer requests to explain what a metric means. Check the audit trail of definition changes at each review cycle. The monitoring dashboard decision design guide covers designing dashboards that display such measures around a defined audience and decision. A metric whose definition has changed several times within a year without a stated reason needs a conversation about whether it is measuring a moving target.

When not to add a metric

Do not add a metric to satisfy a request for more detail. If nobody can name the action it would change, the request is really for reassurance, and a narrative update may meet that need better. Keep the dictionary short enough that the people who use it can find the entry they need in seconds.

Metric definition questions

What does a metric definition need beyond the formula?

A formula is only one part of the definition. The inclusions, source, time window, owner and limitations are needed for a reader to trust the number and to know when it should not be used for a comparison.

What do we do when source data is incomplete for a period?

State the treatment in the entry before it happens. Options include excluding the period, flagging the value as provisional, or back-filling from a documented source. Whichever is chosen, the reader should be able to see that the value has been adjusted.

Where should the dictionary live?

Close to the reports it describes, with a link from each dashboard to its entry. A separate document that nobody opens will drift away from the live calculation within a few cycles.

How do we retire a metric without losing its history?

Mark the entry as retired with the date and the reason, keep the calculation available for the period it was used, and point to the replacement measure. Historical comparisons then remain explainable.

Next step for the metric set

If your service reviews rely on numbers that different teams calculate in different ways, a short session on the entries that matter most is a practical first step. Start a conversation about building the dictionary.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog