How to map a business process before automating it

This guide from AR Labs shows owners and managers of small service businesses how to map a business process before buying automation software or asking anyone to build an AI system. It covers how to record the work as it actually runs, find the failures that cost time or customers, mark the decisions a person must keep, and choose the smallest change that fixes the problem. It is the method the other guides in this series apply to specific workflows, and it follows the discovery stage of our client delivery framework. If you have not yet chosen which workflow to map, start with how to decide what to automate with AI.

The worked examples come from our discovery and design work for an in-home music school, described in the case study; that work is a design, not a system in use. Examples from other kinds of business are illustrations.

Why automation projects start in the wrong place

A common way to start is with a tool. Someone sees a demonstration, connects a form to a spreadsheet with an automation service, and finds later that the data moves but the work is no easier, and that the connections are hard to trust when something changes.

What is usually missing is a written account of how the work really runs, where it breaks, and which parts depend on someone's judgement. People describe their work as they think it runs, and that description leaves out the workarounds they no longer notice.

flowchart TD
  I["Idea: 'we should automate this'"] --> T["Choose a tool"]
  T --> A["Automate the visible steps"]
  A --> U["Use it for a while"]
  U --> X{"Does it remove work?"}
  X -->|"no: moves data, adds checking"| W["Workarounds return"]
  X -->|"breaks on an exception"| W
  W --> I

A common pattern: the tool is chosen before the process is understood, so the exceptions and the judgement calls are found by the automation failing.

The method in this guide reverses that order, and its four main moves fit on one small map: draw who touches what, count the failures, mark the decisions that stay with a person, and only then choose a change, starting from the bottom of the ladder of changes.

Step 1: Pick one workflow and name what it produces

What to do. Choose one workflow, not the whole business. Name its trigger (what starts it) and its output (what exists when it is done). Write both in a sentence.

Why. A workflow with a clear output can be measured and finished. "Admin" cannot. Most small-business workflows worth automating share a shape: something incomplete arrives, someone clarifies it, checks it against rules or records, produces a record that others rely on, and a person decides the next step.

Example. "Starts when a family asks about lessons; ends when a student has a confirmed teacher and a standing weekly slot." Or: "Starts when a customer calls with a fault; ends when a technician is assigned with the right parts noted."

• One workflow chosen
• Trigger and output written in one sentence
• The people who do the work identified

Step 2: Watch the work, not just the description of it

What to do. Ask the people who do the work to record their screen during an ordinary session, or sit with them. Ask for at least one session where they talk through what they are doing and why while they work.

Why. Recordings show the inbox labels used as stages, the snoozed emails used as timers and the sticky notes nobody mentions in an interview. Narration shows what silent footage cannot: decisions made from memory. In our music-school work, silent recordings suggested lead intake was the main problem; one narrated scheduling session showed the real cost was joining information from several places, and the design moved accordingly. The discovery method page describes how we analyse recordings.

Screen recordings capture customers' and colleagues' personal data. Get the agreement of the person recording, avoid screens you do not need, keep the recordings somewhere secure and delete them when the analysis is done, under the data-protection rules that apply to you.

Example. An office manager might record an hour of booking jobs and narrate: "I'm checking the map because this customer is on the edge of our area, and I know our senior engineer won't go there on a Friday."

• At least one recording of real work
• At least one narrated session
• Agreement obtained; recordings stored securely and deleted after use

Step 3: Write a log of what happened, separate from what it means

What to do. Turn the recordings into a timestamped list of events: what was done, in which tool, and any sign of time lost, errors or information that went missing. Keep interpretation in a separate document that refers back to the log.

Why. If the log is written to fit a conclusion, it cannot correct you later. Keeping observation and interpretation apart means a surprising finding stays visible instead of being explained away.

Example. "00:14:20 copies availability from form response into spreadsheet cell as text. 00:15:05 re-types the same availability into the scheduling document." The interpretation, kept elsewhere: "availability exists in three hand-made copies."

• Timestamped event log
• Tool named for each event
• Interpretation kept separate, citing the log

Step 4: Map who touches what

What to do. Draw the people and the systems involved, and the information that moves between them. Mark every movement done by hand: re-typing, copying, looking something up and not saving it, remembering.

Why. The hand-carried movements are where errors and delays come from, and where automation can help. A map of people and systems also stays useful for every workflow they share, where a single flowchart covers only one.

Example. In the music school, the map showed families and teachers sending emails, texts and forms to the owner; the owner joining a spreadsheet, a scheduling document, Gmail labels, Google Maps and his own memory; and the administrator re-keying his decisions into the lesson platform.

• People and systems drawn
• Information flows labelled
• Hand-carried movements marked

Step 5: Find and count the costly failures

What to do. Go through the log and list the failures: information re-typed, state held only in someone's head, follow-ups without a recorded reason, errors caught by chance, customers asked the same question twice. Count each kind.

Why. Counts turn "it's chaotic" into something you can act on and measure later, and they stop the loudest complaint from crowding out the most frequent one.

