A pilot automates one process for one team and demonstrates that it can be done. Then the project stops. This is common enough to be worth treating as the default outcome rather than a surprise.
The pilot was chosen because it was easy
Pilots are picked for a quick result: a clean process, tidy data, one willing team. The next process has three exceptions, data entered inconsistently for years, and a team that was not asked. The pilot proved the technology, not the rollout.
Nobody owns the automation after launch
Automation is not a project that finishes. Processes change, upstream systems change, and something that silently stops working is worse than something that was never automated, because people have stopped checking.
If no named person is responsible for it a month later, it will quietly rot.
The exceptions were never counted
Most processes are mostly standard. The trouble is that the remainder is not rare enough to ignore and not uniform enough to automate quickly. If a fifth of cases fall out to a human, the team still needs the capacity to handle them, and the saving is far smaller than the pilot implied.
The measure of success was never agreed
Hours saved, errors reduced, time to complete, cost per transaction. These lead to different designs. Without agreement, the pilot is judged on whichever number looks best, and the next phase cannot be justified.
What makes the difference
Pick the second process before the first one launches, and pick it for difficulty rather than ease.
Name the person responsible for the automation once it is running.
Measure the exception rate during the pilot and plan for it.
Agree the number that matters before building anything.
None of this is about the tooling. The automation projects that spread are the ones where somebody treated the rollout as the hard part.