Order intake is where most operations quietly lose their day. Documents arrive by email, portal, PDF attachment and occasionally as a photograph of a printed sheet, and someone re-types them into the system that runs the business.

This is one of the most worthwhile things to automate and one of the easiest to do badly.

Why demos mislead

A demonstration runs on a clean document with predictable fields. Real intake includes a supplier whose layout changed last quarter, a customer who lists quantities in the notes column, and a scan that arrived slightly rotated.

Accuracy on the clean case tells you almost nothing about whether the system will hold up on a Tuesday in December.

Build for variation, not compliance

The instinct is to standardise the input. In practice you cannot make your customers change how they order, and trying to do so costs goodwill you need elsewhere.

It is cheaper and more durable to accept that input will be messy and to build extraction that reads intent rather than fixed coordinates.

The exception queue is the product

Whatever the extraction rate, some documents will not resolve. What decides whether the system is trusted is what happens to those: whether they surface immediately, land with a named person, carry the original document alongside the parsed result, and can be corrected in seconds.

Teams forgive a system that says clearly what it could not read. They abandon one that guesses silently.

How to scope the first stage

Pick one document type and the five highest-volume senders. Run extraction alongside the manual process for a fortnight and compare. You will learn more from that fortnight than from any vendor accuracy claim, and you will have the exception patterns you need to design the rest properly.