How to Run an Effective AI POC on ServiceNow

Last updated: August 2026

Quick answer: An effective ServiceNow AI proof of concept follows four steps. Pick a process rather than a task, selecting for high value and high frequency. Run five feasibility questions before committing. Build in three moves, testing the smallest slice manually before stitching a chain together. And define the evidence, including your baseline, before the build starts.

MIT's NANDA initiative studied enterprise generative AI deployments in 2025 and found that roughly 95% of pilots delivered no measurable return. The number gets quoted a lot. The more useful question is what separates the pilots that produce a funded roadmap from the ones that produce a slide.

At Echelon on the Road in Chicago, our cofounder Anand Sainath ran a roundtable with platform owners and architects on that exact question. This article is the framework from that session, expanded. It covers how to choose a use case, how to test feasibility before you commit budget, how to run the build, and how to present the result to leadership in a form they can fund.

Table of contents

1. Why most ServiceNow AI POCs produce nothing
2. Step 1: Pick the process, not the task
3. Step 2: Answer five feasibility questions
4. Step 3: Build it in three moves
5. Step 4: Define your evidence before you build
6. A worked example: L1 triage, end to end
7. Taking the result to leadership
8. Frequently asked questions

Why Most ServiceNow AI POCs Produce Nothing

The failure usually happens at scoping, months before anyone looks at a result.

A platform team decides to try AI. They reach for the smallest, safest thing on the backlog, because a small scope feels like a responsible way to start. Something isolated, low risk, easy to explain. The tool handles it. Everyone agrees it was interesting. And then nothing happens, because the thing that got automated was too small to change any number a CFO tracks.

The second failure mode is measuring after the fact. The build finishes, someone asks what it saved, and the team reaches for an estimate. Estimates do not survive a budget conversation. Without a baseline captured before the work started, there is no credible claim to make.

Both failures share a root cause. The POC was treated as a technical experiment when the actual output of a POC is evidence. Evidence has requirements: a scope large enough to matter, a baseline recorded in advance, and a number someone would defend in a QBR.

We wrote about the broader case for this approach in why starting with a POC changes everything. What follows is how to run one.

Step 1: Pick the Process, Not the Task

Plot your candidates on two axes. Value on one, frequency on the other. Then aim for the top right.

The instinct to start small is the instinct to pick something in the bottom left, and that quadrant cannot produce evidence no matter how well the tool performs. A one-off report generated perfectly is still a one-off report. Frequency is what turns a per-instance saving into an annual number.

Here is roughly how common ServiceNow candidates plot:

The top right cell is your target list. Those are multi-step processes that recur, which means they carry both a meaningful per-run cost and enough volume to compound.

The distinction between a process and a task matters here. Classifying an incident is a task. Taking an incident from arrival through classification, artifact generation, action, and closure is a process. A task automated in isolation leaves the surrounding work untouched, and the surrounding work is usually where the hours live. Our breakdown of the ServiceNow backlog problem covers why individual task speedups so rarely move portfolio throughput.

Step 2: Answer Five Feasibility Questions

Before committing budget or a sprint, run the candidate through these five. Each one has a failure mode attached, and a no is useful information rather than a dead end.

1. Can you define the steps?

If the process exists only as "ask Dave," an agent cannot run it. Neither can a new hire, which is the more revealing version of the same problem. A process that cannot be written down is a documentation project before it is an AI project.

2. Is the knowledge accessible?

If the knowledge required lives in your developers' heads or in tribal memory, that is the first thing to fix. This is the most common blocker and the most commonly underestimated one. We covered why the record of intent goes missing in why ServiceNow documentation fails.

3. Can a tool reach the data?

Instance access, product docs, past tickets, decision history. Reachable by a system, not just by a person who knows where to look. A process where all the inputs sit in someone's inbox will not run, however well documented it is.

4. Can you define success?

A number you would defend in a QBR. If you cannot name it now, you will not be able to name it afterward either, and the POC will end in a conversation about whether it felt faster.

