Mapping a Process Before You Automate It
Why this matters
An automation does exactly what the process does, only faster and without anyone noticing. If the process has a hole, say a declined estimate that lives in a call note instead of the estimate's status, the automation drives straight through the hole on every record, every day. Mapping first is the hour that tells you where people are quietly using judgment, because those are the places a rule will get wrong. Skip it and the first sign of trouble is a customer asking why you are chasing them for a job they turned down last week.
A few terms used below. A process map is a drawing of the boxes (the things that get done) and the handoffs between them (the moments work passes from one person or system to another). A decision point is anywhere someone looks at the situation and chooses. An exception is a real case that does not follow the main path.
Step 1: Pick one process with a clear start and a clear finish
Name the event that starts it and the event that ends it, in terms your software can see. "Estimate status changes to Sent" starts it; "estimate is Signed, Declined or Expired" ends it. "Follow-up on quotes" is not a process you can map, because nobody can say when a given quote enters or leaves it.
Why first: an automation needs a trigger, and the trigger is the start event. If you cannot name one, there is nothing to automate yet. What breaks if you skip it: the map sprawls into three processes at once (quoting, follow-up, financing), and the rule you build later fires on the wrong event.
Step 2: Pull 20 real records and walk them with the people who did the work
Take the last 20 records that went through the process, not a hypothetical. Sit with whoever touched them, usually a tech and someone in the office, and go through each one: what happened, who did it, where it got written down. Twenty is a common starting point for a shop doing a few dozen a month; it is enough to surface the exceptions that happen more than once and small enough to finish in an hour.
Why real records: people describe the process as it is supposed to run. The records show how it runs. The gap between the two is exactly what an automation will trip over. What breaks if you skip it: you map the policy, automate the policy, and the policy is not what anyone actually does.
Step 3: Draw the boxes and the handoffs, with where the information lives
On paper or a whiteboard, one box per thing that gets done, an arrow for each handoff, and a label on each box saying who owns it. Then the part people leave out: next to each box, write where the information produced there is recorded. The estimate's status field. A call note. The tech's head. A lender's website.
Why: a rule can only read data. Anything recorded only in a note, a text thread or someone's memory is invisible to it. What breaks if you skip it: you design a rule around a fact the system does not actually hold.
Step 4: Mark every decision point and say who decides
Go back over the map and put a mark wherever a person chooses: whether to follow up, how hard to push, whether a revised quote replaces the old one. For each, write who makes the call and what they look at to make it.
Why: every decision point is a place a person is currently filtering cases out. An automation removes the person, so it removes the filter. What breaks if you skip it: the rule fires on cases the person would have quietly skipped, and nobody realizes the person was doing that until the complaints arrive.
Step 5: Count the exceptions from your 20 records
For every record that left the main path, write what happened and count how many times each kind occurred. A count matters more than a list, because it tells you which exceptions the automation must handle and which can be handled by a person after the fact.
Why: an exception that occurs in 7 of 20 records is the process, not an exception. What breaks if you skip it: the rule is built for the main path, and the main path turns out to be the minority.
Step 6: Fix the process on paper before you build anything
For each exception you counted, decide how the fact that creates it gets into a field the rule can read. Usually that means a status or a tag, set by the person who learns the fact, at the moment they learn it. Write who sets it and when.
Why: the fix is almost always a data change, not a cleverer rule. What breaks if you skip it: you write a rule that tries to guess from indirect clues, which works until it does not.
Step 7: Automate only the path the data can decide
Write the rule so it fires only where the record itself says what to do. Everything else gets a hold: no message, and a task to a named person instead. A rule that covers 80 percent of cases correctly and routes the rest to a person beats one that covers 100 percent and gets a third of them wrong.
Step 8: Dry-run the rule against the same 20 records
Before switching anything on, take the 20 records and write down, for each, what the new rule would have done. Compare it with what should have happened. Any mismatch is either a branch you have not handled or a field nobody sets.
Why the same 20: you already know the right answer for each one, so a mismatch is unambiguous. What breaks if you skip it: your first test is live customers.
Worked example: the day-3 estimate follow-up
A seven-person electrical and generator shop sends around 20 estimates a month. The owner wants a text on day 3 to anyone who has not signed: "Just checking you got the estimate, any questions?" The software can do it in two clicks. They mapped it first.
The map they drew from last month's 20 estimates:
TECH (truck) OFFICE (desk) CUSTOMER
+------------+ +--------------+
| builds the |---->| checks, sends|-----> reads it
| quote | A +--------------+ B |
+------------+ | ^ |
| | C: calls office v
+---------+------------ decides
A: some techs send from |
the truck, office box +---------+---------+
skipped | | | | |
sign no bank us quiet
| | | | |
where it is recorded: status note site note status
Read across the bottom row: of five outcomes, only two leave a trace in the estimate's status. "No" is a note from a phone call. "Bank" is a financing application sitting on the lender's site. "Us" means the customer is waiting on the shop, in this case for a manufacturer's warranty approval on part of the job, recorded only in a note.
The counts from the 20 records:
- 8 signed within 3 days and never needed a follow-up.
- 12 were still in Sent status on day 3. Of those 12:
- 3 had declined by phone (note only)
- 2 were waiting on financing (lender's site)
- 1 was waiting on the shop's warranty approval (note only)
- 1 had been replaced by a revised estimate, so the old one was still in Sent beside its successor
- 5 were genuinely quiet
That closes: 3 + 2 + 1 + 1 + 5 is 12, and 8 + 12 is 20. The blind day-3 rule would have sent 12 texts. Five were appropriate; seven were wrong. That is 7 of 12, or about 58 percent of the messages the rule would have sent, going to people who had declined, were waiting on a bank, were waiting on the shop itself, or were holding a newer quote. The customer waiting on the warranty approval would have been asked if they had questions about a job the shop was holding up.
The decision points the map exposed. The office manager had been deciding, by memory, whom to call. That was the filter. Removing her from the loop without replacing her judgment with data would have removed the filter.
The fix (Step 6). Three statuses added: Declined, Waiting on Financing, Waiting on Us. Whoever takes the call or learns the fact sets it at the time; the office manager owns checking that new notes have a matching status at the end of each day. Revising an estimate now marks the old one Superseded. And techs sending from the truck now trigger the same record update the office send does, which closed handoff A.
The rule (Step 7). Day 3, status still Sent, no newer revision, customer not opted out of texts: send. Anything in Waiting on Us creates a task for the office manager instead, because the shop owes the next move.
The dry run (Step 8). Against the same 20, the new rule sends 5 texts, all to the 5 genuinely quiet customers, and creates 1 task for the warranty case. Zero mismatches. They switched it on.
What would change the answer. If most estimates were signed on site, there would be almost nothing to follow up and the right move would be to skip the automation. If the shop sold mostly to property managers who approve through a purchase order system, "quiet" would mean "in an approval queue", and a day-3 nudge would be noise; the follow-up would key off the PO instead.
How to check the map was good enough
- Every outcome on the map has a field. If any outcome is still recorded only in a note or a third-party site, the rule cannot see it and will treat it as the main path.
- The dry run had zero unexplained mismatches. A mismatch you "will fix later" is a wrong message waiting for a customer.
- Each new status has an owner and a moment. "Someone marks it Declined" is not an owner. "Whoever takes the call, before hanging up" is.
- Re-pull 20 records a month after launch. Count how many reached the rule with a status that was stale. If the count is above zero, the fix in Step 6 is not being followed, and the rule is quietly reverting to the blind version.
Once the rule is live, every later change to it goes through a written change process rather than a quick edit. See related: The Automation Change-Control SOP.
References
- See related: Automation Versus AI: Two Different Tools
- See related: The Automation Change-Control SOP
- See related: The Automated Reminder That Annoyed Every Customer
- See related: The Follow-Up Automation Worth Setting Up Once