Paid engagement
AI Workflow Pilot
A fixed-scope engagement that builds one workflow, connects it to the systems your organization already uses, runs it against real work, and evaluates it against success criteria agreed before the build started.
A Pilot follows a completed AI Opportunity Assessment, and that order is what makes it worth paying for: the Assessment chooses the workflow, confirms the access and data it depends on, and sets the criteria. It is the third step of the whole engagement path.
Who the Pilot is for
A Pilot suits organizations that have already decided what to build first and are prepared to let the result be judged.
A good fit when
- An Assessment has named the workflow to build first and written down what success would look like.
- The work crosses Microsoft 365 and one or more business systems, and someone carries it across by hand today.
- A process owner can make decisions during the build, not only review it at the end.
- You want to know whether the workflow earned its place, including when the answer is that it did not.
Not the right step when
- No workflow has been chosen yet. Choosing is the Assessment’s job, and skipping it risks building the wrong thing well.
- The point is something to show in a meeting rather than something the team uses in its daily work.
- Guaranteed savings, or a workflow that changes records with nobody accountable, is the expectation.
- Several workflows are wanted at once. A Pilot builds one, and what follows is decided on evidence.
What “pilot” means here
The word is used loosely, so it is worth being exact about what happens during one of these engagements.
It runs against real work
It handles the items your organization actually handles, in their usual volume and their usual mess, not a tidy set chosen because it behaves well.
It runs with the people who do the work
The staff who own the task use it as part of their day and say where it helps, where it gets in the way, and where its output cannot yet be trusted.
It runs inside the permissions already in place
It reaches what the signed-in person is already allowed to reach, through the systems you already run. No standing access is created to make the build simpler.
A person stays accountable for what leaves the team
Record changes, payments, and outbound messages are approved by someone answerable for the outcome. Drafting and classification support that decision, and never make it.
That is the distinction. It is not a demonstration built on sample data and shown in a meeting, and it is not a sandbox exercise running beside your systems instead of inside them. Either can look convincing and still say nothing about how the workflow behaves where the work actually lives.
A published walkthrough shows one built this way: retrieval under the signed-in person’s own permissions, and a record change held for approval. The records are invented and no result is claimed.
What the build may include
What a given Pilot uses follows from the workflow the Assessment chose, and is fixed in the scope agreed before work starts.
- Human-reviewed drafting, classification, summarization, retrieval, and record actions
- Connection to existing systems through whichever method fits: an application programming interface, an automation platform, a webhook, a business application plugin, or a custom component
- A permission-aware assistant that answers from approved internal knowledge
- Role-based guidance and a usage policy for the people who work with the new workflow, written for the tools they actually have
- Evaluation against the success criteria the Assessment set, using signals the organization already has
The connection method is a consequence of the workflow rather than a preference. Whichever route is used, what enters the workflow, where it travels, and what is retained is agreed in writing before anything is built.
How success is judged
What the engagement should produce is stated before it starts. One workflow running against real work, inside the permissions and systems already in place, with a person still accountable for anything that leaves the team, and an evaluation against the agreed criteria that says whether it earned its place.
- Set beforehand
- The criteria come from the Assessment, so success is not defined afterwards by whoever is most invested in it.
- Observable in normal work
- They are read from signals you already have—queue times, rework, exceptions, approvals—not a satisfaction score collected once.
- Able to return a no
- The evaluation can conclude the workflow did not earn its place. A measure that only confirms the decision to build is not a measure.
The four outcomes
An evaluation ends in one of four places. All four are legitimate, and all four arrive with the reasoning recorded.
Proceed to Ongoing AI Operations
It met its criteria. The retainer takes over reliability, support, and the decision about what to build next.
Adjust and re-evaluate
The approach holds but something specific is wrong: a step, a permission, a handoff. The change and the second evaluation are agreed in writing first.
Narrow it
It earns its place for part of the work and not the rest. That part stays, the rest is recorded as out of scope, with the reason.
Stop
It did not earn its place. It is switched off, the rollback path is used, and the write-up records what was observed and what would have to change.
What you receive, and what the Pilot asks of you
A Pilot ends with a working workflow and the written material needed to run it without Natural State Logic in the room. Getting there needs access and participation only you can give.
What you receive
- One workflow running against real work, evaluated against success criteria agreed before implementation started
- Implementation documentation covering what the workflow does, which systems it touches, and who owns it
- A tested rollback path for every action the workflow can take
- A written usage policy and reference material for the roles that use the workflow
- Handover to the people who own and operate the workflow day to day
What stays with you
- A process owner who can make decisions during the build
- A safe way to test, using synthetic records or a non-production path, whenever the workflow touches real records
- Timely review of outputs while the pilot is being evaluated
- Participation from the people who will use the workflow, not only from leadership
Adoption is part of the Pilot
A workflow nobody uses correctly has not been implemented, so guidance and policy are built during the Pilot rather than offered separately afterwards.
The people who use the new workflow receive role-based guidance: what it does, where its judgment ends, what to check before approving something, and what to do when output looks wrong. A usage policy states what may be put into it and what may not. Both are written for the tools those people actually have, in the licensing your organization actually runs.
At handover a person inside your organization owns both, so they can be updated when the work changes or new staff arrive. Guidance helps people use a workflow well; it does not make anyone secure or compliant. The controls are built into the workflow itself, where they do not depend on someone remembering them.
The constraints apply during a Pilot
Least privilege, data-flow review, logging, tested rollback, and human authorization for sensitive actions are minimum conditions of an engagement. They are not relaxed because the work is a first build: a workflow built without them could not be put into daily use, so evaluating one would prove nothing.
The full set is stated once, for every engagement, on the services page.
What happens after the Pilot
The evaluation is written up
What the workflow did, how it performed against each criterion, where it needed a person, and what the people using it reported. It is yours to circulate.
You decide
Nothing continues automatically. Keeping the workflow, changing it, narrowing it, or switching it off is your decision, made from the evidence.
If it met its criteria
Ongoing AI Operations takes over reliability: monitoring, access review, provider changes, employee support, and the decision about what to build next.
If it did not
The write-up records why, and what would have to be different—in the data, the systems, or the process itself—before it would be worth building again.
Questions about the Pilot
Can we skip the Assessment and start with a Pilot?
No. The Assessment chooses the workflow, confirms the access and data it depends on, and sets the criteria. Without it a Pilot can be built competently and still be the wrong workflow, or the right one with no agreed way to tell. The way to start is the AI Opportunity Call.
We already had an assessment done by another firm. Can you pilot from it?
The AI Opportunity Call is where that is decided. We look at what the existing work established and judge whether it gives a Pilot what it needs: a chosen workflow, confirmed access and data, and observable success criteria. Sometimes it does; sometimes a shorter validation comes first.
How long does a Pilot run?
It depends on the workflow, how many systems it crosses, and how quickly access and the right people are available. The schedule is fixed in writing before work starts, so it cannot expand quietly while it runs.
Does a Pilot touch production systems?
Only through the safe test path agreed in scope, and only with a tested rollback for every action it can take. Where it reaches real records it uses the narrowest access that does the job, and a failure leaves the record untouched and reports the error.
What if the Pilot fails its criteria?
That is a legitimate outcome, written up the same way a success is: what the workflow did, where it broke down, and what would have to change. An engagement that can only recommend continuing is not an evaluation.
Who owns the workflow afterwards?
You do. Handover is a deliverable: the implementation documentation, the rollback path, the usage policy, and a named person inside your organization who owns them. Ongoing AI Operations is available, and never assumed.
Is the price fixed?
Scope, schedule, and commercial terms are agreed in writing before work starts, and a Pilot is fixed-scope by design. Anything that would change the scope is agreed before it is built, never invoiced afterwards.
Start with the free conversation
Every engagement begins the same way. Bring the workflow you would want a Pilot to build, and the call will establish the honest next step.