Automation fails at adoption, not accuracy

The form nobody fills in

A familiar story. A company builds a reporting app for its field teams. It is well designed, it works, and three months later most of the data in it is entered on Friday afternoon from memory, if at all. The app is not broken. It simply asks too much of people whose real job is somewhere else.

When automation projects disappoint, the cause is rarely the model. It is the gap between how the system expects people to work and how they actually work.

Meet people in the channel they already use

The fastest way to raise adoption is to stop asking people to go somewhere new. Field and site teams already live in WhatsApp. Finance teams already live in Excel and email. Customers already message the business on the channels they prefer.

An assistant that receives a voice note in WhatsApp, or a workflow that reads an attached spreadsheet and writes back to the same thread, asks almost nothing of the person using it. There is no app to install, no password to forget and no training beyond a first message.

Language is part of the interface

In much of South Asia, the people who know what is happening on the ground think and speak in a language other than English. Asking them to report in English is asking them to translate before they can contribute, and many reasonably decline.

Systems that accept Sinhala, and the natural mix of Sinhala and English that people actually speak, remove that barrier. A sentence in Sinhala with an English product name and a number in either language is the normal case, so it has to be the case the system is designed and tested for.

Accept messy input

Real input is untidy. Voice notes have background noise. Invoices arrive as photographs taken at an angle. Spreadsheets have merged cells and notes in the margins. A system that only works on clean input will work in the demonstration and fail in the field.

Designing for messy input means testing on real examples from the start, and deciding in advance what happens when the system is unsure. Which brings us to the most important design decision.

Keep a person in the loop where it matters

Good automation does not try to handle everything. It handles the clear cases quickly and routes the unclear ones to a person, with the context already gathered. An invoice that matches its purchase order goes straight through. One that does not goes to the right reviewer with both documents and the discrepancy highlighted.

This is not a compromise. It is what makes the system trustworthy enough to use, because people can see that it knows the limits of what it knows.

Make every step traceable

Every automated action should be recorded with its source: the original voice note, the original document, the cell it came from. When someone asks where a figure came from, the answer should take seconds. That traceability is what makes automation acceptable to auditors and managers, and it is often what turns a reluctant team into a supportive one.

Measure adoption before accuracy

In the first weeks after launch, the most important number is not accuracy. It is how many of the people who should be using the system are using it, and how often. A system with modest accuracy and full adoption can be improved. A highly accurate system that nobody uses has nothing to improve.