5. What tooling can you reach?

The options form a ladder. In-product assist such as Now Assist sits at one end, coding agents like Claude Code, Cursor and ServiceNow Build Agent in the middle, and delivery platforms including Echelon at the other end, where the tool comes with the people who run it. Which rung you can reach depends on procurement, security review, and how much of the work you want to own. Our guide to AI tools for ServiceNow delivery compares eight of them, including where each one stops.

One yes can be enough to unlock a use case that otherwise looks blocked, which the worked example below illustrates. The point of the questions is to surface which specific thing needs fixing first, rather than to produce a pass or fail.

Step 3: Build It in Three Moves

The build has a shape, and following it produces a defensible number rather than an impression.

Move 1: Test manually

Take the smallest slice of the process and run the tool on it by hand. Does the output meet your bar? If it does not, the useful output of this move is knowing why, specifically. Missing context, unreachable data, an undocumented step. Each of those is a different fix.

Move 2: Iterate outward

Repeat per subtask until you have a chain. What you are building is a map showing exactly what AI can and cannot complete today on this process, on your instance. That map is valuable on its own, and it survives even if the POC does not proceed.

Move 3: Stitch it together

Connect the chain end to end. This is the point where you get your first real number on total time and cost, because you are measuring a complete process rather than a step.

The governing principle from the session: start from the smallest slice and work outward, but always inside a use case big enough to matter. That combination is what separates a demo from evidence. A small slice inside a large process gives you a safe starting point and a meaningful ceiling. A small slice inside a small process gives you neither.

Step 4: Define Your Evidence Before You Build

Measurement has two tracks, and most teams only run one.

Track 1: Team adoption

Which groups adopt first, and how they use it. Which groups resist, and what triggers the flip from not using it to using it. This track is soft, and it predicts whether anything survives past the pilot. A tool that works and that nobody opens has failed.

Track 2: Hard data

• Cycle time. Request to deployed, measured end to end.
• Throughput. How much the team ships per sprint.
• Rework and quality. Does the output hold up after it ships? A throughput gain that generates defects is a transfer, not a saving.

Your baseline depends on who builds today

This is the part to get right before anything else, because the baseline determines which sentence you can say at the end.

If your own team builds, the baseline is your team's time and capacity. The sentence you are working toward sounds like this:

"We cleared 30% more of the backlog with the same headcount."

Baseline captured: hours per unit of work, and units shipped per sprint, before the POC.

If a partner builds, the baseline is SOW cost and partner turnaround. The sentence sounds like this:

"What used to be a $40k SOW taking six weeks now takes days, and gets done in-house."

Baseline captured: the quoted cost and elapsed time of comparable recent SOWs.

Write the sentence you intend to say before the build starts, with the number blank. If you cannot construct the sentence, the scope is wrong and you should return to step 1. Teams evaluating the commercial side of this will find our comparison of outcome-based versus hourly billing useful for framing the partner baseline.

A Worked Example: L1 Triage, End to End

The framework run on a real use case, from the roundtable.

The map

L1 triage, end to end. Not the narrow version. Every ticket needed the right artifacts generated and the right actions taken, so the scope covered classification through resolution rather than classification alone. High value, high frequency, and a genuine multi-step process. Top right of the map.

Feasibility

One yes unlocked it. The steps lived half in a wiki and half in people's heads, which is a fail on question one and a partial fail on question two. What rescued it was question three: every ticket carried the signals needed to route it, and thousands of past tickets showed how the team routes in practice. The decision history existed as data even though it did not exist as documentation.

That pattern is worth internalizing. Where a process is undocumented but heavily exercised, the record of how it runs may already exist in your instance.

The build

Three steps, repeated per category. Classify the ticket. Carry out the action, which spanned tickets, emails, and in one case an external service reached through a mailbox integration. Then act on the response. Each category was built out the same way, which is move two of the build shape, iterating outward until the chain was complete.

Measurement

