OBLYTECH Logo
OBLYTECH Logo

ServiceNow / Practical guide

Govern Vendor Performance Through Structured Reviews

ServiceNow vendor reviews should help a service owner decide whether a supplier is meeting the agreed operating need, where risk remains, and what action is required. A meeting that only repeats activity reports does not provide enough evidence for a service decision.

For service owners reviewing whether a ServiceNow supplier or managed service is meeting the agreed operating need..

ServiceNow vendor reviewssupplier service reviewvendor governance

Guide map

Reviewing supplier performance against agreed service levels

Define the service and supplier boundary

A supplier review should separate what the contract promises from what the business actually needs, so the conversation starts from operating reality.

Review evidence against the operating need

Compare the supplier's reports with what the business actually experiences, because a service can look healthy on paper while users struggle.

Examine incidents, changes, and dependencies

Pull the incident and change history for the review period and check how many trace back to a dependency the provider does not control.

The practical framework

Govern ServiceNow vendor reviews with scope, service evidence, commitments, incidents, changes, dependencies, risks, actions, and accountable ownership.

Define the service and supplier boundary

Record the service outcome, supplier scope, internal responsibilities, dependencies, commitments, escalation path, and exclusions. Make clear which condition the supplier controls and which condition remains with the organisation or another provider.

The ServiceNow managed-support route is the relevant internal destination when supplier activity forms part of ongoing support.

Review evidence against the operating need

Use incidents, requests, changes, service-level evidence, quality findings, risks, customer or user feedback, and unresolved actions where relevant. Ask whether the evidence explains service condition and consequence, not just whether work was reported.

The ServiceNow health-check route provides an internal path when controls and evidence need structured review.

Examine incidents, changes, and dependencies

Review recurring incidents, failed or delayed changes, data or integration dependencies, supplier handoffs, and risks that could affect continuity. Separate an isolated event from a pattern, and record the evidence supporting that judgement.

The ServiceNow incident-management route is relevant when service disruption or escalation needs review.

Turn exceptions into owned actions

State the exception, consequence, owner, decision needed, due date, evidence, and escalation trigger. Avoid assigning a general action to “the vendor” when an internal owner must coordinate the response or accept the remaining risk.

The ServiceNow process-automation route supports a consistent review and action workflow.

Prepare for renewal, change, or exit decisions

Use the review record to inform renewal, scope change, remediation, transition, or exit decisions. Record dependencies, data, access, knowledge, and support implications before a supplier relationship changes.

For vendor service review work, the ServiceNow continuous-improvement route provides the next internal path.

Common questions

Questions teams ask about vendor reviews

What should a vendor review measure?

It should examine evidence relevant to the service outcome: commitments, incidents, changes, quality, risk, dependencies, communication, unresolved actions, and the owner’s confidence in the operating boundary.

How should supplier risk be recorded?

Record the risk, affected service, evidence, consequence, owner, current response, decision authority, and review trigger. Do not reduce a dependency to a label without stating what action follows.

The research-grounded boundary

A vendor review is only as useful as the decision it supports. Record what the supplier committed to, what the service actually did, which risks are still open and who answers for each one. A reviewer who was not in the meeting should be able to tell whether the supplier can keep delivering the service.

What a vendor review is actually deciding

A vendor service review is not a relationship meeting. Its job is to decide whether the service the vendor delivers still matches the operating boundary the organization depends on, and if it does not, what the organization will do about it. The review has to come out with a decision on at least one of three things: continue as is, change the terms or the scope, or start a transition. A review that ends with a warm conversation and no decision has spent everyone’s time.

The reader who will act on the review is usually the service owner inside the organization, not the vendor’s account manager. Prepare the evidence from that point of view. What has the service delivered against the commitments? Where did the operating boundary blur? Which risks are now open, and who carries them while the vendor works on them?

Gathering the evidence before the meeting

Assemble the evidence from the organization’s own records first, and only then compare it with the vendor’s report. The vendor’s report describes the service the vendor believes it delivered. The organization’s records show the service that users experienced. Both are useful, but the gap between them is where most reviews find their real agenda.

