Part 1 of this series was about the station where work piles up on the floor. This one is about the station where work piles up in the office, and nobody has put tape around it, because it doesn't look like a station. It looks like an inbox.
Follow one PO through the building
A customer purchase order arrives as a PDF attached to an email. Then:
- Someone in the office opens it and types the part numbers, quantities, due date, and ship-to into the order screen — or into the Access database, or into the spreadsheet that is the order screen.
- Someone prints a traveler, and the floor writes the job number on it by hand, and when the router doesn't match the print rev, someone types the correction somewhere else.
- When it ships, someone types the same part numbers, quantities, and prices into QuickBooks to invoice it.
Three keyings of the same information. Three chances for a 7 to become a 1. The PO said rev C; the traveler said rev B; the invoice said whatever the last order said, because that's what the office copied forward.
Ask the office how long each keying takes and you'll hear "a few minutes." Multiply by every order, every week. Then add the remake — say, one job a quarter cut to the wrong rev because the retype was wrong — and it's no longer a few minutes. It's a station with a queue in front of it and a scrap rate.
The lightweight patch
This is the kind of fix we mean when we say connect what you already have. Not a new system. A small tool that sits next to the one you've got:
- It watches the inbox (or a folder, or a shared drive).
- When a PO and a drawing land, it reads them — part numbers, quantities, dates, revision, ship-to, the customer's PO number — and matches them against your customer and part records.
- It drafts the work order. Not creates — drafts. It puts a screen in front of a human that says: here is what I think this PO is. Here is the part it matched. Here is the rev on the drawing versus the rev we last built. Approve, fix, or reject.
- One click on approve, and the order exists in your system, the traveler is generated from it, and the invoice later comes from the same record.
One keying, done by software, checked by a person. The person's job goes from typist to approver, which is the job they were actually hired for.
Scope: a sprint or two. It runs alongside the Access database, the QuickBooks file, whatever's there. Nothing is migrated. There is little to retrain — the approval screen is most of the training.
Why a patch this small has an outsized effect
It isn't the minutes, though the minutes are real. Three things give this fix an effect out of proportion to its size:
It's on the critical path of every job. Every job the shop will ever run passes through intake first, so time or error removed here comes off the whole shop's throughput, not one corner of it. If the time from PO to floor drops from two days to two hours, that's nearly two days off every lead time you quote.
It removes a whole kind of error, not a percentage. You can't mistype what you didn't type. A rev mismatch between order and traveler stops being a retyping problem, because they're now the same record. What's left is an approval miss, and the screen puts the two revs side by side to catch it. "Keying errors per month" can go to near zero — the kind of KPI (key performance indicator: the number a sprint is judged by) that's easy to commit to.
*It changes what an order is.* This is the one that matters for the rest of this series. Before the patch, an order is a piece of paper that people re-describe to three programs. After it, an order is born as data — one record with a rev, a due date, a routing — that everything downstream can read without a person in the middle. The floor can scan against it. Purchasing can be triggered by it. The books can close from it. And, further down the ladder, another shop can receive it.
You cannot automate a work order that doesn't exist as data. This is the first brick.
What we measure
Each of these is the KPI for the sprint that builds it, written down before the quote:
- Office minutes per order, intake to traveler — before and after.
- Keying errors per month — the rev mismatches, the wrong quantities, the ship-to that went to the old address.
- Order-to-floor time — the hours between the PO arriving and the traveler being on the cart.
If the numbers don't move, the sprint didn't count. That isn't a slogan; it's how the invoice is structured.
Where the reading part belongs
The piece that reads a PDF and proposes a work order is what people now call AI, and it's usually good at it — a messy PO, a customer's homegrown form, a drawing with the rev in the title block. We put it exactly there and nowhere else: proposing, behind an approval. The approval step isn't a limitation we apologize for; it's the product. A shop that lets software release work to the floor unreviewed has traded a typing error for a much more expensive one.
The honest caveats
Some POs are a photo of a handwritten note. Some customers change the quantity in the email body and not on the form. The tool flags what it can't read with confidence and hands it to the human unchanged — the fallback for a bad PO is the process you have today, not a worse one.
And as with the tape in Part 1: if the fix is "stop keying the invoice by hand, pull it from the order," and the software you already own can do that — do that. Two of the three keyings may be yours to delete on Monday.
Next: where this ladder goes if you climb it all the way. Not the robot — the office the robot needs behind it.