Pilots start easily: the technology is on everyone's lips, a "let's try it" budget appears, the contractor makes promises. In our experience – and companies often come to us right after someone else's stalled pilot – roughly one in three or four makes it to productive use. The rest quietly wind down under the heading "we gained some interesting experience." And the reasons repeat with such regularity that we gathered them into a list and check every new project against it, like a checklist in reverse. Here are all five, and how to get past each one.
Reason 1. A pilot with no metric owner
The most common and the least visible. The pilot is launched to "take a look at the technology": the IT director is named as sponsor, or a working group of six people is assembled. Two months in, the agent does something, but no one answers the question "did it get better or not" – none of the six has anything riding on that number. The project doesn't fail with a bang. It dissolves.
How to get past it: before you start, name one owner and one metric. Head of support – the share of tickets closed without an operator. Chief accountant – minutes to assemble a set of source documents. Head of department – the amount deducted for defects during the fund's inspections. The owner is the person who reports that number to the director, not the person who was "asked to oversee it." One metric. Not five.
Reason 2. Automating chaos
If three employees run a process three different ways, the agent will faithfully reproduce all three – contradictions included. A sure sign of chaos shows up during the review itself: we ask "what's the right way?" and three people give three different answers, each one confidently. Automating that means speeding up chaos and getting more of it.
How to get past it: pick a first process where a "right way" exists – to find one, we run candidates through a seven-question checklist. If the process matters but has drifted, the reference is fixed right during the week we set up the prototype: one page where the owner answers the disputed cases in writing. Not a forty-page regulation – one page.
Reason 3. "Let's do everything at once"
A scope covering six departments, four integrations, a custom interface and a mobile app on top. A pilot like that dies under the weight of approvals: over eight months priorities shift, the sponsor leaves, the budget gets cut – and there's still nothing to show. In our experience, each extra department in the first wave roughly doubles the time to the first measurable result.
How to get past it: one scenario, all the way to a result. Not "sales automation," but "handling inbound calls and filling in the records." Expand after the first number: on a platform, the second scenario connects faster and cheaper than the first, because the integrations, permissions and orchestration are already built. We covered the economics of this model separately – and it explains why scope discipline pays off, rather than just being "the right thing to do."
Reason 4. Employees see a threat, not a helper
A pilot can be technically flawless and die socially. Managers "forget" to use the suggestions, operators hit "skip," doctors never open the drafts. The metrics end up at zero – not because the agent is bad, but because no one used it. The cause is always the same: people heard the word "optimization" in the project and decided it was about them.
A real example. The contact center of a telecom operator, second week of the pilot: operators accepted the agent's suggestions 9% of the time. We talk to the shift – the fear is simple: "you'll collect the stats and cut staff." What we did. We opened the agent's action log to the operators: they could see what it does and what it doesn't, including in bilingual dialogues. We gave them the right to correct the agent's answers – every correction fed back into the configuration. We publicly changed the pilot's metric from "payroll savings" to "time to respond to the subscriber." Three weeks later the share of accepted suggestions rose to 64%, and the shift leaders themselves brought a list of scenarios they wanted to hand to the agent next. Similar processes are described in our customer service solution.
How to get past it: from day one, say out loud that the agent takes over the routine, the checkpoints stay with people, and no one gets cut as a result of the pilot. And keep your word – no one will believe it a second time.
Reason 5. A project instead of a platform
The pilot was built by a contractor to order. A polished demo, applause – and then the contractor moved on to the next contract. A regulation changed – a fix means a quote and a three-week wait. The models updated – a rebuild. Six months later the company is running "the version as delivered," which fewer and fewer people use. Production is not "a finished pilot." It's operation: monitoring, an action log, permissions, model updates, connecting new scenarios.
How to get past it: before the pilot even starts, ask "who will change the scenario in six months, and how, when the process changes?" If the answer is "we'll order a rework," you're buying a project with an expiry date. If it's "we'll adjust the scenario's configuration on the platform," the automation has a chance of surviving its first year. The subscription model – from 12 million tenge a year – exists precisely for this: the platform lives and changes along with your processes, instead of being frozen at the handover date.
How do you get a pilot to production?
Ready to launch = one scenario + a metric owner + a recorded reference of "the right way" + employees the agent helps + a plan for operation after the pilot.
Our route looks like this. Process review – an hour, we pick the scenario and the metric. A prototype on your data – about a week, free. A decision based on the numbers, together with the metric owner. Rollout to production – from eight weeks, with checkpoints and team training. Subscription payback, with a scenario chosen by the checklist, is 6–9 months. Each step of the route closes one of the five reasons above; that's the whole point of it. The easiest way to start is with a review of your processes – an hour of your time, no commitments.
Frequently asked questions
Our pilot already failed. Start from scratch?
First, a post-mortem: which of the five reasons was at play. Most often it's the metric owner or a bloated scope, and then a relaunch on the same process takes less time than the first attempt: you already have the data, the access, and an understanding of the exceptions.
How do you tell in advance whether employees will accept the agent?
Give them a role in the setup. The people who do the work, invited to the review and taught to correct the agent, defend the pilot better than any order from above. The details help too: an action log open to the team, and a metric framed around the outcome of the process rather than cutting people.
How many scenarios should you launch in the first year?
In our experience – two to four. The first is taken through to payback and becomes an internal case study, and then neighboring processes are connected: they share integrations and permissions, so each next one starts faster and cheaper than the last.