Skip to content
Bytewerf

Stop retyping forms and field reports

Short answer: retyping can go away as soon as you can name which fields you need out of a document. Not understand the whole document, just those fields. Once that list exists, retyping is a task software can do, with a person alongside it for the cases that stand out.

Where the retyping comes from

The pattern is nearly always the same. Something gets recorded in the field: an inspection, a work order, a measurement, a delivery note. It arrives as a photo, as a scanned form, as a loose pdf, or as all three mixed together. In the office someone transfers those details into the system the rest of the business works in.

That person is not doing stupid work. They read awkward handwriting, spot that an engineer ticked the wrong box, and know that this particular customer always puts two lines on one note. Which is exactly why retyping survives so long: it looks like knowledge you cannot automate.

The question that settles it

The useful question is not “can software read this”, it is: which fields do we actually use afterwards?

For a four-page inspection report, that often turns out to be eight or ten. The fault found, the measurement, the part used, the location, the date, who did it. The rest of the document is context that has to be kept, but that nobody ever retypes.

Once that list is on the table, the job changes. It is no longer “understand documents”, it is pull out ten fields and keep the rest as an attachment. That is a task with a clear boundary, and therefore a task that can be made reliable.

The exceptions are the real design

Automatic extraction goes well most of the time and sometimes it does not. That is fine, as long as you agree in advance what happens then.

In practice this works well:

  • Confident enough goes straight through. What is stated clearly on the document goes directly into the system.
  • Doubt goes to a person, with the document next to it. Not retyping from scratch, just confirming or correcting one field.
  • Urgency skips the queue. A fault that needs attention today does not wait for the data entry pile, it gets put in front of someone immediately.

That third rule often delivers more than the time saving itself. When reports wait in a stack until somebody processes them, an urgent fault only becomes visible at the end of the week. Processed on arrival, it is the same day.

How to tell it is still too early

One situation: if nobody can say which fields are needed, because every department pulls different details out of the same document, then retyping is not your problem. The lack of agreement about what should be recorded is your problem, and automation will not solve it. That conversation takes an hour, and it saves you a system built the wrong way.

We have written this pattern up as an example scenario in our work. What a project like this costs is on the packages page, and a short conversation is usually enough to tell whether it applies to you.

Bytewerf is an independent software studio in NL.

Bytewerf · KVK 93563639 · VAT NL005027684B59

TermsPrivacy

A data processing agreement is available on request.