Notes for owners · Industry playbooks
Why RPA pilots stall after the proof of concept
An automation pilot works and still goes nowhere. This post sets out the usual reasons a proof of concept does not become an order, and what the vendor can fix before it starts.
The GullySales team · Updated 6 Oct 2026 · 5 min read
On this page
Most pilots stall because nobody on the buyer's side owns what happens next. The proof of concept ran, the clerks saw a bot key in an invoice, and then the finance controller went back to the month-end close. There was no decision to make, no named person to make it, and no support terms to sign. A pilot that ends without a dated next step has already ended.
The pilot answered the wrong question
A vendor treats the proof of concept as a test of the technology. The buyer treats it as a test of the vendor. Whether the bot can read an invoice is not what worries the controller. What worries him is the March close, when the bank changes its login page and nobody is there to mend it.
So a pilot that proves the bot works, on a clean set of invoices chosen by the vendor, has shown the one thing the buyer did not doubt. Run the pilot on the buyer's own messy files, including the ones with a scanned stamp over the total, and show what the bot does when it cannot read one. A bot that stops and raises a flag looks more trustworthy than one that has never failed in the demo.
Nobody on the buyer's side owns it
In many companies the pilot is set up by the finance head and the IT head approves access, and neither of them is the person whose morning gets easier. The clerks who key the data feel threatened, not helped, and nobody has told them otherwise.
Ask for a named owner before you start, and write the name in the scope. Ask the clerk too. For example, an automation firm in Pune automating bank statement entry for a distributor in the same city would sit with the two clerks first, and ask which part of the morning they dislike most. The pilot then removes that part, and the clerks become the people who ask for the next one.
The proof of concept has no ending
A pilot that is described as "a few weeks of testing" has no finish line. Write the finish line down in the first meeting: the process, the volume of items to be handled, the measure of success, who judges it, and what the buyer does if it passes. The next-step line is the important one. It reads something like "if the pilot meets the agreed measure, we move to a scoped production phase and sign the support terms in the same meeting".
The time it takes depends on the buyer, so do not promise a number of days. Agree a decision date with them and write it into the plan.
Support is written as an afterthought
The buyer's biggest worry is a bot that breaks with nobody answering. If the pilot proposal says nothing about support, the buyer fills the gap with the worst case.
Put support terms next to the pilot terms. Cover who monitors the bots, how a failure reaches you, what the buyer's team does while it is fixed, and whose name the platform licence is in. That last point matters more than vendors admit, because a buyer who finds the licence is in your name starts wondering what happens if you leave.
A pilot summary that gets signed
| Item | What to write |
|---|---|
| The process | One process, in the buyer's own words |
| The systems it touches | Named, with who gives access |
| The buyer's owner | A person, with a role |
| The measure of success | One measure, agreed before the pilot |
| The decision | Who decides, and the date |
| If it passes | Production scope and support terms, signed together |
| If it fails | What the buyer keeps, such as the process map |
A one-page summary like this goes to the controller and the IT head together, so that information security is brought in at the start and not at the end. Credentials and logs are where many pilots stall, so answer them on page one. The sales process page for automation firms covers the steps from discovery call to signed order.
The second process never comes
Even a pilot that goes live can end there. The vendor leaves and the buyer feels the work is done. But the clerks, the controller and the IT head have all just learned that automation works in their own company, and that is the moment to ask what they dislike next.
Keep a list of the processes you heard about during the pilot, and bring it back at the first review. Name the next process, not "more automation". Use the pilot as a described case for the next buyer too, with the client's permission. The buyer journey page shows where the second sale starts and the CRM page shows how to record who said what.
What to do next
Pull out your last three pilots and write one line for each: who owned it on the buyer's side, what the finish line was and what was signed at the end. If any of the three has a blank, you have found where the next pilot will stall.
The free audit is a 90-minute call on how enquiries reach you and what happens after the first meeting, followed by a written, scored report. For the trade as a whole, start at the business automation and RPA companies page.