Manual data entry is rarely anybody's job. That is exactly why it survives. It arrives ten minutes at a time, attached to work that does have an owner, and it never appears on a budget line as its own cost.
It shows up in the answers to a different question. Ask someone what they did this morning and you hear about the customer. Ask what they typed twice and you find the process.
Where the retyping usually lives
- A form on the website, then the same details typed into a CRM or a spreadsheet.
- Supplier invoices arriving as PDFs, then keyed into accounting one line at a time.
- Orders that come in by email or WhatsApp, then copied into a sheet, then copied again into shipping.
- Timesheets collected in one format and re-entered into payroll in another.
- Marketplace or supplier exports reconciled by hand against your own stock list.
- A closed deal in the CRM that someone turns into an invoice by retyping the numbers.
Three questions that decide it
How often does it happen, and how many people do it? Volume is what turns a small annoyance into a real number. A step that happens twice a month may not be worth touching. The same five-minute step happening forty times a day is a different calculation.
How stable is the input? A CSV that always has the same columns is easy. A supplier who redesigns their invoice twice a year is harder. Handwritten notes photographed on a phone are a different project altogether.
What does an error cost? Retyping a postcode wrong means a redelivery. Retyping a price wrong can mean invoicing a client incorrectly for a year before anyone notices. The pricing error justifies stronger controls much sooner. The postcode error may not, unless the volume and the cost of redelivery add up.
Automate in the boring order
Start with the highest-volume step that has the most structured input, even if it is the least interesting one. If both systems have a usable API, that is usually where we start: there is less interpretation involved, and failures can be logged, retried and seen, rather than discovered weeks later.
Reach for document extraction, whether that is OCR, structured parsing, or a model handling documents that follow no fixed format, only where structure genuinely is not available. When you do, send anything that fails validation, does not match an expected value, or comes back flagged as uncertain into a review queue before it reaches the system of record. You keep most of the speed without letting an uncertain reading write straight into the system your team relies on.
What to leave to people
- Anything where the typing is incidental and the judgment is the actual work.
- Low volume with high variance. Ten unusual cases a month will cost more to encode than to handle.
- Steps in a process you already know is changing. Automating a workflow two months before it is redesigned wastes the build twice.
- Anything where an error is both expensive and invisible, unless you also build the check that would catch it.
What the work costs
Four things move the price. Whether both systems expose a usable API, or whether one of them has to be driven through exports and imports. How clean the existing data is, because matching records that were typed by hand is often the real work. Whether history has to be backfilled or only new records flow. And whether a human review queue is needed, which is a small interface rather than a script.
The cheapest projects are the ones where two systems already speak and nobody had connected them. They are the easiest to justify because there are fewer moving parts, but they are not maintenance-free: credentials expire, schemas change, endpoints get deprecated, and something has to notice when they do.
Before quoting anything, we count. Pick the step you suspect is worst, tally it for a week, and you will usually find the answer is obvious in one direction or the other.