ServiceNow operating model
ServiceNow value realization connects platform work to service ownership, workflow evidence, user behaviour, exceptions, decisions, and the operating model that keeps the service useful.
State what decision the evidence must support. Avoid collecting measures that do not change an operating decision.
The ServiceNow platform operating model route provides the internal path when value depends on clear authority and governance.
Name the service owner, workflow owner, data authority, support route, and decision forum. A platform team may enable the workflow without owning the business outcome.
Connect each measure to a source, review owner, time period, definition, and action. A number without context, authority, or action is an activity signal rather than a value conclusion.
Review where users abandon a path, teams work around the process, ownership is unclear, or an exception remains open. Adoption is evidence about whether the operating design is usable and understood.
The ServiceNow continuous-improvement route gives an internal path for recurring findings.
Revisit the model when a service, workflow, integration, role, channel, or decision boundary changes. Retire measures that no longer answer a useful question.
Evidence is useful when it is defined, traceable, reviewed by an owner, and connected to a decision.
The service owner owns the business outcome, while the platform owner governs the enabling capability and its controls. Decision rights should be documented.
Treat value realization as a governed workflow: define the question, evidence source, human review, exception signal, decision, and follow-up record.
A ServiceNow investment is often justified with a projection of what it will change: fewer manual steps, faster resolution, fewer repeat contacts. Once the platform is live, the same people are asked whether those changes happened, and they can answer only if someone measured the position before the change. Without a baseline, every answer is an impression. The first discipline in value realization is therefore not a dashboard but a short, dated record of how the work was done before the platform touched it, captured with the same definitions that will be used afterwards.
The baseline does not need to be elaborate. It needs to state what was counted, over what period, from which records, and what was excluded. A team that can say the request volume in a given month was measured from a named source, with duplicates removed in a stated way, is in a far stronger position than one that remembers the work felt heavier.
Most value measures are only as reliable as the record they come from. Platform data is a rich source, but it reflects how people used the platform, which is not always how the work was done. The table sets out common measure types, where they usually come from and the caveat a reader should keep in mind.
| Measure type | Usual source | Owner who should review it | Caveat to state with it |
|---|---|---|---|
| Cycle time for a workflow | Timestamps on the workflow records | Process owner | Waiting time spent outside the platform is not captured |
| Work completed without rework | Reopen and reassignment history | Service owner | Reopening may reflect a policy change, not poor quality |
| Use of a self-service route | Submission counts by channel | Digital channel owner | Users may have moved from another route, so totals may not grow |
| Staff time released | Survey or time sample, cross-checked with volume | Operations manager | Estimates are indicative and should be labeled as such |
The staff time row is the one most often overstated. Time saved on paper does not become a budget reduction unless the work is removed or reassigned in a way that the finance function can see. A value statement should say which of the two has happened.
Attribution is the hardest part of value realization, and the one most often glossed over. A reduction in resolution time may follow a new workflow, but it may also follow a change in staffing, a seasonal dip in demand or a process change that was introduced at the same time. A defensible claim describes the change, the period, the other changes that happened in the same window, and the reasoning for believing the platform contributed. It does not present a single figure as the effect of the platform alone.
Where two changes overlapped, the honest position is often a range or a qualitative conclusion, supported by the workflow evidence. Stating the limit is not a weakness. A reader who later finds an unacknowledged overlap will discount the whole case.
Value cases tend to stop when the project closes, which is when the platform begins to change. A benefits register kept after go-live records each intended benefit, the measure used to track it, the owner, the review date and the decision the measure is meant to inform. Benefits that are no longer achievable should be closed with a reason rather than left to decay quietly. Benefits that are achieved should show what the organization did with the result, because a benefit that is realized but not used has not changed the operating model.
The register is also the place to note exceptions that matter to value, such as a workflow that users avoid, or a team that has built a workaround. These are early signals that the benefit will not arrive as planned, and they are easier to act on while the project team is still around.
Usually not. A single figure hides the mix of measures behind it and invites a debate about the assumptions rather than the decision. A short set of measures, each with its source and caveat, supports better decisions than one headline number.
Early reviews are useful for adoption and workaround signals, but they are weak evidence of outcome. Outcome measures need a period that covers normal cycles of the work, including at least one peak if the service has one. The review schedule should reflect that rather than a fixed monthly habit.
That is a finding. It may mean the platform did not address the constraint that was assumed, that the process was not changed to match the workflow, or that the baseline was measured against the wrong population. Each of these leads to a different action, and the register should record which one the review concluded.
The measure owner, after agreeing the change with the people who use the figure. Changing a definition mid-period without recording it makes the trend meaningless, and it is one of the most common ways a value case loses credibility.
Finance leaders and operations directors read value reports for different reasons. A finance reader wants to know whether a cost has moved, whether it is recurring, and whether the movement will persist without further spend. An operations reader wants to know whether the service is easier to run and where it still needs attention. A single report that tries to answer both usually answers neither well. A practical structure gives each reader a short summary of the measures relevant to their decision, with the source and caveat beside each figure, and a separate note on what the platform is still expected to deliver.
The timing of the report matters too. A report that arrives after the budget round has been set is a record rather than a decision input, and a report that arrives with no comparison to the baseline is an opinion. Agree the reporting calendar with the people who will use it before the first figures are produced.
Say what the measure is for. Adoption data tells the owner whether the design is usable and understood. If the same figure is used to rank individual teams or staff, people will avoid the workflow or record activity to protect their position, and the measure will stop describing the work. Keep adoption reviews focused on the design and the route, and keep individual performance discussions separate.
If the platform is already live and no baseline exists, begin with the one workflow that carries the largest stated benefit. Reconstruct the earliest reliable records available, state the gap honestly, and set up the measure so it is captured from now on with a named owner. The platform operating model page covers who decides on platform matters such as data, standards and exceptions, and the reporting and dashboards governance model covers ownership and accountability for reports and dashboards. To talk through a value model for a platform that is already running, start a conversation about your baseline, measures and register.
Bring the outcome, evidence, or ownership question that needs a clearer operating model.
Discuss value realizationGuides from the Oblytech ServiceNow library that explain the practice behind this page.