Your paperwork is a mess. Here's what actually has to be true

Somewhere in the first ten minutes of nearly every conversation about automating something, the same sentence arrives, usually with an apology attached: our records are a state.

They usually are. Job numbers written four ways. Delivery slips that are photographs of delivery slips. A customer who is Smith Builders in the accounts system, Smith Builders Ltd on the invoices, and “Dave” in the dispatch notes. Field notes on the back of a card in somebody's van. The shared drive with folders called 2019 final and 2019 final USE THIS.

None of that is disqualifying, and I want to be specific about why, because “we'll need to clean the data first” is how a lot of these projects die of exhaustion before they start. Tidy is not the requirement. There are about four things that genuinely have to be true, and the rest is noise you can live with.

The four things that actually matter

It has to exist somewhere. Written down, photographed, recorded, typed — the form barely matters. What kills a job is when the information only ever lived in someone's head and got acted on: the reason the delivery was short, the reason that job took two extra days. No system can learn a thing nobody ever recorded.

You have to be able to get it out. This is the real blocker far more often than mess is, and it has nothing to do with how tidy your records are. If your dispatch system has no export and no way in except the screen, that's a wall. If your supplier's portal shows you the slips but won't give you the file, that's a wall. Neat records inside a locked box are worse than messy ones in a folder.

The same thing needs to be findable under its different names. Not standardised — findable. If Smith Builders has three spellings, that's fine as long as somebody can tell me they're the same firm. Which they can, immediately, because they've worked with them for nine years. What isn't fine is nobody knowing.

The hard cases have to be in there. This is the one people get backwards. The instinct is to send over the clean examples, because that is what you would send anybody. What I want is the ugly ones: the slip photographed at an angle in the cab, the handwritten note with the job number that has a letter in it, the PDF that's actually a photo of a fax. Twenty bad examples teach more than a thousand tidy ones, because the tidy ones were never the problem.

Start by finding out what you've actually got

Before deciding anything, spend an afternoon writing down where the material lives. It's always in more places than the owner expects.

The project or job management system. The accounts package. A shared drive full of spreadsheets, each one somebody's private system. The estimator's email, which is where the submittals really live. The printer that emails scanned PDFs to one address nobody reads. Photos on four phones. The WhatsApp group, which counts, and is frequently where the exceptions get reported. A filing cabinet. A box in the truck.

For whichever pile the job actually depends on, get concrete about it. Take one week of it, count what you have, and write the answers down:

Delivery slips, week of <date>

- Slips received:            <count>
- Arrived as: PDF / photo / paper / portal   <count of each>
- Legible without squinting: <count>
- Carry a readable PO number: <count>
- Carry a readable date:      <count>
- Line items match the order: <count checked, count matching>
- Where the copy ends up:     <inbox / drive folder / cabinet>

That page tells you more than any conversation about data quality. If four in five slips arrive as photographs and a third of them have a thumb over the corner, that's a real constraint and it's better known now than after a build.

The mess that matters and the mess that doesn't

Some of it is cosmetic and some of it will actually bite.

Doesn't matter much: inconsistent formatting, dates written in different orders, extra spaces, mixed capitals, four ways of abbreviating “quantity”. These are mechanical to fix and they get fixed once.

Matters: units that silently disagree. Cases against each. Pallets against cartons. Hours against days. If half your records say 12 and mean 12 units while the other half say 12 and mean 12 cases, nothing downstream can tell the difference, and neither can you six months from now.

Matters: the same job entered twice by two people who each thought the other hadn't. Duplicates aren't just clutter — anything counting or learning from your records will treat that job as twice as common as it is.

Matters more than anything: gaps that aren't random. A field that's empty half the time is not necessarily a problem. A field that's empty except on warranty jobs, because that's the only time anybody's made to fill it in, is a trap. Anything reading those records learns from the ones that happen to be complete, and warranty jobs are not a fair sample of your work.

Your records show what you managed, not what people wanted

This one is worth slowing down for, because it's subtle and it's the mistake that produces a confident, useless system.

Your dispatch records show the jobs you took. They do not show the calls that rang out at 9pm and went to somebody else, because those never became records. Feed a system that history and ask it when you get emergency work, and it will tell you — correctly, according to the data — that almost nothing comes in after hours. It has learned the shape of your answering capacity and called it demand.

Same shape, different trade: a stock history that doesn't distinguish “nobody ordered it” from “we were out of it” will teach a forecast to keep you out of the parts you keep running out of. A line-inspection record that only logs the defects somebody had time to write up tells you about the quiet shifts, not the bad ones.

Nobody can spot this from the data alone. It takes someone who knows the work saying “hang on, that's not right, we just stopped logging those in March”. Which is why the person who does the job has to be in the room when the records get looked at, and why I'd rather have an hour with your dispatcher than a week with your database.

What “enough” looks like

There's no threshold number of records, and anyone who gives you one is guessing. What matters is how many examples exist of the rarest thing you care about.

If you want a system that flags short deliveries, the question isn't how many slips you have, it's how many short ones — and if the answer is that it happens about once a month, that's the number governing the whole exercise, not your ten thousand tidy slips. If you want after-hours calls sorted into urgent and not, the question is how many genuine emergencies are in there, not how many calls.

That usually reframes the conversation usefully. Often you don't need more data, you need six months of it looked at properly.

Don't clean everything first

The instinct is to sort the records out and then automate. It's the wrong order, and a records cleanup with nothing attached to it never finishes, because nothing tells you when to stop.

Do the opposite. Take the material as it is, warts included, run it through, and let the failures tell you which mess actually matters. You'll find that most of the untidiness makes no difference at all, and one specific thing — the units, the missing PO number, the three spellings of one customer — is causing nearly all of the errors. Fix that one thing. Run it again. That's a week of work with a visible end, rather than a quarter of tidying.

Keeping it from going back to a mess

Whatever you fix will drift back unless something holds it. Three things do most of the work.

One person owns it. Not a committee, not “everybody's responsible” — one named person who decides how a customer gets spelled.

Fix it where it's entered, not after. If a driver can photograph a slip in a way that cuts off the corner, they will, so the fix is a phone that says “I can't read the bottom, take it again” while the driver is still standing there. Anything corrected downstream gets corrected forever.

Watch the change, not the number. A weekly note saying most slips came through readable means nothing on its own. The same count sitting next to last week's means everything, because a sharp drop tells you a supplier changed their form or somebody's phone camera got cracked, and that's the alert you actually want.

Where the compliance bit sits

If your records include people — customer addresses, gate codes, recorded voicemails, photographs of the inside of somebody's house — those carry obligations, and putting them into a system doesn't shed the obligations. It's rarely complicated at your scale, but it should be a decision somebody made rather than something that happened. Know what's being stored, know where, and know how you'd delete a customer's records if they asked, before somebody asks.

Watch one go through

The quickest way to see what this looks like is to watch one document go through it. I built a demo that reads a delivery slip and pulls the numbers off it: extract a sample delivery slip. The slip is fictional. What's worth looking at is which fields it commits to and which ones it hedges on, because that hedging is the behaviour you want on your real ones.

Then book a call and tell me what shape your records are in. Bring the bad ones. I'd rather find out on a Tuesday afternoon that a job can't be done than after you've paid for it.