Not sure yet what to build?
Start with Discovery.
ServiceNow implementation
A ServiceNow implementation is judged twice: on go-live day, then at every family release after it. We build for the second test.
We use the standard platform wherever it already does the job and keep custom work in scoped applications. Every change is tracked, and every decision is written down with its reason. Where a process needs judgment on unstructured information, we bring in Anthropic Claude, inside a process ServiceNow already governs.
Already live and stable, and the question is how to run it?
Start with Managed Services.
Live and not working?
That is a re-implementation, and it starts here.
The problem
Where ServiceNow implementations actually break
Most ServiceNow implementations do not break at go-live. They break months later, when the first family release, the first new requirement or the first audit arrives. The causes repeat: customization, uncontrolled change, an IT model forced onto a business process, integrations nobody owns, a neglected data model, and no real handover.
01
Customized out of the upgrade path.
Out-of-the-box scripts and UI policies were modified instead of extended. Every family release now brings a list of skipped records that someone has to review by hand. So upgrades slip by one release, then two, and the capabilities you already license never reach your users.
02
Built in production.
Changes were made directly in production, or carried between instances in update sets nobody tracked. Development, test and production drifted apart, and nobody can say with confidence what is actually running.
03
The platform never left IT.
Customer Service Management or Sales CRM is licensed. Cases and orders still run through email and spreadsheets, because the build copied the IT incident model onto a customer process that works differently.
04
Integrations nobody owns.
Point-to-point scripted REST calls, credentials sitting in script includes, and no tests. They work until an upgrade on your side or an API change on the other, and then they fail without telling anyone.
05
A data model that was never respected.
Duplicate accounts, contacts nobody maintains, and an install base loaded once and never reconciled. Reports contradict each other, and Now Assist or any other AI has nothing trustworthy to reason over.
06
Go-live was the finish line.
The team that built the solution left the week after. Your team inherited something they had never operated, with the reasoning for every decision in the heads of people who are gone.
Every customization is a promise to maintain it at every upgrade.
Related: Customer Service Management, Sales CRM, Integrations, ServiceNow AI.
What implementation means for us
A capability your business runs, and can keep changing
Implementation is the discipline of making something exist and keeping it explainable. Three things have to be true when we finish.
It works against your real data.
With its duplicates and its history.
It survives the next upgrade.
Without a rescue project.
Your own team can run it.
Because every material decision has a recorded reason.
We build on two technologies, and the choice between them is a design decision.
ServiceNow
THE GOVERNED SYSTEM OF ACTION
It holds the process, the records, the permissions and the audit trail. When work has to happen the same way every time, be visible to a manager and survive a compliance question, it belongs on the platform.
Anthropic Claude
THE REASONING LAYER
When the bottleneck is judgment on unstructured information, such as reading a long customer email, drafting a response or researching a case, that needs a different kind of tool.
A capability nobody can explain is a capability nobody will change.
How we build
Clean core, clean code, and changes you can trace
We build ServiceNow implementations to stay upgradable and explainable. That means design before build, a clean core with custom logic in scoped applications, written coding standards with peer review, and every change tracked from development to test to production. We hold our Claude work to the same standard.
01
Design before build.
Design is a separate engagement with its own deliverables. We agree on a blueprint per capability and per interface before anyone configures anything, so the build has something to be measured against. A decision log records every design choice and its reason. A RAID log gives every risk, assumption, issue and dependency an owner and an impact.
02
Clean core.
We configure before we customize and extend before we modify. Out-of-the-box records stay untouched. Custom logic lives in scoped applications with clear boundaries to the global scope. Any deviation from the standard platform carries a reason and an owner in the decision log. The result is a short, explainable skipped-records list at upgrade time, and upgrades that stay routine.
03
Clean code.
Written coding standards and naming conventions, and peer review before anything is merged. No hard-coded sys_ids, no database queries inside loops, and no business logic hidden in client scripts. Server-side logic sits in script includes that can be tested. Comments explain why the code exists, not what it does.
04
Tracked changes, never edits in production.
Every change lives in an update set, and nothing is built directly in production. Update sets move from development to test to production in a fixed order, so every instance holds what it should, and anyone can see what changed and when.
Data, testing and go-live
Tested against real data before anyone depends on it
Most of the risk in a ServiceNow implementation sits in the data and the testing, not in the configuration. We run data migration as its own workstream and budget test effort per story and per interface, so the process is proven against the data it will meet before your people rely on it.
01
Data is its own workstream.
Migration is part of the build, not an afterthought. We map, cleanse and reconcile data, and run trial loads at real volumes before go-live.
02
Testing that is budgeted.
Test effort is estimated per story and per interface. Every integration endpoint gets three test cycles. User acceptance testing is run by your team, with our support. Acceptance means documented test evidence, reconciled data, and priority one and two defects resolved or formally accepted.
03
Go-live and hypercare.
Go-live is staged wherever your organization allows it. It is followed by a contracted hypercare period with a named team and a defect buffer.
Related: the ServiceNow hub carries the full method in detail.
Planning a build, or fixing one?
Either way, we start by reading the instance with you.
AI implementation
AI implementation, inside a process ServiceNow governs
Our AI implementation services put Anthropic Claude inside processes that ServiceNow already governs. We start new AI use cases as a bounded pilot, and we use the same pattern in our own delivery, with a person reviewing every step that matters.
- 01
Claude prepares the work
- 02
A person or a rule approves it
- 03
ServiceNow executes and records it
Human approval where it matters.
Instructions in a prompt are not a security boundary.
ON THE PLATFORM
Approval thresholds and exception paths.
ON AI WORK
An explicit approval step before anything writes to your instance.
IN PERMISSIONS
Platform permissions that limit what an AI integration account can touch.
Claude in how we build
We use Claude in our own ServiceNow delivery and on client engagements:
Data migration
It proposes field mappings from legacy systems with a confidence score, and a consultant reviews each one.
Knowledge-base migration
A migration pipeline extracts and curates articles, with human review before import.
Instance investigation
It reads a live instance’s tables, rules and permissions. It has no write path at all, so it is safe during discovery. READ-ONLY
Natural-language configuration
It turns plain-language requirements into ServiceNow configuration, with approval gates before anything is written. This one is in pilot on a client development instance. IN PILOT
We run on what we sell
ServiceNow is the backbone of our own commercial operations
The same clean-core rules, the same change control and the same upgrades apply to our own instance as to yours. When we tell you a customization will cost you at every release, it is because we pay that cost ourselves.
Sales CRM
Takes us from opportunity to order.
Strategic Portfolio Management
Takes us from project to portfolio.
Now Assist
On our own instance, so we know what ServiceNow’s own AI does well before we recommend it.
Claude
Supports our knowledge base, our documentation and the delivery skills described above.
The combination we build for clients is the combination we run on.
Ways we work
Same discipline, different shape
We implement in three shapes. The method, the decision log and the acceptance standard stay the same in each.
01
We build it.
A defined scope, our team, our method and an agreed acceptance standard. Design first, then build, then hypercare. This is how most of our implementation work runs.
02
We start with a pilot.
Especially for AI. One bounded use case, a non-production instance, and your real data under your controls. Before we begin, we agree on the path to production, including what has to be true for it to go live. A pilot with no path to production is a demo.
03
A forward deployed engineer works alongside your team.
One of our people works alongside your team, accountable for a named outcome, with direct access to the people and systems involved. A lead on our side owns changes, and our method and practice stand behind the work.
Forward Deployed Engineer →
Where this sits
The five things we do, and where building fits
Advisory decides what should change and why.
Implementation makes the change exist.
Discovery decides what is worth building and what ready means.
Implementation builds the agreed capability.
Managed Services begins when you choose an ongoing operating model for what has been built.
Implementation ends when the agreed capability is accepted, deployed and supported through the contracted hypercare period.
Enablement exists because a capability your team cannot use is a capability you do not have.
Capability transfer and handover are part of every implementation. Enablement is where that becomes a program in its own right.
Start the conversation
Bring us the design.
Or the instance.
If you have a design and need it built, we will tell you what we would change about it first.
If your instance is live and fighting you, we will start by reading it.
FREQUENTLY ASKED QUESTIONS
Questions buyers ask us
How do you keep our instance upgradable?›
By keeping custom work small, contained and documented. We configure before customizing, leave out-of-the-box records untouched, and keep custom logic in scoped applications. Every deviation from standard has a written reason and an owner. Every change is tracked in update sets, so at upgrade time we know exactly what we built and why.
Can you take over an implementation another partner built?›
Yes. We start by reading the instance before we change it: customizations, skipped records, integrations, and the gap between what is licensed and what is used. You get a clear picture of what is worth keeping, what to return to standard, and what to rebuild, before anyone commits to a plan.
What is the difference between consulting and implementation?›
Consulting produces a recommendation. Implementation produces a working capability, and the two fail in different ways. A recommendation fails by being wrong. A build fails by being unusable, or by being impossible to upgrade. A useful question to ask any supplier is whether the people who designed it will still be there when it goes live.
When does Discovery end and Implementation begin?›
When there is enough clarity to build: an agreed scope, a known architecture, a named owner, and an acceptance standard everyone recognizes. Implementation is the point where decisions start to cost real money to reverse, which is why they should already be made.
When is implementation the wrong next step?›
When one of four things is missing. If two departments still disagree about how the process should work, a build will encode the disagreement, so start with Discovery or Advisory. If nobody trusts the data, start with Discovery and fix the data first. If the AI use case has not been chosen, start with AI Use Case Discovery. And if nobody will own the capability after go-live, decide the operating model before you build.
Should the same firm implement our platform and our AI?›
Not necessarily. But the seam between them is where value usually leaks: AI that cannot see the process, and a process that cannot use the AI. What matters is that one party is accountable for the whole capability working.
What happens after go-live?›
A contracted hypercare period with a named team, and then a decision. Hypercare has an end date on purpose. It exists to catch what testing missed, not to become an informal support arrangement nobody has priced. Before it ends, you choose an ongoing operating model: your own team, us, or a combination. If you choose us, Solution Support keeps the solution working and improving from there.
How do you make sure our team can run it afterwards?›
We write the reasoning down, and we involve your people in the build rather than only in the handover. A decision log tells someone why a configuration exists, not just where it is. Acceptance includes documented test evidence, administrator handover and a cutover runbook.
Do you use AI in your own delivery?›
Yes, in specific places, and always with a person reviewing the result. Claude supports our data migration, knowledge-base migration, read-only instance investigation and documentation. Natural-language configuration, with approval gates before anything is written, is in pilot on a client development instance.
Where does our data go when Claude is involved?›
Only where you have agreed it can go. How Claude handles company data is set out on Anthropic.
What is a forward deployed engineer, and how is it different from hiring a contractor?›
A senior specialist who works alongside your team, accountable for one named outcome rather than for hours, with a planned handback. How the model works, and how it differs from contract staffing, is set out on our Forward Deployed Engineer page.