A pilot is usually scoped to prove the technology works. So it gets built on the cleanest data anyone can find. The invoices that match. The orders that arrive complete. The forms somebody filled in properly. The demo goes well, because everyone in the room watches the agent read a document and do the right thing with it.
Then it meets a normal week.
The happy path was never the problem
If a case follows the rules, something is probably handling it already. A rules engine, a template, or a person who clears it in two minutes without thinking. The time goes on the cases that don't follow the rules. The invoice with no PO. The payment that covers three invoices and part of a fourth. The vendor who changed their remittance format without telling anyone.
Those cases are where the cost sits. They are also exactly the cases a demo is built to avoid.
Test it on the worst week
We ask for the worst samples you have. The faxed copy. The handwritten correction. The case your team keeps in a separate folder because nobody is sure what to do with it. If the agent can't cope with those, we'd rather find out in week one than after you've told your board it works.
Two questions tell you whether a pilot means anything. First, what does the agent do when it isn't sure? It should stop and hand the case to a person with its reasons. It should never guess. Second, who decided where sure ends? That line belongs to the person who owns the process, and it should be written down.
Why we run in parallel first
Nothing we build goes straight to the lead. It runs alongside your existing process on live work, and every miss gets reviewed each week. By the time it takes over, you have watched it handle your own exceptions.
A pilot that proves the technology works answers a question nobody was asking. The useful question is what happens on the case nobody planned for.