Get more from the Now Platform with Oblytech’s expert ServiceNow consulting services. We go beyond implementation, providing strategic guidance and practical changes to optimize your IT operations, streamline processes, and speed up your digital transformation.
ServiceNow consulting is the right purchase when the platform is running, people depend on it, and the open question is what to change, in what order, and whether the current setup still earns its keep. It is not the right purchase when the requirement is a new workflow that has not been designed yet, which is an implementation question, or when the instance needs someone to keep it running every day, which is a support question. Most buyers who search for consulting already know something is wrong or stalled. The job of this page is to help you name the problem in front of you and pick the one consulting route that answers it, before you commit budget to a broad engagement that tries to answer everything at once.
Each of the five consulting routes produces a different kind of output and assumes a different starting point. The table below pairs the symptom you are likely seeing with the route that addresses it. Read the last column as carefully as the others, because it tells you what you will still need after the engagement ends.
| What you are seeing | Consulting route | What you should receive | What it will not do for you |
|---|---|---|---|
| Leadership asks what ServiceNow should do next and gets a different answer from each department | Strategic IT roadmap development | A sequenced set of decisions, the owner for each, and the dependencies that set the order | Build the items on the roadmap |
| Automation has been requested for many processes and nobody can say which one pays back first | Process optimization and automation | Process maps, a shortlist of candidates, and a view of where a workflow change would move work | Redesign the process for the people who run it without their input |
| The instance feels slow, and every upgrade conversation ends with a list of reasons to wait | Performance tuning and upgrades | Findings on performance hot spots, an upgrade path with its blockers named, and a monitoring view | Remove customizations that the business still relies on |
| The platform has grown unevenly, and the team no longer trusts the data or the configuration | ServiceNow health checks and audits | A written report of findings with recommendations for optimization, security and performance | Clean up the data itself |
| A change is coming that will reach users, such as an upgrade, a new module or a reorganization | Change management advisory | An impact view, a communication and training plan, and a way to measure whether people adopt the change | Operate the change board or approve changes on your behalf |
If you recognize two or more rows, do not buy all of them at once. Pick the one whose output unblocks the others. In many organizations that is either the health check, when the team does not know the current state well enough to decide anything, or the roadmap, when the current state is understood but the choices are not.
The three service families are often blurred in buyer conversations, and the blur causes real trouble. An implementation builds a defined scope against a set of requirements and ends at release. Managed support keeps the platform running against an agreed service level and ends when the contract does. Consulting sits upstream of both. Its work is to answer what should be built, changed or retired, why, and in what order, and to leave the buyer with decisions and artifacts that someone inside the organization can act on.
That last point is where most consulting disappoints. A well-run consulting engagement ends with a document that has named owners, dated decisions and a list of open items, and the sponsor knows who will carry each item forward. A poor one ends with a deck that describes the platform in general terms and recommends a long list of things that nobody has been asked to own. Before you engage any provider, ask who will carry the output after the final session. If the answer is nobody, the engagement is likely to produce a report and little else.
Consulting also differs from implementation in what it is allowed to change. An implementation team configures the instance inside the scope it was given. A consulting team usually reads widely, interviews people, reviews configuration and reports, and recommends changes that the buyer then decides whether to make. That separation is useful, but it means the buyer must have the internal capacity to act on what the consultants find. Without it, the findings sit unused.
Consulting routes depend on each other more than their names suggest. The sequence below reflects the dependencies that show up most often. It is a starting pattern, not a fixed program, and the right order for your organization may differ once you know the instance.
Some organizations skip the health check because they believe they already know their platform. That belief is worth testing. A team that knows its platform well can usually explain the modules it uses, but it is less often able to explain why a particular business rule exists, which integration owns a given table, or how many scheduled jobs run in a normal working day. Those gaps are what consulting work tends to expose.
Consulting work is shaped by access and by people. Before a provider can give a useful view, the buyer usually needs to make a few things available. The exact list depends on the route and on the instance, but the following items recur across almost every engagement.
Buyers often ask for a fixed price before the scope is understood, and a fixed price given without a technical conversation can hide a risk the buyer later pays for. The effort is settled in that conversation, not in a sales call. What follows are the drivers that move effort up or down, so that you can judge a proposal when it arrives.
| Driver | Why it changes effort | What to ask the provider |
|---|---|---|
| Number of modules and applications in use | Each one has its own configuration, data and users to examine | Which modules are in scope, and which are only mentioned |
| Amount of customization | Custom code and altered base configuration take longer to review and carry more upgrade risk | How customizations will be identified and grouped |
| Number and type of integrations | Each connection needs its data flow, error handling and ownership checked | Whether integrations are reviewed from the platform side only, or with the other system’s owner |
| Data quality | Poor data slows every analysis and can turn a short review into a remediation project | Whether data remediation is included or scoped separately |
| Number of decision makers | More stakeholders means more readouts and more rounds of agreement | How many sessions are assumed, and who attends them |
| Access restrictions | Limited access means some areas can only be inferred, which changes the confidence of the findings | Which findings would be affected if access is limited |
The answer should name a role inside your organization, not only the sponsor. If the output will sit with a platform owner, a service manager or a governance forum, make sure that person has been part of the work, because a report that its eventual owner did not help shape is rarely acted on.
A useful consulting team states the finding plainly and explains the cost of leaving it. A weak one softens the finding until nobody can act on it. Ask for an example of how a difficult finding was written up, with the identifying details removed.
A provider should be able to list the areas it will read, the areas it will not change, and the reasons for each. If the list is vague, the scope is probably vague too.
Sometimes they can, and sometimes the recommendations need a build partner. The honest answer depends on the skills already present in your team, and a provider that says so is more useful than one that promises ownership transfer without describing how it would happen.
The fastest route to the right engagement is a short description of the problem, written in the words of the people who live with it. Include the modules you use, the one or two things that worry you most, and the decision you need to make in the next few months. That description gives a first conversation with any provider something concrete to work from, and it is where scope, access and the choice of route are normally settled.
Our ServiceNow consulting services are designed to give your business efficient, agile, and scalable IT solutions. Whether you’re just starting your ServiceNow journey or looking to optimize your existing platform, our experts are here to help.
ServiceNow advisory services are paid assessment and recommendation work on a platform you already own. An adviser reviews your instance, your processes and your plans, then tells you what to change, retire or leave alone, and in what order. The deliverable is a set of decisions, not configured functionality.
The words advisory, consulting and assessment overlap in practice, and providers use them differently. Judge an offer by its outputs rather than its label. An engagement that ends with configuration changes in your instance has moved into implementation, and one that only describes the platform has not advised anyone.
A typical advisory engagement runs in a recognisable order.
Judge a proposal by how it treats uncertainty. A credible adviser says which findings rest on evidence from the instance and which rest on what people reported, and states which areas were not examined. Gaps that are named can be managed. Gaps that are hidden turn into surprises during the next upgrade.
If you already know the problem, go straight to the matching route, such as a ServiceNow health check and audit or a strategic IT roadmap. If you are unsure whether to buy advice or ongoing help, the consulting versus managed support decision sets out how to choose.
In practice the terms overlap. Advisory usually means assessment and recommendation without building, while consulting can include guided changes. Ask any provider to list the outputs and say whether your instance will be changed, because the label alone does not tell you.
It should state the question asked, the evidence reviewed, each finding with its risk and effort, and the recommendations in order, with a named owner or a deferral for each. It should also list what was not examined, so nobody assumes silence means the area is healthy.
Yes, and a narrow scope is often better. A focused review of one module, such as incident or the CMDB, gives clearer findings than a broad review of everything. Pick the module where the problem is causing the most visible cost.
A health check suits the moment when no one on the team can describe the platform’s present condition with real certainty. Its output narrows the field: it shows which later questions deserve attention. Once that picture exists, planning the next two or three investments in a fixed sequence becomes the sensible follow-up.
Heavier customization makes a review slower, because every altered base setting and custom code path must be read and judged. It also raises the risk attached to each upgrade. Teams often feel the effect most in the speed of the platform, so providers should state how they will locate and cluster those changes before pricing the work.
Whether remediation sits inside the price depends on the proposal, so put the question to the provider in writing. Weak underlying data stretches every stage of analysis and may convert a brief assessment into a cleanup effort of its own. Score that exposure alongside the other cost drivers.
The sponsor is the person who must be there. Someone with authority over the findings should join the readout rather than only the opening meeting. In that working session, every recommendation leaves with a named owner or a recorded decision to postpone it, so those who can hand out ownership should attend.
Begin with a brief account of the difficulty, phrased the way the staff who deal with it every day would phrase it. List the modules involved, the one or two concerns that keep people up, and the choice that has to be made within the coming months. With that in hand, a provider can start shaping scope, access and the right route.
Usually not on its own. A partner that configured the instance is reviewing work it produced, which makes it harder to say that a design choice was wrong. An independent advisory review is more useful when the question is whether the platform should change, not whether it was built to specification. Buyers typically keep the original partner for delivery and bring in a separate adviser for the review, and the arrangement works best when each party knows its role from the start.
The conflict is rarely deliberate. It shows up in small ways: a finding about a customization gets described as a tuning task, a data problem gets put down to users, or an integration issue is left out because it sits in another team’s scope. Ask the reviewer how they will handle a finding that points at work their own firm delivered. A direct answer is a good sign.
A shared review is acceptable when three conditions hold:
Keep the original partner in the room for the readout. They can correct facts about how a component was meant to behave, which helps avoid findings built on a misreading. What they should not do is decide which findings are accepted.
If you cannot find a reviewer who is independent of both the original build and the ongoing support contract, a self-run review with a written list of questions is still better than none. Write down the decisions the review must support, the modules in scope and the date the sponsor will decide. Then check the output against that list rather than against a general sense of platform health. For the data side of the review, read how CMDB hurdles tend to surface in a review. To judge whether test evidence can be trusted, see how business-owned validation works after a build. A reviewer checking delivery quality can also compare findings against the common implementation pitfalls that cause rework.
A sound ServiceNow advisory proposal names the decision your findings will feed, the evidence the adviser will read, and the person who owns each recommendation afterwards. If a proposal describes activities but never names a decision, it may be selling time rather than advice.
Proposals for advisory work tend to look alike, so the differences sit in a few specific places. Check each one against the table before you compare prices.
| Check | A good sign | A warning sign |
|---|---|---|
| The question | One or two questions written in your own words, such as whether to keep a heavily customised module | A general promise to assess the platform |
| The evidence | A list of what will be read: configuration, reports, integrations, interviews | A workshop with no stated inputs |
| The output | Ranked recommendations, each with an owner, a dependency and a cost of waiting | A slide deck of observations |
| Independence | The adviser states what they would gain if you chose a particular option | Every finding ends in a build project from the same firm |
| Limits | Areas that could not be inspected are marked as lower confidence | Every finding is stated with the same certainty |
The independence row matters most when the same firm advises and builds. That arrangement is not wrong, and it can save a handover, but you should ask for the recommendations in a form that another provider or your own team could act on without further explanation.
Advisory work answers questions that reading and interviews can answer. It typically cannot prove a redesigned process will be adopted, and it does not repair data.
If the main doubt is the condition of the instance, a ServiceNow health check and assessment is the narrower starting point. If the doubt is direction, the platform strategy and roadmap route fits better, and the guide to roadmap prioritisation shows how competing requests are ranked.