Inside this article
- A pilot answers one question: can the model do this task? Production asks several more, about systems, access, approval, record and ownership.
- A production workflow needs scoped agents, approval routing, run logs with a way to roll back, and a trial on real work by the people who own it.
- A stalled pilot is rarely wasted. It has already proved the task, which is a good input to a proper build.
Many IT channel businesses have run an AI pilot by now. Someone connected a model to a sample of tickets or quotes, the output looked good, and the room agreed it had promise. Months later the work is still done the old way.
This is common enough to have a pattern, and the pattern has a practical answer. The pilot worked. It simply answered a smaller question than the one production asks. This article sets out the difference and what to add.
What is the difference between a pilot and a production workflow?
A pilot is a test of capability. A production workflow is a part of how the business runs. The same task can sit in both, held to very different standards.
In a pilot, the data is a sample, the access is one person's login, and the result is copied back into the real system by hand. That is the right way to run a quick test. It tells you whether the model can classify a ticket or draft a quote summary.
In production, the workflow has to reach live systems, act under limits someone has agreed, put its changes in front of a person, leave a record, and belong to someone. None of that was needed for the test, so none of it was built.
Why does a pilot stall when the model clearly works?
Because the questions that decide whether something goes live are not about the model.
An operations leader asked to put a pilot into production will ask: which systems does it touch? What is it allowed to change? Who approves that? If it gets something wrong, how do we find out and undo it? Who looks after it next quarter? What does it cost to run, and how do we know it helped?
A pilot has no answers to these, because it never had to. So the sensible decision is to wait. The pilot is not rejected. It just never gets a date.
PRESHai groups the reasons into five gaps: adoption, systems, control, change and return. The why AI stalls page describes what each one looks like from the inside and what closes it. For a pilot, the systems and control gaps usually bite first. The assistant cannot reach the PSA or the CRM, and nobody is willing to let it change a live record.
What does a production workflow need?
Four things, all of which are engineering around the model.
Scoped agents. Each agent has a role, the way a person does. It can read and change only what that role allows, and never more than its owner.
Approval routing. The agent proposes and a person decides. Anything the agent wants to change waits in one inbox, where the approver sees exactly what will change.
Run logs and rollback. Every run is kept with its steps, so a change can be traced and rolled back. This is the answer to "how do we find out and undo it".
A trial on real work. The people who own the work use the workflow on real cases and approve live actions before it goes live. A demo scenario is not a substitute.
Underneath all four sits the connection to your systems. Agents have to reach the systems of record, with access scoped to the job, and those systems stay where they are. The deployment page covers how these pieces come together in a build, and governance covers how roles, Approvals and the record work in PRESHos.
Who has to own it?
A pilot is often run by whoever was curious: an engineer, an analyst, a manager with a free afternoon. That person usually has a day job, and the pilot is not it.
A production workflow needs a named owner on the business side. This is the person who answers for the work the workflow does, such as the service desk manager or the sales operations lead. They decide when it goes live, they hear about it when it misbehaves, and they decide what to change.
It also needs someone to keep it current. Vendor systems change, models change, and the process itself changes. If nobody is accountable for keeping up, the workflow slowly drifts away from how the business works.
How do you prove it is working?
Agree the measure before the build, and make it a number your team already counts.
Take a quoting workflow at a solution provider. "Faster quotes" cannot be checked. "Time from discovery call to quote sent" can, because the CRM already holds both dates. Write down today's value. After the workflow has been live for a while, read it again.
Then add the cost side. If each run is recorded with its steps and its cost, you can see what the workflow costs per task and set that against the result. Without both numbers, the conversation about whether to extend the workflow turns into opinion.
Can a stalled pilot be rescued?
Usually, yes. A stalled pilot has already done something useful: it has shown that the model can do the task. That removes one risk from the build.
Treat the pilot as the starting material for a proper first workflow. Name the owner. Agree the measure. List the systems the work really runs through and who owns each one. Decide what the agent may read and change. Then build the connections, the roles, the approvals and the record around the task the pilot proved.
This is the sequence PRESHai follows in every implementation: Map, Connect, Deploy, Operate and Transfer. How we work shows what happens in each phase and which decision is yours.
One caution. Some pilots stall for a good reason: the task was not worth doing, or the process underneath it was not settled. If the owner cannot name a measure the workflow would move, that is a sign to pick a different workflow.
What should you ask before the next pilot starts?
A few questions at the start save the stall at the end.
- Who owns this work, and will they decide when it goes live?
- Which number is it meant to move, and what is that number today?
- Which systems does the work run through, and who can grant access to each?
- What would the agent be allowed to change, and who would approve it?
- If this works, who runs it afterwards?
If these have answers, you are no longer planning a pilot. You are planning a first production workflow, and the test of capability becomes the first step of the build.
Where to start
Take the pilot that came closest and run it through the questions above. The gaps in the answers are your build list.
If you would like to work through it with someone, tell us where AI is stalling. We will talk through the first workflow worth fixing and what is practical to build and run.
