Platform Governance: accountability for your ServiceNow platform, not just availability.
Most platform support answers by phone or email. Very little of it takes responsibility for whether the platform is still coherent, still healthy, and still bringing out more value with every release.
We take that responsibility: clear ownership, one funnel for new demand, deliberate work on platform health and feature readiness, combined with a measurement rhythm that tells you whether the platform is earning its keep.
The decisions about your business stay with you.
The platform is live. There is no governance and no ownership.
There is an admin team, a sponsor and a budget. What there usually is not, is one person accountable for the platform and its governance as a whole. So nobody builds a roadmap or establishes standards, and the value drifts to whoever has capacity that quarter, with nobody looking at it end to end.
Requests arrive in the order they arrive
No single route in, no visible backlog, no view of total demand and no funnel. The loudest request wins, and the platform fills up with changes rather than with best practice.
Technical debt is invisible until an upgrade
Configuration drifts from the baseline, customizations accumulate, and nobody finds out how much until the upgrade that should have taken days takes weeks.
Support fixes symptoms
Incidents get resolved. The causes do not. Preventive work has no deadline, so workarounds get built around known errors instead of solving the issues with best-practice functionality.
Nobody can say whether it is working
Adoption is unmeasured. The business case that funded the platform was filed and never reopened. The renewal conversation happens without evidence, based on a custom rather than a standardized solution.
It is accountability, not availability.
Platform governance means we take named, accountable responsibility for the health, coherence and continued value of your ServiceNow platform. It puts an integrated plan-do-check-act process in place for continuous platform improvement.
Most of what is sold as platform management in this market is capacity: hours, tickets, coverage windows. Capacity is useful and it is not the same thing. A platform can be perfectly well supported and still be drifting: undocumented customizations piling up, two releases behind, licenses paid for and unused, and a backlog nobody has prioritized in a year.
Answerable for the response time
Hours, tickets, coverage windows.
Answerable for the state of the platform
Health, coherence and continued value.
The difference is whether somebody is answerable for the state of the platform, or only for the response time.
What we take on.
Accountable decisions
A named owner. A written decision record. A published split between the decisions we make and the decisions that stay with you.
A governance process
A clear process for establishing platform ownership, and what is needed to bring it into your organization.
Coherent demand
One route in, whoever is asking. A visible backlog. A prioritization basis you can see and argue with.
Sustainable platform health
A health baseline, a technical debt register, release discipline, and a clear position on upgrade readiness.
Measurable value
Baselines, a review rhythm, and the original business case brought back into the room instead of left in a folder.
One prioritized backlog to bring out the most business value
Once a platform is live, requests come from business users, process owners, project teams, auditors, and vendors shipping features you did not ask for. Without one route in, three things follow.
Work happens in arrival order rather than value order.
Nobody can see total demand, so every capacity conversation is a guess.
Changes accumulate that nobody decided to make.
Single intake funnel
A single intake funnel regardless of who is asking
Minimum definition
A minimum definition per request, so two requests can actually be compared
Triage
A triage step that separates something broken from a change from a new capability
Prioritization basis
A prioritization basis you can challenge
Visible backlog
A visible backlog
An answer for declines
An answer for requests we recommend declining, because silently ignoring them is how shadow work starts
A backlog where nothing is ever declined is not a prioritized backlog.
Part of what you are buying is somebody willing to recommend not doing things.
What we own, and what stays with you
A managed service that takes all the decisions creates dependence. One that takes none is a ticket queue. So here is the split, in the open.
What the business needs, and what it is worth
YouYou
Which work gets funded, and in what order
YouYou, on our recommendation
Whether a change is architecturally sound
UsUs, in writing, and you can overrule us
Configure or customize
UsUs, recorded with the reasoning
Whether and when to upgrade
YouYou, on our recommendation
Who may access what
YouYou decide, we design it
What is in the next release
TogetherTogether, on an agreed cadence
Whether to accept a risk
YouYou, always
Every architectural recommendation we make is written down with its reasoning, so the decision can be revisited later rather than re-argued from scratch. That record covers system-of-record, integration pattern and template decisions, and we contract a response time on your side for it, because decision latency is a delivery risk rather than an inconvenience.
And if you overrule us, we record that too.
Along with what we think it will cost later. That is not a threat, it is how a decision record stays useful.
Not sure who owns your platform today?
We will tell you what state it is actually in.
A scan produces findings. Findings are not a plan.
ServiceNow gives you good tooling for this. The tooling covers the first two stages. The last two are what you are paying an owner for.
Scan
HealthScan and Instance Scan inspect the instance and report drift, unused code and inefficient queries.
Findings
Upgradeability checks flag records that differ from baseline, including ones opened and saved without a real change.
Judgment
Finding by finding: intentional and still correct, obsolete, or accidental. Keep and record, plan removal, or return to baseline.
Register
A technical debt register and a prioritized remediation view that gets reviewed rather than filed.
You touch it, you own it.
We review live instances and find capabilities installed, active and fully current with nothing published for them to actually govern. Being active is not the same as being effective, and telling the difference is what you are paying an owner for.
It has no deadline.
A badly indexed table, an inefficient business rule or a deprecated interface becomes an incident eventually, but never today. Preventive work does not happen unless somebody owns it.
The calendar moved, and so did your deadline
ServiceNow releases two major platform versions a year, and supports the current release family and the one before it. Stay outside that window and you stop being entitled to patches and hotfixes, which turns an upgrade question into a security question.
The major release schedule moved, and the deadline to be on a supported version moved forward. If your upgrade planning was built around the old rhythm, your window is now tighter than you think.
There is a real decision here, not a best practice.
Upgrade once a year
Less disruptive, and it lets technical debt accumulate.
Upgrade after each release
Smaller changes each time, and it demands stronger governance and better test coverage.
Both are legitimate. Which one fits depends on your capacity and your appetite for change, and somebody should make that choice deliberately rather than by default.
We confirm your position against the current official release calendar as part of the health baseline, because this schedule moves and a plan built on last year's rhythm is a security exposure rather than a scheduling problem.
Proving the platform still earns its cost
Every platform gets a renewal conversation. Most of them happen without evidence.
What we do is make the platform's value visible again, with a baseline and a review rhythm, so the renewal conversation runs on evidence from your own instance rather than on a percentage somebody invented.
Demand
Delivery
Health
Upgrade readiness
Adoption
Value
Governance
We will say which.
A high emergency change rate, for example, is a governance signal rather than a capacity problem, and knowing that changes what you do about it.
One thing we will not do is count the same benefit twice, or treat time saved as money saved. If the platform frees up time, that is a real operational fact. Whether it becomes money depends on whether cost comes out or the capacity gets used for something valuable.
This is how most of these conversations start.
An implementation partner has finished, or a contract has ended, and somebody has to pick the platform up. The order is the point.
- 01
Find out what is actually there
What is installed, licensed, configured, customized, integrated, and paid for and unused. We review the installed state against what was actually purchased before activating anything further.
- 02
Sort out access
Which accounts, which roles, which environments, and who holds administrative rights nobody has reviewed. Permissions decay faster than almost anything else without ownership. We design entity-level filtering, access control lists and role management across multiple business entities, with group integration.
- 03
Establish the intake route
So new demand stops arriving chaotically while we are still working out what we inherited.
- 04
Baseline the health
And confirm where you sit against the supported release window.
- 05
Name the decision rights
Before the first disagreement rather than after it.
- 06
Then start on the debt
Stabilize before improving.
- 07
Establish platform governance
Set up a process to continuously improve the platform.
A transition is where a new provider usually discovers the platform is in worse shape than the customer believed. We will tell you what we find.
That conversation is uncomfortable once and useful permanently.
Building your capability, not your dependence.
The measure of good ownership support is that you could take it back.
That is an odd thing for a recurring service to publish, and we mean it practically rather than sentimentally. A managed service that leaves you unable to make your own platform decisions has not reduced your risk, it has moved it.
So: we work jointly rather than as a black box. Documentation gets maintained as the work happens, not written up at the end. And we name the things you should own internally, and help your people own them.
Not because a contract forces it, but because a platform you cannot administer without us was never really yours.
Being clear about the boundary saves everyone a wasted conversation.
Not bounded application support
If you need a defined scope kept working and fixed when it breaks, that is Solution Support, and it is a better fit and probably cheaper.
Not designing your operating model
If you do not yet know who should own the platform, the roles, the decision rights or whether you need a Center of Excellence, start with Operating Model Design. Platform Governance is the operating part of the answer.
→ Operating Model Design
Not AI governance
Governing the AI running on your platform is Governance as a Service, with AI Control Tower as the tooling.
Not a capacity contract
We are not selling you a number of hours or a response time table. If a published service level is the thing you are being asked to compare, we may not be the right answer, and we would rather say so now.
Decisions, not status reports.
A named owner
One person accountable, who knows your platform and stays with it.
An agreed cadence
A regular review that covers health, demand, upgrade position and value, and produces decisions rather than a status report.
A maintained backlog
Visible to you, prioritized on a basis you can challenge.
Reporting you can act on
We use AI in our own delivery, including automatically generated delivery updates and meeting capture that separates decisions from updates from problems. The value is coverage and consistency: fewer things quietly falling out of the record, and senior time spent on judgment rather than on reconstructing what happened.
The specifics of scope, cadence and commercial shape are set per client, and agreed with you rather than published as a table that fits nobody.
Somebody answerable for the state of the platform.
Accountable, not just available
Most platform services sell response time. We sell somebody answerable for the state of the platform.
You keep control
The decision rights split is published, and you can overrule us.
Independent advice
Our contracts oblige us to document the recommended system of record and integration boundary for each material capability, including where an existing system or another supplier's product is the better answer for you. On an ongoing service, where the easy money is in saying yes to everything, that clause matters more than usual.
Senior people, close to the platform
The people who look after your platform are experienced practitioners with 18+ and 20+ years in platform, process and delivery work, not a first-line queue. On a recurring service, the person who knows why your platform works the way it does has to still be there in month fourteen.
We agree the commitments rather than publishing them
Service levels, coverage and measures are set around your scope, your risk and your operating rhythm, then written into the contract. A published table is a number. An agreed one is a commitment.
Find out what state your platform is actually in.
Bring us a platform you inherited, or one nobody quite owns. We will tell you what we find, what we would do first, and whether you need us at all.
Platform governance
A clear process for keeping your platform aligned with continuous best practice.
Platform owner
The person accountable for the platform as a product: its roadmap, standards, health and cost.
Instance
Your own copy of the platform.
Technical debt
Work deferred or done the quick way, which will cost more to fix later.
Differs from baseline
A record that no longer matches what the vendor shipped, whether or not it was deliberately changed.
Upgradeability
How ready the platform is to take the next vendor release without breaking.
Release family
A vendor version and its patches. ServiceNow supports the current one and the one before it.
Hypercare
Intensive support for a defined period straight after go-live.
Decision rights
Who is allowed to make which decision, agreed in advance.
Access control list
The rules controlling who can see and do what.
System of record
The one system that holds the master version of a specific piece of data.
The questions buyers ask us.
What is ServiceNow platform management?
›
Looking after a live ServiceNow platform so it stays coherent, healthy and worth what it costs. In practice that means someone is accountable for the decisions, there is one route for new demand, technical debt and upgrade readiness are worked on deliberately rather than in emergencies, and somebody can tell you whether the platform is still delivering what it was bought for. It is different from support, which keeps an agreed scope working when something breaks.
How is this different from ServiceNow support?
›
Support answers when something is wrong. Ownership is answerable for the state of the platform. A platform can be well supported and still drifting: undocumented customizations accumulating, two releases behind, licenses paid for and unused, and a backlog nobody has prioritized. If what you need is a defined scope kept working, Solution Support is the better and probably cheaper answer, and we will tell you that.
Do we lose control of our own platform?
›
No, and we publish the split so you can check. You decide what the business needs, what gets funded and in what order, who may access what, whether to upgrade and when, and whether to accept a risk. We decide whether a change is architecturally sound and whether something should be configured or customized, and we put that in writing with the reasoning. You can overrule us, and we record that too.
What happens if we disagree with your recommendation?
›
You decide. We write down what we recommended, what you chose, and what we think the consequence will be. That is not a way of scoring points later, it is how a decision record stays useful when somebody asks in eighteen months why the platform works the way it does.
Can you take over a platform another partner built?
›
That is the most common way this starts. How a takeover works is covered on Implementation.
How often do we have to upgrade ServiceNow?
›
ServiceNow releases two major versions a year and supports the current release family and the one before it, so in practice you need to upgrade at least once a year to stay entitled to patches and hotfixes. In 2026 the release schedule and the supported-version deadline both moved, so if your planning was built around the old rhythm your window is tighter than it was. There is a genuine choice between upgrading annually, which is less disruptive but lets debt build, and upgrading after each release, which means smaller changes but needs stronger governance and better test coverage.
How do you measure whether the platform is delivering value?
›
We baseline at the start and review on a cadence: open demand and its age, changes released and how many were emergencies, open critical health findings and their trend, how many releases behind you are, active users against licensed users, and whatever the original business case said would improve. These are baselines and review measures rather than promised outcomes, and they come from your own instance. We also do not count time saved as money saved unless you can say what happens to the released capacity, because that is the assumption most platform business cases quietly get wrong.
What are your service levels and coverage hours?
›
Response times and coverage hours are agreed in your service description. How they work across our ongoing services is set out on Managed Services.