01
IT consulting
Clarify the technology direction and operating need.
Explore this route →
Many buyers arrive at a services page with a problem stated in operational terms: approvals take too long, a platform is not doing what the business expected, a project has stalled, or a support queue keeps growing. The difficulty is that the same problem can call for advice, for a build, for an ongoing service or for testing, and a provider that offers all four will be tempted to recommend whichever it sells most easily. The routes on this page exist to separate those choices. Each one answers a different question, and the first task is to decide which question is actually being asked.
A practical way to start is to write down what has to be different after the work is finished. If the answer is a decision that is not yet made, the route is advisory. If the answer is a system that does not yet exist, the route is delivery. If the answer is a service that must keep running with a known level of response, the route is operational. If the answer is confidence that a change will work before users see it, the route is assurance.
| What is missing today | Route to consider first | Typical output |
|---|---|---|
| A clear direction for technology spending | IT consulting | Options, a roadmap and an agreed set of decisions |
| Someone accountable for software that is already live | Managed IT services | An operating cadence, reporting and an escalation path |
| A working application for one defined need | Custom software development | A built and handed-over application with defined ownership |
| Evidence that a change works before release | Quality assurance and testing | A test approach, results and a defect picture |
| A ServiceNow platform that needs direction or repair | ServiceNow services | A readiness view, a delivery plan or a support arrangement |
Most of the platform work described across this site concerns ServiceNow, which the services page names as the primary platform focus. The ServiceNow routes cover consulting, implementation, optimization, support and a range of solution areas, including IT service management and CMDB data. The other routes on this page are described at the level of detail their own service pages support. Where a question is primarily about ServiceNow, the ServiceNow services overview is the better starting point than a general route.
The reason for the emphasis is practical. A ServiceNow engagement usually touches data, workflow and ownership in ways that a general IT project does not, so the questions a buyer must answer are more specific. Which records are authoritative? Who approves a change to a workflow? What happens when an integration fails at night? Those questions are easier to answer when the provider has worked through similar platform decisions before, which is a fair question to put to any provider.
The quality of the first conversation depends on how clearly the buyer can describe the situation. Four facts help most. The first is the operating question in plain words, such as why a routine request takes longer to close than the policy allows. The second is the people involved, including the business owner, the technical owner and whoever will live with the result. The third is what has already been tried and what it cost. The fourth is the constraint that matters most, which might be a deadline, a budget ceiling, a regulatory obligation or the availability of internal staff.
A buyer who cannot yet say these things is not disqualified. A short discovery can produce them, and the platform health and readiness page describes preparing for a platform review.
The routes are not a menu to be ordered once. A common sequence runs from advice to delivery to operation. An organization might begin with a strategy question, commission a build to answer it, test the result, and then move the running system into a managed service. Each step produces artifacts that the next step needs, such as a requirements record, a configuration baseline or a set of known defects. A buyer who plans that sequence at the start avoids paying twice for the same discovery.
The same logic applies in reverse. A managed service that keeps raising the same incident is a sign that a project or a consulting review may be needed, and a provider running that service should say so rather than continue to absorb the cost.
The route decision is easier when someone in the client organization owns it. In most organizations that is an executive who holds the budget for the affected function, supported by a technical lead who knows the estate. Involving a provider before that owner is named tends to produce proposals that are technically sound but cannot be approved, because nobody with authority has agreed what success looks like. A short internal note that names the owner, the decision and the deadline is often the single most useful thing a buyer can prepare before the first call.
This page does not set out the detailed scope, price or staffing for any route. Those depend on the systems involved, the access available and the decisions the client has already made, and they cannot be settled from a general page. The page also does not describe every specialist area, because specialist capacity is best scoped against a specific need rather than listed as a general promise. Where a route on this page is not the right fit, the discussion should say so, and point the buyer toward the route that is.
The right route depends on the question, not on company size. A small business with one critical system may need only managed support, while a larger one with an unclear direction may need consulting first. The fit is determined by the decision in front of the team.
Yes, and often they should be. A consulting decision may lead to a build, which then needs assurance testing and eventually an operating service. The risk is in running them without a shared record, so that each provider works from a different picture of the system.
No. Salesforce and SAP have their own routes on this site, each described at the depth its page supports. ServiceNow is the primary platform focus, not the only service area.
The operating question, the people affected, what has been tried and the constraint that matters most. Those four items let the first conversation move quickly to the right route.
The IT consulting overview is the usual starting point when the direction itself is open, and the managed IT services overview covers the case where something already runs and needs an owner. Talk to an expert about your delivery route once the owner, the decision and the deadline are written down.
A delivery route has failed when its output does not answer the question it was bought for. The common signs are a consulting report that nobody acts on, a build with no named owner after go-live, a managed service that closes tickets while the same requests keep arriving, and a test pass that does not match what users experience.
Start by reading the last deliverable against the original question. If the analysis is sound but no decision has been taken, the gap is ownership, and a second study will reproduce it. If the build works but people route around it, the requirement was probably written by the team that asked rather than the team that does the work, so reopen the requirement record before changing the build.
| Sign | Check first |
|---|---|
| Report agreed, no decision taken | Who owns the decision and by which date |
| Build live, nobody maintains it | Whether support and change approval were written into the handover |
| Same incident returns each month | The root cause record and whether the fix was ever scheduled |
| Tests pass, users find defects | Whether acceptance criteria came from the requirement or from the build |
On a ServiceNow platform, repeated incidents often trace back to who owns configuration. Ask who approves a change to a workflow, who is accountable for each configuration item, and who decides when a workaround becomes permanent. If nobody can answer those questions, start with the platform operating model and governance work before any further build. A structured review such as ServiceNow health checks and audits will show where the gaps sit.
Many failing routes can be corrected without starting over. The usual fixes are to name one owner, rewrite the one record that is wrong, or add a check at the point where the output is handed over. Where the same problem keeps returning, a review of open fixes and their owners is usually the quickest start, which is the work behind continuous improvement.
Keep a short record for every route: the question it was meant to answer, the measure agreed at the start, and the date that measure was last checked. Without that record, a buyer cannot tell whether a route failed or whether the question changed underneath it. Write it before the first provider call.