When a ServiceNow program wraps, someone always asks what it was worth. The answer usually arrives as a slide: hours saved, tickets deflected, a headline ROI percentage. It looks precise, and it is almost always incomplete — because it counts only what the platform produced and quietly ignores what the platform costs to keep running. Worth is not a gross number. It is a net one.
The honest way to measure a ServiceNow investment is realized value minus total cost of ownership, and it is that second term that does the damage. A platform can look like a triumph at go-live and be worth measurably less every quarter after, as customization, technical debt, and performance drag accumulate into a carrying cost that never appeared on the original business case. This is not a fringe concern. Across the software industry, maintenance and support routinely consume the majority of a system’s lifecycle cost, and McKinsey has attributed roughly 40 percent of the typical IT balance sheet to technical debt. Those figures are not rounding errors, and on a ServiceNow platform they are entirely a function of how the platform was built.
This paper reframes value as a net figure, walks through the four cost lines that erode it, explains why Property & Casualty carriers tend to carry more of this cost than most organizations, and lays out a practical way to instrument worth both before and after go-live. The thesis is straightforward: you cannot know what a platform is worth until you are honest about what it costs to own — and once you are, most of the levers that raise its worth turn out to be architectural choices you already control.
Ask ten sponsors what their ServiceNow platform is worth and you will get ten ROI decks — and not one of them will show you the other side of the ledger. I have helped more than thirty organizations deploy or extend ServiceNow, and the value conversation follows a predictable script. Before go-live, worth is a projection: a business case built to secure funding. After go-live, worth becomes a story: a benefits slide assembled to justify the funding that was already spent. In both versions, the number is gross. What almost never appears is the cost of carrying the very thing that produced the value.
That omission matters because a ServiceNow platform is a long-lived asset, not a one-time purchase. Its value compounds over years — and so does its cost. A gross ROI figure can flatter a platform that is silently expensive to own, while understating one that was built with discipline and runs almost for free. If two carriers each report the same realized value but one spends three times as much keeping its platform alive, those two platforms are not equally valuable. They are not even close. The only figure that tells the truth is the net one.
So the question in the title deserves a more honest treatment than a benefits slide. Measuring what an implementation is actually worth means measuring what it returns after you subtract what it costs to keep running. Let me define that denominator, show the four places it hides, and then lay out how to put a real number on it.
Here is the equation I wish every steering committee kept on the wall: worth equals realized value minus total cost of ownership. Realized value is the part everyone already tracks — efficiency, deflection, cycle-time reduction, revenue enablement. Total cost of ownership is the part that gets waved away as ‘run cost’ and rarely gets attributed back to the design decisions that created it. That is the denominator nobody prices, and on a ServiceNow platform it shows up in four distinct places.
The first cost line is the most fundamental, and the most consistently underestimated: the platform costs money to run every day it is live. Industry research on software lifecycles has been remarkably stable on this point for decades. Gartner has reported that organizations spend somewhere in the range of 55 to 80 percent of their IT budgets simply maintaining existing systems, and the IEEE software-engineering literature has long placed maintenance at roughly 60 to 80 percent of total lifecycle cost. These are directional figures drawn from broad industry studies rather than from any single ServiceNow instance, but the direction is not in dispute: over the life of a system, the cost of keeping it running dwarfs the cost of building it. On a ServiceNow platform, that carrying cost is enhancement work, defect fixing, integration upkeep, and the regression testing you repeat on every release. It is real money, and it is recurring.
The second cost line is where architecture starts to matter, and it is the distinction I return to on nearly every engagement. Configuration — using the platform the way ServiceNow intended — is cheap to carry, because the vendor maintains it for you. Customization — writing code and reshaping the platform beyond its intended use — is expensive to carry, because you now own it forever. And technical debt is the interest you pay on customization you never actually needed. Each custom decision looks reasonable in isolation. Collectively they become a standing liability on the balance sheet. McKinsey has estimated that companies pay an additional 10 to 20 percent on top of project costs just to service technical debt, and that CIOs believe technical debt represents somewhere between 20 and 40 percent of the value of their entire technology estate before depreciation. Read that back as a worth statement: a meaningful share of what you think you own has already been mortgaged to the cost of maintaining it.
The third cost line is the one teams forget to count at all, because it does not arrive as an invoice. Poorly performing code is not merely slow — it is a recurring tax on infrastructure, on user time, and eventually on the stability of the instance itself. I have seen a single query against a 180,000-row table drop from nine seconds to under a millisecond after we added the right index; the same table, indexed poorly, had been quietly taxing every process that touched it. On another platform, a single missing setLimit call caused a job to read roughly 1.5 BILLION more rows than it needed, burning something on the order of seven hours of processing every single day. Nobody had budgeted for those hours, but the platform paid them anyway. Performance debt is carrying cost you feel continuously, and at scale it is the difference between a platform that hums and one that drops to its knees under its own weight.
The fourth cost line is the slowest to appear and the most consequential. Every customization pulls the instance a little further from the ServiceNow baseline, until each upgrade becomes a project of its own — re-testing, re-fixing, re-validating everything you bent out of shape. That is the upgrade tax, and it compounds. The more expensive part is what it forfeits. The entire premise of buying a platform is that the vendor innovates on your behalf; when your instance has drifted too far from baseline to absorb what ServiceNow ships next, you have quietly given that innovation away. The broader software economy shows the scale of the problem: CISQ, in its 2022 report sponsored by Synopsys, put the cost of poor software quality in the United States at an estimated $2.41 trillion and accumulated software technical debt at roughly $1.52 trillion. Those are economy-wide, directional numbers, but they name a real line item on your own platform — the value you can no longer capture because your instance can no longer keep up.
Every cost line above applies to any ServiceNow platform. Property & Casualty insurance concentrates all four. Carriers rarely run a single tidy process; they operate across personal and commercial lines, each with its own onboarding, renewal, servicing, and claims nuances. That breadth means more workflows, more integrations, and more surface area on which customization and drift can accumulate after launch. More surface area is more denominator.
Then there is the regulatory reality. P&C carriers operate under state-by-state oversight and tight expectations around documentation and traceability, which raises the cost of making any change safely. An undocumented customization in most industries is technical debt; in a regulated carrier it is also audit exposure — carrying cost with a compliance multiplier attached. This is precisely where two carriers with identical realized value can end up with radically different worth, depending on how their platforms were built.
ServiceNow gives carriers a strong out-of-the-box starting point. Financial Services Operations ships P&C servicing and claims processes and an insurance data model built for the industry. The expensive mistake is to treat that baseline as raw clay — reshaping it by editing business rules, flows, and script includes directly. That approach is cheap on the day you make the change and expensive for every year afterward. The disciplined path is to extend the baseline through scoped applications that add capability without ever touching the core. When Naitiv builds something like Personal Lines Customer Onboarding, a Bordereaux Workbench, or a Policy Renewal Workbench, it ships as a scoped application layered cleanly on top of Financial Services Operations — delivering workflow the carrier needs and that ServiceNow does not offer out of the box, while leaving the underlying platform fully upgradeable. Same value on the numerator; a far smaller denominator underneath it. That is not an aesthetic preference. It is the difference between a platform whose worth climbs for a decade and one that erodes quarter over quarter.
Measuring worth is not a single calculation you run at the end. It is a discipline you practice before and after go-live, and it rests on one uncomfortable premise: if you never priced the denominator, you were never measuring worth in the first place. Here is the practical part.
Worth is decided at design time, not at go-live. Every requirement should be evaluated not just on whether it can be built, but on what it will cost to carry once it is. A requirement met out of the box or with light configuration contributes high worth, because its denominator is close to zero — ServiceNow carries it for you. Solve the same requirement with customization and you have lowered its lifetime worth before a single user ever touches it. Make configuration-versus-customization an explicit, costed decision in your design reviews, and keep a willingness to answer a request with ‘not that way — but here is the out-of-the-box alternative.’ That single habit protects more worth than any post-launch optimization ever will.
You cannot manage what you refuse to watch. Three measurements track carrying cost directly, and none of them requires exotic tooling. First, the ratio of configuration to customization over time — the clearest early signal that discipline is slipping. Second, upgrade effort per release, measured in hours and regression defects; this is the most honest proxy for how far the instance has drifted from baseline, and it is a number you already generate whether you record it or not. Third, performance headroom — slow-transaction counts, long-running queries, and table-growth trends on your busiest tables. These are the vital signs of the denominator. Watch them and you can see worth eroding while there is still time to intervene; ignore them and you will only learn the number when someone proposes a costly re-platform.
Once you are tracking both sides, express worth as one figure: realized value minus the annualized cost of ownership — support, enhancement, upgrade effort, and the share of infrastructure and staff time attributable to customization. A rough, honestly-built net figure is far more useful than a precise gross one, because it is directionally true. It also changes the conversation with the business. A platform that returns a large gross value while consuming most of it in carrying cost is worth less than a leaner one that returns a little less but costs almost nothing to keep alive — and only a net figure will ever show you that. Resist the urge to dress this up with invented precision; a defensible range beats a fabricated point estimate every time.
Finally, a number nobody owns is a number nobody defends. The Technical Review board is the body that protects the denominator, enforcing the out-of-the-box-first discipline that keeps carrying cost low. The Executive Steering board should own the net figure itself, reviewing worth on a regular cadence rather than signing off once at go-live and moving on. As I argued in ‘The Go-Live Trap,’ launch is the day the real work begins; measuring worth is how you prove that work is paying off. Put a worth review on the quarterly calendar, and the platform stops being a project you finished and becomes an asset you actively manage.
The reason so many ServiceNow platforms are mismeasured is that the flattering number is also the easy one. Gross value is simple to assemble and satisfying to present. Net value requires you to admit what the platform costs to own — and to trace that cost back to the architectural choices that created it. But only the net number answers the question honestly. A platform that produced a great deal of value and costs nearly as much to carry is worth less than a disciplined one that produced somewhat less and costs almost nothing to keep alive, no matter which one has the better ROI slide.
So before you accept the next benefits deck, ask what it left out. What does this platform cost to run, to enhance, to upgrade, and to keep performant — and how much of that cost was designed in rather than forced on us? The worth of a ServiceNow implementation was never what it did the day you launched. It is what it keeps returning after you subtract the cost of keeping it alive. And the encouraging part is buried in that same equation: most of the denominator is within your control. Measure net, not gross — and architect the denominator down.
[1] Gartner. Research on IT spending allocated to maintaining existing systems (approximately 55–80 percent). Figures are directional and drawn from broad industry reporting. gartner.com
[2] IEEE Computer Society and related software-engineering literature. Maintenance estimated at roughly 60–80 percent of total software lifecycle cost; figures are long-standing and directional. computer.org
[3] McKinsey & Company. “Tech debt: Reclaiming tech equity.” October 2020. Technical debt estimated at ~40 percent of the IT balance sheet, a 10–20 percent ‘tech tax’ on project costs, and 20–40 percent of the value of the technology estate before depreciation. mckinsey.com
[4] Consortium for Information & Software Quality (CISQ), sponsored by Synopsys. “The Cost of Poor Software Quality in the US: A 2022 Report.” Cost of poor software quality estimated at ~$2.41 trillion and accumulated software technical debt at ~$1.52 trillion. Economy-wide, directional figures. it-cisq.org
[5] Pearson, C. ServiceNow Community, Developer Blog. Posts on query performance, indexing, and result-set limits (source of the performance war stories referenced in Section 2.3).
[6] Pearson, C. “The Go-Live Trap: Why Most Transformations Stall After Launch.” Naitiv, June 2026.
.svg){kind=icon}
