What a typical pilot looks like
Someone in the business is asked to “do something with AI”. A vendor or an internal team picks a process — invoices, claims, complaints — and builds a demo. It reads a clean PDF in English, fills in the fields and suggests an answer. The demo goes well. Everyone agrees it is impressive.
Six months later it is still a demo. Nobody switched it off; it simply never became the way the work is done. The team still keys in, chases and decides the way it did before.
Across the region this is the common outcome, not the exception. When people explain it, they usually blame the model: not accurate enough, not ready for our documents. That is rarely the real reason.
The four things it skips
The real inputs. The demo read clean PDFs. The real work arrives as phone photos of invoices, scans with a stamp across the total, WhatsApp messages with three attachments and a voice note, emails forwarded twice. A pilot that never saw the real inputs has not been tested.
The systems. A decision needs facts the document doesn’t contain: is this supplier known, is there an open purchase order, has this claim been seen before, what did the customer pay. If the pilot can’t read your accounting system, your core system or your CRM, it can only guess. If it can’t write the outcome back, someone still has to key it in.
The languages. Thai, Vietnamese, Bahasa, Tagalog and English, often mixed on one page or in one chat. A model that reads English well and everything else roughly fails on exactly the documents and messages that make up most of the volume.
The review and approval process. Somebody is accountable for every decision. A pilot that produces answers with no place for a person to check, correct and sign off gives that person no reason to trust it, and no way to explain a decision to an auditor, a regulator or a customer afterwards.
Why model quality is rarely the reason
Today’s models read documents well, and small ones can be tuned on your own documents and languages at little cost. When a pilot fails, it is almost never because the reading was impossible. It is because the reading was the only part that was built.
The rest — connections to your systems, handling of the messy channels, the rules your team already follows, the list of decisions, the review screen, the record — is unglamorous engineering. It is also most of the work, and it decides whether anyone uses the result.
What “reached production” actually requires
A process has reached production when cases arrive through the real channels, the agent works them using your real systems, decisions are written back where they belong, uncertain cases go to a named person, and every step is recorded well enough to answer “why?” months later.
And one more thing: someone with authority has looked at the numbers — how many it handles, how often it is wrong, what each one costs — and decided to switch it on. Without that decision it is still a pilot, however well it works.
How the method addresses each
Map documents the real process before anything is built: every channel work arrives through, every system it touches, the list of decisions, who decides today and what the auditor needs. Nothing is assumed from a clean sample.
Measure runs on 200–500 of your past invoices, claims or applications, in your languages, with their known outcomes. The assessment tells you what share the agent would have handled, where it would have been wrong and what it is worth, before you commit to a build. If the numbers don’t work, we say so.
The parallel run builds the connections, the rules and the review screen, then runs on live data alongside your team with nothing executing. Your reviewers see every step; you see the numbers every week.
Switch on is your decision, one decision type at a time. Payments and refunds stay with a person until their numbers say otherwise.
None of this is clever. It is the work most pilots leave out.