Example. In the narrated music-school session, the owner switched between five working surfaces about 49 times in under half an hour, and 29 of 66 recorded events depended on a fact held only in his head. Those two numbers pointed the design at one shared place for each placement case.

• Failures listed by kind
• Each kind counted
• Consequence noted: time, error, lost customer

Step 6: Mark the decisions a person must keep

What to do. On your map, mark every point where someone makes a judgement: which teacher fits a student, whether a job is an emergency, whether a prospect is a good fit, whether a payment correction is right. Decide which stay with a person, and write down why.

Why. In many owner-run businesses the owner's judgement is the product, and automating it removes what customers pay for. The useful design brings the right information to the decision and handles the routine work before and after it.

Example. The music-school design keeps the owner choosing every pairing and approving every outgoing message, prepared as drafts in his own inbox. The system ranks candidates and shows why each fits; it never chooses.

• Every judgement point marked
• Each one marked "person keeps" or "rule can handle", with a reason
• Money, safety and customer commitments kept with a person

Step 7: Check the map with the people who do the work

What to do. Show the map, the counts and the decision points to the people involved, with the gaps visible, and make it easy for them to disagree. Write down their corrections in their own words.

Why. Your map is a hypothesis until they confirm it. A correction in the owner's words is better evidence than another recording, and it is the point at which evidence gathering can stop.

Example. A correction might sound like this: "You've got the Friday rule wrong: it's not him, it's anyone without a van." The map is corrected, and that rule becomes a field in the record.

• Map shown to the people who do the work
• Corrections recorded in their words
• Evidence gathering closed at a stated point

Step 8: Write the outcome, then choose the smallest useful change

What to do. Write one outcome statement in this shape: "By [change], we will [reduce or increase] [measure] from [now] to [target], resulting in [benefit]." Then go up this ladder and stop at the first rung that achieves it: a written method or a better form; configuring a tool you already own; fixed rules or checks; connecting tools; custom software; AI.

Why. If you cannot fill in the outcome statement, you are not ready to choose a solution. Each rung up the ladder costs more and carries more risk. Any AI step should also beat a simple baseline, such as fixed rules or a trained person, before it is used.

flowchart TD
  W["One workflow, trigger and output named"] --> O["Observe: recordings, narration"]
  O --> L["Event log, kept separate from interpretation"]
  L --> M["Map: people, systems, hand-carried steps"]
  M --> F["Failures counted"]
  F --> J{"Person decides: which judgements stay human"}
  J --> C{"People who do the work confirm or correct the map"}
  C -->|"correction"| M
  C -->|"confirmed"| S["Outcome statement written"]
  S --> R{"Owner chooses: smallest change on the ladder"}
  R --> P["Phase 1, reversible, measured against the baseline"]

The target method. Diamonds are decisions made by people, not by the analysis.

Example. An illustrative statement for a scheduling workflow like the music school's: "By storing availability as structured fields in one record, we will reduce the number of places the owner checks per placement from five to one, so the administrator can prepare placements without him." That design starts from an off-the-shelf CRM (customer relationship management software) and adds custom software only for the scheduling view and the connections between tools that no CRM provides.

• Outcome statement written and agreed
• Each rung of the ladder considered in order
• Any AI step compared against a simple baseline

Step 9: Plan in phases you can stop after

What to do. Split the change into phases. Each phase should leave something working that the business can keep using if the rest never happens, and should increase what the system can do only as trust is earned: copies of data first, then drafts a person approves, then live actions.

Why. Owners' questions about automation are usually about control: what happens if it goes wrong, can we stop, are we locked in. Phases that each stand alone answer those questions, and they keep the business from carrying all the risk of one big build at once.

Example. The music-school plan has three phases: first one shared record and a scheduling workspace, with no automated actions; then automations that match replies and prepare follow-ups for approval; then migration and integration with the lesson platform, after the record is in daily use.

• Phases defined, each useful on its own
• Live actions come after drafts and approvals
• Re-measure against the baseline after each phase

The ladder of changes

The other guides in this series refer to this table. Each row costs more than the one above it, so move down only when the row above has stopped being enough.

Approach	What it involves	Good fit when	Limits
By hand	A written method, a checklist, a better form, a script	The failure is inconsistency or missing information	Relies on people following it when busy
Configure an existing tool	Fields, statuses, templates and reminders in software you own	The tool can do it and nobody has set it up	Bounded by the tool's design
Connect tools	Built-in integrations or an automation service moving data between systems	The same information is re-typed between systems	Each connection needs monitoring and an owner
Build custom	Software for the part no product covers, connected to your existing tools; AI only where a baseline shows it helps	Counted failures remain after the rungs below	Most cost and risk; needs phasing and human approval points

The guides that apply this method to one workflow each cover music school scheduling, tutor matching, service calls for trades firms, client intake for agencies, onboarding for bookkeeping practices, legal consultations and following up enquiries and quotes.

AR Labs offers this kind of discovery and design work to owner-run businesses; more about us is on the about page.