Editor's note for Suresh: this draft is written from general ServiceNow practice, not from your specific engagements. Add your own examples where they fit — a real anecdote from HPE or T-Mobile will do more than anything here. Delete this box before publishing.
Most free platform assessments are sales instruments. They are structured to surface a set of findings that map neatly onto the assessing firm's service catalogue, and they end with a proposal. That is not dishonest — a firm should show what it can do — but it is worth being clear about what you are receiving, because an assessment that exists to generate a proposal is optimised for a different outcome than one that exists to tell you the truth.
A useful assessment produces a document you own, that is worth having even if you never engage the firm that wrote it.
Seven things worth examining
1. Architecture and the data model
How deep is the CI class model, and how much of it is actually populated? Are custom applications properly scoped, or did they land in the global scope? Are the table extensions justified, or did somebody extend Task because it was the fastest route? These decisions are cheap on day one and expensive to unwind in year three.
2. Customization debt
How many platform records have been modified? How many skipped records did the last upgrade produce? Is there a pattern — the same team, the same era, the same shortcut — and is the pattern still occurring? A count on its own is not very informative. The trend, and whether anyone is watching it, is.
3. Upgrade posture
Which version, how far behind, when was the last upgrade, and how long did it take? What is the support status of the current release? This is the single best predictor of what platform work will cost over the following two years, and it is the question most assessments treat as a footnote.
4. Integration inventory and data authority
What connects to the platform, in which direction, and which system is authoritative for which data? Point-to-point integrations built ad hoc are individually reasonable and collectively immovable. The important finding is not the count — it is whether anyone can state, per attribute, where the truth lives.
5. Operational health
Long-running jobs, slow transactions, tables growing without a retention policy, indexes missing on frequently-queried custom fields. These accumulate silently and surface as "the platform is slow lately", which is a symptom with a dozen possible causes and no owner.
6. Adoption
Which modules are licensed against which are genuinely in use? Are people going through the portal or ringing the service desk anyway? Shelfware is a common and awkward finding, and it is often the one with the largest immediate financial consequence.
7. Governance and ownership
Who approves platform changes? Is there a defined promotion path? Who owns the data model? If the answer to any of these is "it depends" or a name that left the organization, that is a more consequential finding than most technical debt, because it determines whether anything else gets fixed.
What the output should look like
A findings document, written for a reader who is not in the platform team, containing:
- What is actually wrong, in plain terms, separated from what is merely non-standard. Not every deviation is a problem.
- Why each finding matters — the consequence if nothing changes, and roughly when it lands. "This will make your next upgrade significantly more expensive" is useful. "Does not follow best practice" is not.
- What it would take to fix, at a level of precision that supports a budget conversation.
- A prioritised sequence, because everything cannot be first, and the order usually matters more than the list.
- What is fine. An assessment that finds problems everywhere is either describing an unusually bad instance or padding. Saying plainly that something is in good shape is what makes the rest credible.
Questions worth asking before you accept one
- Do I keep the document regardless of what I do next? If the findings only arrive attached to a proposal, you are being sold to, not assessed.
- Will you tell me what not to do? A good assessment identifies work that is not worth doing. If nothing gets ruled out, nothing was really evaluated.
- Who performs it? The same question as any engagement — whether the person writing the findings is the person who will be accountable for acting on them.
- How long, and what access? A credible assessment needs read access to the instance and a handful of conversations. Anything that can be done from a questionnaire alone is a survey with a nicer cover.
On scoring frameworks. Numeric maturity scores are useful for tracking your own progress over time and nearly useless for comparing organizations, because the weighting encodes the assessor's opinion about what matters. Treat a score as a summary of the findings underneath it, never as a substitute for reading them.
How we run one
A bounded review with a fixed scope and a fixed price, producing a written findings document that belongs to the client whether or not any further work follows. We will say when something is in good shape, and we will say when remediation is not worth what it would cost. On instances where the honest finding is that the platform is being maintained competently and needs no outside help, that is what the document says.
Written by Suresh Ganapathy, founder of Tessivant.