Where the manual work actually hides

Most automation projects start with a list of things someone would like automated. That list is almost always wrong, because it is written from the features people can name rather than the work that is actually consuming them. Ask a team what they want automated and you get "the reporting". Watch the same team for a week and the reporting takes an hour, while re-typing order details from an email into a system takes nine.

The work worth automating hides in a specific place, and once you know its shape you can find it in any business in about two days.

Every business runs several systems that were each bought to be good at one thing — a website, a payment provider, an accounting package, a CRM, a spreadsheet somebody built in 2019 that turns out to be load-bearing. None of them were designed together. Between any two of them is a join, and in most businesses that join is a person.

That person is not doing a job. They are being an integration. They read a value out of one screen and type it into another, and the business has come to think of this as their role because it has always been their role. It does not appear on any process document, because from the inside it does not look like a process — it looks like Tuesday.

Across engagements the same four keep appearing, and naming them makes them much easier to spot in a conversation.

1. Re-keying. The same data typed into a second system by hand. The most common, the most automatable, and the one people are least likely to mention because they are slightly embarrassed by it.
2. Chasing. A person whose contribution is remembering that something has not happened yet — an unpaid invoice, an unreturned form, an unapproved quote. This is a scheduling problem wearing a person as a costume.
3. Reconciling. Two systems that disagree, and someone who periodically works out which is right. Usually a sign that neither system owns the record, which is a design problem the automation must resolve rather than paper over.
4. Deciding-that-is-not-deciding. A rule applied consistently but held in someone's head. "If it is over this amount it goes to me first." That is a conditional, and it has been running in a human for four years without documentation.

Not with a workshop. Workshops surface what people believe their process is, which is the tidied version. Four techniques work better, and all of them are observational.

• Follow the copy-paste. Ask to watch a normal task end to end and count how many times something is copied between windows. Each one is a join with a name and a frequency.
• Count the second screens. A person with two monitors showing two systems is usually reconciling them by eye. Ask what they are comparing.
• Listen for "just". "I just check that it came through", "I just export it and tidy it up". The word marks work the speaker has stopped noticing, which is exactly the work that never gets costed.
• Read the shared inbox. Where a business keeps a shared mailbox, the recurring message shapes are a free map of its unhandled processes. Anything that arrives in the same form more than weekly is a candidate.

Two days of this produces a better backlog than two weeks of stakeholder interviews, because you are recording behaviour rather than self-report.

For each join, three numbers, none of which require instrumentation to estimate: how often it happens, how long it takes, and what it costs when it goes wrong. That third one is the one people leave out, and it is frequently the largest. A re-keying join that takes four minutes and happens twenty times a day is a real cost — but a re-keying join that occasionally transposes two digits in a bank detail is a different category of problem entirely.

Frequency times duration tells you what you save. Failure cost tells you what you are actually buying. Sort by the second and you will build different things than if you sort by the first, and usually better ones.

This matters more than the list of candidates, because the failures in this discipline are almost always over-automation rather than under.

• Anything running less than weekly. The build and maintenance will exceed the saving, and you will have added a thing that can break in exchange for very little.
• Anything where the exception rate is high. If a third of cases need a human anyway, an automation adds a second path to maintain rather than removing the first.
• Anything the business is about to change. Automating a process a month before it is redesigned is the most expensive way to discover the redesign was coming.
• Anything where the person in the middle is quietly applying judgement. Watch for the case they handled differently and could explain why. That is expertise, not friction, and automating it removes the check nobody realised was there.

The measure is not how many steps disappeared. It is whether the business can now answer a question it could not answer before — where an order is, why a lead went cold, which supplier is late — without asking a person to go and look. Automations that only save keystrokes are worth doing. Automations that make the state of the business visible are worth considerably more, and they tend to be the same builds approached with a different intention.

The other measure is what happens when it breaks. An automation with no failure path is a liability with good manners: it works for eight months, fails silently in the ninth, and nobody notices until a customer does. Every join we automate gets a defined behaviour for the case where the far side does not respond, and somebody named who hears about it.

The question is never "what could we automate". It is "where is a person acting as glue between two systems, and what does it cost when the glue is on leave".