Evidence areaWhat to look forQuestion it answers
CommitmentsEach commitment in the agreement, with the measured outcomeWas the agreed service delivered in the agreed form?
IncidentsRepeat faults, delayed restoration and escalations caused by the vendor’s areaIs the same failure coming back under a different ticket?
ChangesChanges the vendor made, their validation and any rollbackAre changes arriving with evidence that they worked?
CommunicationNotices of delay, risk and scope change, and how quickly they cameDid the organization hear about problems before users did?
Unresolved actionsOpen items from the last review and their ownersIs the review actually closing things?

A sequence that keeps the review decisive

  1. Agree the decision the review must reach, and circulate it with the evidence pack beforehand.
  2. Walk through the commitments first, because they set the baseline for every other discussion.
  3. Take the incident and change evidence next, looking for patterns rather than single events.
  4. Name each open risk, its consequence, its owner and the current response, and confirm who has authority to accept it.
  5. End with a short list of decisions, each with an owner, a date and a review trigger, and send it to the vendor the same day.

Setting a review trigger can matter more than teams expect. A trigger such as a repeat fault in the same area, a missed commitment in consecutive reporting periods, or a proposed change to the operating boundary tells the organization when to reopen the question without waiting for the next scheduled meeting.

Reading the operating boundary, not just the scorecard

A scorecard can be green while the service is drifting. The usual cause is an operating boundary that no longer describes what the vendor is doing. A support team takes on a small new task informally, a monitoring alert is routed to a different group, or a change is approved in a way the agreement never contemplated. None of these shows up as a missed commitment, but each one moves risk onto the organization without a decision. Ask the vendor and the internal team to walk through the boundary as it operates today, and compare that with the written version.

Look also at what the vendor depends on. A dependency on another supplier, on a particular individual or on an internal team that is short of capacity can make a commitment impossible to meet while the vendor is working as hard as it can. Record that dependency in the review, because the decision may be to change the dependency rather than the vendor.

What good looks like at the end of a review

A useful review leaves the organization with fewer unknowns. Open risks are named and owned. Commitments that were missed have a recovery plan with a date. Boundary questions are answered in writing. The next review has a clear starting point. If the review produces a long list of general concerns with no owner, the process needs to be tightened before the next cycle.

When a review should not be the first move

If the organization has not yet agreed what it expects from the service, a vendor review will measure the vendor against an undefined standard. Write the expectation first. Likewise, if the relationship is already in formal dispute, the review should be run through the process the agreement sets out, not as an informal meeting that may be read later as a concession.

Questions raised in the room and after it

How often should a vendor service review take place?

Regular enough to catch drift and infrequent enough to allow the vendor to act on the last decisions. A fixed cadence that matches the reporting period is often the most practical, with an extra review when a trigger is met.

Should the vendor see the internal evidence before the meeting?

Share the evidence that concerns the service outcome, and keep internal commentary about individuals or internal politics out of the pack. The vendor needs enough to respond to the substance of the problem.

What if the vendor disputes the internal view of incidents?

Ask for the vendor’s records of the same events, and agree the facts before debating the cause. Many disputes shrink once both sides are looking at the same timeline.

When does a review point to a change of supplier?

When the same commitment is missed across several periods, the operating boundary cannot be restored to what was agreed, and the vendor cannot explain the cause in terms the organization can act on. At that point the review should set out the options, including a managed transition, rather than waiting for the contract end.

If a vendor review keeps producing discussion without decisions, agree the evidence and the decision points before the next meeting. Discuss how to structure the review.

The consulting and managed support decision is covered in the note on consulting versus managed support, and the SLA breach prevention guide covers what commitment is measured, when the clock starts and pauses, and who owns the work. For the standing meeting that keeps these decisions moving, see the operations review agenda, and the risk management accountability guide covers risk records that support a decision. The offshore delivery governance and accountability page covers governing offshore delivery.

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