Map how the work really runs before you automate anything

You've decided a routine job should be handed off: to software, to a new hire, or to an AI worker. Someone writes the steps down from memory. Then it goes live and trips over the thing nobody wrote down, like the customer whose invoices go to a different address or the approval that only happens when Mike is in.

Before you automate a job, watch it done on real cases and write down every step as it actually happens: who does it, what starts it, which systems and files they touch, where it waits, where someone decides, and every exception. Map how it runs today, agree on one way it should run, and only then decide what to hand off.

What does skipping this step cost?

Usually it doesn't cost anything on day one. It costs later, in three ways:

• The automation handles the normal case and fails on the rest. If a fifth of cases are exceptions, someone ends up doing those by hand, plus checking the automated ones, plus fixing what went wrong in between.
• The tool is set up around the procedure in the binder, not the one people use. So people go back to their workaround, and you pay for both.
• Nobody can say whether it worked. If you never measured how the job ran before, you can't show it runs better after.

For example, a business hands off invoice reminders, but its biggest customer pays only against a monthly statement sent to a separate accounts payable address. Nobody mentioned it because the bookkeeper "just knows." The reminders go to the wrong person, the customer complains, and the project is judged a failure for a reason a one-hour sit-down would have found.

Why don't written procedures match how the work really runs?

• Workarounds become the real process. The software doesn't do something, so a person fills the gap, and the gap-filling never gets written down.
• Exceptions live in memory. "Oh, that one's different because..." is where most of the real know-how is.
• Two people do it two ways. The morning person and the afternoon person each learned it differently, and both are partly right.
• Hidden checks. "I always look at the customer's history first," or "anything over $5,000 I run past the owner." These are decisions, and they're invisible until you watch.
• Invisible cleanup. Someone fixes a name, a date or a code before entering it. The data looks clean only because they cleaned it.
• Timing. The job behaves differently at month-end, in tax season or in the busy season.

How do you map a job yourself?

You don't need software or training. You need a person who does the job, a spreadsheet and about two hours across two weeks.

1. Describe the job in one sentence. "When [something happens], [who] does [what] using [which tools] until [the finish line]." If your team can't agree on that sentence, that's the first finding.

2. Go and watch it on real cases. Lean practitioners call the place where the work actually happens the gemba, and the Lean Enterprise Institute pairs it with "go and see": observe and ask questions where the work happens before you act. For office work that means sitting beside the person, or on a screen share, while they handle three recent cases from start to finish. Ask them to talk as they go. Don't fix anything yet.

3. Write each step on its own row.

Your rows will differ.

4. Mark every decision. Highlight each row where someone judges rather than follows a rule. Write the rule if there is one ("over $5,000 goes to the owner") and note where there isn't one ("depends on the customer"). These rows matter most later, because they're where a person stays in the loop.

5. Collect the exceptions. Ask, "What was the strangest one last month?" and "What do you do when the usual way doesn't work?" Then for two weeks, have the person tick each case as normal or exception, with a few words on why. Now you know how big the exception pile is.

6. Follow the information. The Lean Enterprise Institute describes value-stream mapping as diagramming every step in both the material and the information flows. For office work, information is most of it. For each piece of information, ask where it comes from, where it goes and who retypes it in between.

7. Agree on one way. Lean practice calls the map of today the current state and the target the future state. Sit down with everyone who does the job, settle the differences, and write the agreed version. Fix obvious breakage first. Automating a step nobody needs just makes it faster.

8. Write down what "working" would mean. Three to five statements you can check, such as "every overdue invoice gets a reminder within two days" or "no reminder goes to a customer marked 'statement only'." Then keep a set of past cases where you already know the right outcome, so any tool or person can be tested against them.

When does doing it yourself stop working?

Mapping is simple, but it takes time from the people who are busiest. It stops working when:

• the job crosses three or more systems and nobody understands all of them;
• the people who do it disagree and nobody has the authority, or the time, to settle it;
• the data is messy enough that cleaning it is a project of its own;
• the one person who knows the job is leaving, and there's no time for a calm sit-down.

What are your options?

What can you hand off, and what should stay with your team?

You can hand off the watching, the note-taking and the counting. Someone outside the job often sees the workarounds more clearly, because they don't take them for granted.

Keep three things with your team. Agreeing on the one way the job should run is a management decision. Deciding which of the marked decision rows stay with a person is yours: the rows where a mistake would be costly or hard to undo should stay human, at least at first. And approving the written definition of "working" is yours, because it's how you'll judge anyone you hire, including an AI worker.

If the job involves customer data, map it with care. Ask before recording anyone's screen or call, since some states require everyone's consent, and remove customer details from anything you share outside the business. Share samples, not full exports, and only with people who need them.

Questions to ask anyone you hire, us included

1. Will you watch the job done on our real cases, or work from our description?
2. How will you find the exceptions, and how will you count them?
3. Who settles it when our people do the job differently?
4. What will we have at the end of the mapping, even if we stop there?
5. What's the written definition of "working," and when do we agree it?
6. Which steps do you think should stay with a person, and why?
7. What access do you need to see the work, and what will you do with recordings and samples?

The Operator page explains how we run an AI worker, human-in-the-loop AI explains where the person sits once a job is handed off, and the walk-through is a free 30-minute call about a job you're thinking of handing off.

FAQ

How long should mapping one job take? For a job done weekly or daily, two sit-downs on real cases and two weeks of tallying exceptions are usually enough to see its shape. A job that only happens at month-end needs a month-end to watch.

Do we need flowchart software? No. A spreadsheet with one row per step works, and it's easier for your team to correct.

What if the map shows the job shouldn't be automated? That's a good result. Some jobs are mostly judgment or relationships, and they're better left with people, or fixed in the software you already use.

Who should we watch? The person who does the job most often, and ideally a second person who does it differently. The differences are where the useful questions are.