SERVICENOW PARTNER · SALESFORCE PARTNER
OBLYTECH — SYSTEMS OF RECORD, MADE OPERABLE
The situations that bring a buyer into a ServiceNow conversation usually look the same. The platform is already running, several teams depend on it, and a growing list of things it does badly sits on someone’s desk: approvals that stall between two groups, incident queues where nobody holds the next action, a configuration database that nobody trusts enough to base a change decision on, or an executive request to add AI to the service desk before anyone has agreed what that AI may decide. The useful starting point is which of those problems costs the most right now, not a catalog of modules.
Three buyer groups tend to get the most out of a conversation like this. The first is an IT operations or service management leader who owns the platform and is accountable for its results but did not design the original build. The second is a transformation or digital lead who has been given a target, such as a new automation program, and needs someone to say what the platform can carry today and what it cannot yet. The third is a partner or internal engineering lead who needs extra delivery capacity for a defined stream of work and wants to know how that capacity will be governed. Each group asks a different first question, so each is better served by a different route.
| Buyer situation | The first question usually asked | Where to start |
|---|---|---|
| Platform in use, results uneven, cause unclear | Is the problem configuration, data, ownership or process design? | A readiness review of the platform |
| Data behind decisions cannot be trusted | Which records matter, who owns them, and what should be fixed first? | Configuration, service mapping and asset work |
| Automation or AI requested for a live process | What may the automation decide, and who approves the exceptions? | A governed strategy for enterprise AI |
| Extra delivery capacity needed for a defined stream | How is the team governed, and who is accountable for outcomes? | Dedicated ServiceNow delivery teams |
A useful first conversation starts with the stall rather than the wish list. Ask where a request waits longest, which group is waiting, and what the platform’s own records say about that wait compared with what people believe is happening. In most mature platforms the gap between those two pictures is the finding. A workflow that looks slow is often waiting on an approval step with no named approver, on a field that three teams fill in three different ways, or on an integration that fails quietly and leaves a record half updated.
From there, an early review usually works through four questions in order. What is the process supposed to do, and what does it actually do today? Which records and fields does the process depend on, and are they populated consistently? Who owns each step, and what happens when that person is away? Which other systems send information into this process or receive from it, and how are their failures made visible? The answers rarely map onto a single product module, which is why a sound review is framed around the process and not around a feature list.
A useful early review ends in a short set of decisions rather than a long report: a ranked list of what to change first, what to leave alone for now, and what needs a decision from someone with authority before any build begins. Those decisions become the basis for scope. Where the work moves into build, the ServiceNow implementation route covers that stage. Scope, duration, staffing and price are agreed for each engagement after a technical conversation about the real environment, so nothing on this page should be read as a fixed package with a published fee.
The most useful preparation is modest. Gather the names of the people who own the process under discussion, a rough description of the volume and of the places where work waits, and any recent change or incident history for that area. Teams that arrive with a complete data dictionary are uncommon, and a missing dictionary does not stop a review; it simply becomes one of the findings, with an owner and a date attached to it.
Automation and AI work on a ServiceNow platform inherits every weakness the platform already has. An agent that drafts a change, routes a request or summarizes an incident can only be as reliable as the records, approvals and ownership it reads from. That is why governance belongs in the design rather than in a review added at the end. For a live process the questions are concrete: what the automation may read, what it may write, which decisions it may make alone, which it must hand to a person, and how a bad output is noticed and reversed.
This site describes how the company runs its own AI delivery internally: human approval for anything consequential, full audit trails, and independent verification before a result is trusted. Those are the controls a buyer should ask to see working inside a real process, not only drawn on a slide. A diagram shows intent; a sample of the audit record shows whether the control actually happens.
Some requests are better served by sequencing than by immediate automation. If the configuration data behind a process is unreliable, the sensible first step is usually ownership and cleanup, followed by a narrow automation on the cleaned subset. Three practical rules tend to separate automation that reaches production from automation that stalls at the approval stage:
Open-ended requests for an assistant that will handle everything tend to produce long discussions and little release. A bounded job with clear controls is easier to approve, easier to test and easier to stop if it misbehaves.
Credentials and claims on a services website are a starting point, not evidence of how the work is done. The strongest material a buyer can request is specific and checkable. Ask for a description of a past piece of work: the problem as it was presented, the constraint that shaped the approach, what was changed, and how the change was verified afterwards. If confidentiality prevents naming the client, the description can be made anonymous, but it should still be concrete enough to test.
Ask who will do the work, and whether the people in the first call are the people who will deliver it. Ask for a sample of the working documents a review produces, such as a findings register, a dependency map or a remediation sequence, and read whether the sample says something concrete about a real platform or only lists generic topics. The about page is the place to start checking the organization’s background and how it describes its own practice.
Partner statements can also be checked against the platform vendor’s own partner records. A tier or certification shown on a website should be confirmed there, and a buyer should not assume that a directory listing means a particular skill has been validated for the kind of work being bought.
A direct enterprise buyer is usually accountable for an outcome: a service level, an audit position or a program date. A partner that needs delivery capacity is usually accountable for a deliverable inside someone else’s program and governance. The same engagement can look quite different depending on which side of that line the buyer sits, so the questions to raise differ as well.
| Area | Direct enterprise buyer | Partner seeking delivery capacity |
|---|---|---|
| Accountability | Who signs off the outcome internally | Who owns the backlog and the acceptance criteria |
| Team continuity | Named lead and how a handover is managed | Named people, skill checks and replacement rules |
| Access and confidentiality | What data the team sees and where it is held | Whose tenant is used and what the end client sees |
| Commercial basis | Scope agreed per engagement with price drivers explained | Capacity commitment, rate basis and change control |
The dedicated team route and the offshore delivery governance page are separate pages, and either works best when the buyer has a named internal owner. A team without one often keeps working only until the first disputed priority. The offshore delivery governance and accountability page pairs delivery ownership with client accountability.
The period after a review is where most plans either become real or quietly fail, so it deserves the same care as the review itself. Once priorities are agreed, the first weeks usually go to confirming the findings against the live platform, because a finding written from documentation alone is often wrong about one detail that matters. Owners named in the review should confirm they accept the responsibility, and any change that needs a release window or a security review should be scheduled before anyone starts building it.
From that point the work tends to fall into three kinds. Some fixes are configuration changes that can go through the normal change path quickly. Some are data corrections that need an owner to decide which value is right. Some are redesigns that should be treated as a small project in their own right, with their own acceptance test. Mixing the three in one plan is a common reason for slow progress, because the owners and the approval routes are different for each.
A sensible handover at the end of an engagement records what changed, who owns each part of the process now, which tests were run and which were not, and what the buyer should watch for in the first cycle after release. A handover without those items leaves the buyer to rediscover the same problems later.
Not necessarily. A review can begin with the processes causing the most trouble and work outward from there. What it needs is a reliable answer for the records those processes depend on. Gaps elsewhere become a prioritized cleanup list rather than a reason to stop. The configuration, service mapping and asset route focuses a first release on the classes, services, assets and decisions that matter most, rather than on every record at once.
Narrow automation on a clean subset is often possible. Broad automation over unreliable records usually is not a good idea. The safer order is to fix ownership and the fields the automation reads, run it on a small set of cases with known correct answers, and then widen its scope in stages.
Price is set per engagement rather than from a published list. Common drivers are the number of processes and modules in scope, the state of the data and integrations, the access the team is given, and whether the work is configuration, build or redesign. The technical conversation is the point at which those drivers become a concrete estimate.
Distributed delivery is common, and the practical question is overlap rather than geography. Ask which hours the team covers, how urgent incidents are handled outside those hours, and who makes decisions when the buyer’s own owner is unavailable. Those answers matter more to day-to-day delivery than where the people sit.
If the platform is running and a specific process is not behaving the way the business expects, the most useful first step is a short technical conversation about that process. Have the name of the owner, the rough volume and the place where work waits ready. From that conversation the right route is usually clear: a readiness review, a data ownership piece, a governed automation design or a delivery arrangement. You can discuss your platform assessment with the team; scope, staffing and price begin to take shape in that technical conversation.