Evidence defined up front. The baseline was hours of manual triage per week. The bar was routing accuracy, agreed before anyone built anything. And the leadership sentence was written before the build, with the number left blank.

Their platform owner summed up the reason any of this matters in four words: "Demos are just demos." Prove it on your own instance, with your own configuration and your own edge cases, or you have proven nothing about your environment.

Taking the Result to Leadership

A POC that produced a real number still has to survive a conversation. Three objections come up repeatedly, and each has a better answer than the defensive one.

"Will my budget get cut?"

The framing to avoid is efficiency for its own sake, because that framing invites exactly the outcome you are worried about. The framing that works is more with existing. The same budget now buys a larger portfolio, and the backlog that has been sitting untouched for three quarters starts moving. You are expanding what the budget delivers rather than defending its size.

"We have a year left on our MSP contract, do we need this now?"

An existing partner contract is a reason to start sooner. Evidence gathered now becomes leverage for your next renewal. Walking into that negotiation with measured data on what your own team can deliver changes the conversation from renewing by default to scoping deliberately. Our non-negotiables for evaluating ServiceNow partners covers what to hold that conversation to.

"Half my team is anti-AI."

Watch who flips. This is why adoption is track one of the measurement framework rather than an afterthought. Skepticism on a platform team is usually specific rather than ideological, and it resolves when someone sees the tool handle a case they were certain it would fail. Track which groups adopt first, which resist, and what specifically triggered the change. That record is more persuasive internally than any vendor material.

Frequently Asked Questions

How long should a ServiceNow AI POC take?

Long enough to complete the three build moves on a process large enough to matter, which usually means weeks rather than months. The constraint is rarely tooling speed. It is whether the process is documented, whether the data is reachable, and whether you captured a baseline before starting.

What is the best first AI use case on ServiceNow?

A high-value, high-frequency multi-step process. Common candidates are catalog item creation, requirements through to build, Workflow to Flow migration, upgrade work, and bulk data updates. The worst first use case is the smallest safe item on your backlog, because it cannot produce a number worth funding.

How do you measure the ROI of an AI POC?

Capture the baseline first. If your team builds, baseline hours per unit of work and units shipped per sprint. If a partner builds, baseline the cost and elapsed time of comparable SOWs. Then track cycle time, throughput, and rework alongside adoption by group.

What if our processes are not documented?

Check whether the decision history exists as data even though it does not exist as documentation. Thousands of past tickets can show how a team routes in practice. Where that record exists, an undocumented process may still be a viable candidate. Where it does not, documentation is the prerequisite project.

Should we use Now Assist or a third-party tool for a POC?

It depends which rung of the tooling ladder you can reach. In-product assist requires no new vendor or security review, which makes it the fastest thing to try. Coding agents and delivery platforms cover more of the process end to end. Match the tool to the scope of the process you selected rather than selecting the process to fit an available tool.

Key Takeaways

• Pick the process, not the task. Plot value against frequency and target the top right. The smallest safe item on your backlog cannot produce evidence.
• Run the five feasibility questions first. Definable steps, accessible knowledge, reachable data, a defined success number, and a tool you can procure.
• Build in three moves. Test the smallest slice manually, iterate outward per subtask, then stitch the chain together for your first real number.
• Write the leadership sentence before the build. With the number blank. If you cannot construct it, the scope is wrong.
• Measure adoption alongside hard data. Cycle time, throughput and rework tell you whether it worked. Adoption tells you whether it survives.
• Prove it on your instance. Demos are just demos.

Running Your First POC

The framework above came out of a room full of ServiceNow platform owners in Chicago comparing what had worked and what had stalled. The consistent pattern was that POCs succeed or fail at scoping, and that the teams who got funded were the ones who decided what evidence looked like before they started.

If you want to run this against your own instance, an instance scan produces the input for step 1: what is in your instance today, grouped by root cause, which makes the value and frequency question answerable with data rather than intuition.

To try the tooling directly on a personal developer instance, try Echelon. To talk through use case selection with our team, book time with us. We run these sessions live at Echelon on the Road events as well.