ServiceNow is a dynamic platform that’s constantly evolving, with new features, functionalities, and best practices emerging regularly. To ensure your ServiceNow instance remains optimized, efficient, and aligned with your business goals, a commitment to continuous improvement is essential. Oblytech’s Continuous Improvement services provide expert guidance and support to help you proactively identify areas for enhancement, implement best practices, and achieve ongoing success with ServiceNow.
Continuous improvement is a phrase commonly attached to support contracts, and it can give sponsors very little to hold a supplier to. A sponsor who approves an improvement budget without defining its outputs usually discovers, a year later, that a steady stream of small changes has been made and that nobody can say whether the platform is better used. The useful way to frame the work is as a cycle with visible products at each stage: a short list of observed problems, a decision about which ones justify change, a set of changes released in a known window, and a measure that shows whether each change did what it was meant to do. If any of those products is missing, the improvement is activity rather than progress.
The cycle also needs a stopping rule. Some improvements are worth making only once. Others need to be re-examined each quarter, because the business process they support keeps moving. A retirement step, where an improvement is removed because the need has passed, belongs in the cycle as much as the addition of new capability. Platforms that only ever grow become expensive to change, and the cost is felt most by the people who must maintain them.
Improvement decisions are only as good as the evidence behind them, and no single source is complete. Platform records show what users did. Surveys and feedback show what users felt. Support data shows where they got stuck. Each source has a characteristic blind spot, and the cycle works best when the blind spots are known in advance.
| Source | What it reveals well | Where it misleads |
|---|---|---|
| Platform usage and transaction records | Which paths are used, how long steps take and where records stall | It cannot show work that happens outside the platform, such as side conversations |
| Reopened and reassigned records | Where ownership or resolution is unclear | A reassignment can be correct when the first owner was wrong about the category |
| Short user feedback at the point of use | Friction that users notice immediately | Users rarely report the problems they have already learned to avoid |
| Service desk conversations | Recurring questions that the platform should answer without help | Agents may answer the same question differently, which blurs the signal |
| Interviews with process owners | The reason a step exists and what would break without it | Owners often describe the process as designed rather than as performed |
A practical habit is to test each suspected improvement against two sources before it enters the backlog. If the platform data and the service desk conversations point in the same direction, the case is usually strong. If they disagree, the disagreement is itself a finding, and it is often a sign that a process is being performed differently in different teams.
A continuous improvement backlog fills quickly, and most of what goes into it will look worthwhile. Prioritization needs a small set of criteria that the sponsor and the platform owner accept in advance. Useful criteria include how many people the problem touches, how often it occurs, whether it creates risk to records or compliance, how much effort the change requires, and whether the change makes a later change easier or harder. A change that removes a common source of rework can be more valuable than a visible feature, and the criteria should make that visible.
The discipline lies in recording why an item was rejected as well as why one was accepted. A declined request that comes back six months later is easier to handle when the earlier reasoning is on file, and it prevents the same argument being repeated with different people in the room.
An improvement backlog fails in one of two ways. It either becomes a dumping ground that no one reviews, or it becomes a queue that only the platform owner can move. A governance rhythm avoids both. A short standing review, with the sponsor or a delegate, the platform owner and one representative from the largest user group, meets on a fixed cadence. Decisions are recorded, owners are named and anything not decided within a set period is escalated rather than left to age. The review should be short enough that busy people will attend, and it should have authority to say no as well as yes.
Release timing is part of governance. Changes should be grouped into predictable windows so that testers, trainers and the business can plan around them. Frequent small releases feel responsive, but they tire users and make it difficult to tell which change caused a new problem.
Users stop noticing improvements when the communication about them is poor. A release that quietly improves a form may be valuable, but if no one tells the people who use the form, the benefit is lost and the next change is treated with suspicion. A short note for each release, written in terms of the task the user performs rather than the feature that was built, works better than a long list of technical changes. Where a change alters a familiar step, a brief walkthrough or a pinned example helps users find the new route.
The same principle applies to feedback. Asking for input and never showing what happened to it teaches users that feedback is pointless. A simple practice is to publish, after each review, the requests that were accepted, the ones declined and the reason for each. That record also reduces the number of repeated requests that arrive from people who had not seen the earlier decision.
Continuous improvement works best on the existing shape of the platform. When a request would add a new process, a new module or a substantial change to how a team is organized, it is a project, with its own business case, funding and delivery approach. Treating such requests as improvements hides their cost and leaves the sponsor unable to judge whether the budget is being used well. The boundary should be agreed early, with a test that the review can apply: if the change alters who does the work, what data the work depends on, or which decisions the platform supports, it probably needs project treatment.
The cadence should match the rate at which requests arrive. A review that meets more often than requests come in will spend its time on repetition. A cadence that is too slow lets urgent items age. Many teams settle on a rhythm that lines up with the release windows, so that each decision has a visible route into delivery.
The sponsor or a delegate with budget authority, the platform owner and a representative of the largest user group are the minimum. Including someone who runs the service desk is useful, because they see the recurring questions first.
Yes, provided the budget is sized for the kind of work it covers. Small, well-scoped changes can be absorbed in a standing allocation. Anything that needs new design, new data or new people should be reviewed separately.
Success is a measurable change in something the business cares about, such as the time a common request takes, the share of requests handled without escalation or the number of repeat contacts about the same task. Counting completed changes alone tells the sponsor how busy the team was, not whether the platform improved.
If the current support arrangement produces a steady flow of changes without clear results, the sensible move is to agree the evidence sources, the prioritization criteria and the review cadence. Discuss how a continuous improvement cycle would be governed to agree those terms before the next budget period starts. The support and maintenance overview is the wider support page, and the roadmap prioritization page is the related pointer for sequencing larger decisions. For the reporting side, the guide to dashboards explains what a ServiceNow dashboard is.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.