The pilot worked. That is exactly the problem.
A pilot runs under conditions that disappear the moment you scale: the person who built it is watching, the data was cleaned by hand, and the team involved knew it was coming. At unit number two, none of those things are true.
Here are the six failures that account for most stalled rollouts, and what has to exist before the second unit goes live.
1. The pilot was a build, not a configuration
The first location got a workflow. The second one needs different fields, a different script, a different routing rule and a different phone number, so somebody rebuilds it. Now there are two systems, and a fix applied to one silently does not apply to the other.
The test: write down what changes between unit one and unit two. If the list is values, it scales. If the list includes logic, it does not.
What to do: turn the pilot into a template with a configuration per unit. A location should be a config, not a development project.
2. The data was cleaner in the pilot than it is in reality
Somebody normalised the phone numbers for the pilot. Somebody removed the duplicates. Often they do not even remember doing it, because it felt like preparation rather than work.
Then the real list arrives with three variants of the same company, numbers that predate the records holding them and empty fields where the logic expects values.
What to do: enrich, verify and deduplicate before contact, and route bad contact information into its own path instead of spending a dial on it. A wrong number costs exactly what a right one costs.
3. Nothing was written back where humans work
The AI called, learned something and stored it in its own platform. The CRM shows nothing. So the rep calls back and asks questions the customer already answered, and the customer concludes nobody is paying attention.
What to do: whatever the system learns lands on the record a human already opens. Outcome, a two line summary, the corrected contact details, the next step. A log only the builder reads is worth nothing operationally.
4. There is no error route
The API times out at 2am. The model returns valid JSON with a wrong value. A webhook fires into a workflow that was renamed last week. Automation documentation treats error handling as a first class concern precisely because what has no error route falls over in silence.
What to do: every flow gets an error path and an alert with enough context to act on. And build small: start with the simplest thing that works and add autonomy only where it earns its cost.
5. Nobody owned it after launch
The builder moved to the next thing. Six months later the script no longer matches the offer, one integration has been failing quietly since a platform update, and nobody can say when it stopped working.
What to do: name an owner before launch, not after. Write the runbook while building, not at handover. And schedule a review that actually happens, because these systems decay in the direction of the business changing around them.
6. Success was measured in activity
Twenty thousand calls is not a result. Neither is a hundred thousand emails sent. Activity metrics are easy to produce and they let a project look healthy while producing nothing.
What to do: define the business result before launch and instrument the path to it. Money received, walked backwards through the deal, the handoff, the conversation and the list it came from. If you cannot trace it, you cannot decide what to keep.
The one thing to fix first
If you only address one of the six, make it the fifth: give it an owner. Most of the other failures are survivable when somebody is watching, and none of them are when nobody is.
The second thing is the definition of done. A green execution is not proof that anything worked. The proof is the record: open the lead, and the business result is either there or it is not. Teams that change that one definition find half their silent failures within a week.
If the blocker is inside your systems
That is a specific job, and it has a name. MitHub keeps open profiles of forward deployed engineers who have taken this work from pilot to production inside real companies, with each deployment written out: the problem, the approach, what was built and what it produced.
See the engineers. Reading the work and contacting them is free.