On most factory floors the reports are filled in fine. The cost sits after collection, where one person retypes paper and spreadsheets into a summary. This is how we take that step out without changing how the floor records anything.
None of them is the right answer every time. What decides it is whether your forms hold a stable layout, and whether reading them takes judgement.
| Macros (VBA) | RPA | AI-OCR | AI agent | |
|---|---|---|---|---|
| Input it can take | Data already in a spreadsheet | Fixed screens and file layouts | Scans and photos of printed forms | Paper, photos, and spreadsheets mixed |
| Survives a layout change | No — an edited sheet breaks it | No — a changed screen breaks it | Only after the zones are re-taught | Yes, within the same family of forms |
| Handles judgement | No | No | No — it returns whatever it saw | Yes, with a confidence threshold and review |
| Reconciliation against the original | Not applicable | Not applicable | Left to the reviewer | Built in — unsourced values are held back |
| Who keeps it running | Whoever wrote it — dependent on one person | An RPA specialist | Whoever maintains the templates | Rules and thresholds, changed without code |
| Worth it when | The data is already digital and the rules are stable | The clicks never vary | Forms are printed and identical | Forms vary and the numbers have to be trusted |
Generative models will fill an unreadable field with a plausible number. We trace each extracted value back to its position on the source document, and anything we cannot source never reaches the summary.
Checking everything by hand is not automation; passing everything through unchecked is how bad data ships. Items below the confidence threshold go to a review screen. The rest flow straight through.
Send one form and we will read it and show you the result. Faster to judge than any document we could send you.
Talk to us about your forms →We work remote-first: requirements, data handover, and verification all happen online. Visits to the floor are an option, not the premise.
Show us one of your current reports. We will tell you which steps can come out and roughly how much time that returns.
We test reading accuracy against real documents and deliver a process inventory, an ROI estimate, a decision on where the system should sit, and a quote for the rollout.
One line or one department first, with output shaped to the summary you already use. Data moves over a channel you approve.
We widen the scope while tracking the error rate, and keep up with changes to your forms.
No, and the design assumes you will not. Different layouts per line are handled on our side. If the fields are genuinely freeform, verification is where we find out how far that goes — on your actual documents, not in principle.
Anything unreadable, or below the confidence threshold, is held out of the summary and sent to a review screen. Someone corrects those fields only. Nobody re-checks the whole batch, and a wrong value does not quietly enter the numbers.
Not necessarily. Input is never used to train external models in any configuration. Where information cannot leave at all, the system runs entirely inside your network. You decide where the data sits.
It has not. Requirements, sample handover, and verification all run online, which usually makes the first three weeks faster than scheduling site visits would. On-site work is available where it genuinely helps.
Deciding whether to go further is easier once you have seen what came back off your own document.
What the first three weeks cover, what you get at the end of them, and how we decide where the system should sit.
See how we run a project →One shift report is enough for us to show you what can be read and what would need review.
Talk to us →Drawings, costing, and supplier information often cannot go anywhere. Tell us the constraint and we will describe a setup that fits it.
Talk to us about constraints →