Map the Process Before You Automate It

Most automation projects that run over budget do so because the process was never fully described before the build started. The exceptions, the second approver, the spreadsheet nobody mentioned. This checklist is the audit we run at the start of every engagement. Work through it yourself and you will arrive at any vendor with the answers they would otherwise charge you to discover.

Do this for one process at a time, sitting with the person who actually performs it. Tick an item only when the answer is written down somewhere, not when you think you know it.

Process Audit Checklist

One process at a time. Tick an item only when the answer is written down.

0 of 24 complete0%

Your ticks are saved in this browser, so you can work through the list over several sessions.

01Trigger and inputs

0/5

What starts the process and what it needs to begin.

The trigger event is identified and a system can detect itAn email arriving, a form submitted, a date passing. Not a phone call or a person remembering.
Every input is listed with its source and formatPDF, email body, form fields, spreadsheet row, API payload, and which system or person each comes from.
Mandatory inputs are separated from optional onesWhat must be present for the process to start, and what happens when a mandatory input is missing.
Input quality is described honestlyHow often inputs arrive incomplete, in the wrong format, or as a photo of a handwritten form.
Duplicate and repeat triggers are accounted forWhat happens if the same item arrives twice, or the trigger fires again after the work is done.

02Systems and data

0/5

Every place the process reads from or writes to.

Every system touched is listed, including spreadsheets and email foldersIf information is written down between steps, the place it is written is a system.
Each system is marked as read, write or bothWriting to a system needs more care than reading from it, and usually a different permission.
API or export access is confirmed for each system, including licence tierMany products only expose an API on higher plans. Check the plan you are on, not the marketing page.
The authoritative source is named for every field that exists in two placesWhen the CRM and the accounting system disagree on a customer address, which one wins.
Personal, financial and health data is identified and its handling recordedWhere it is stored, who may see it, how long it is kept, and whether it may go to a third-party service. Obligations under the Australian Privacy Principles carry over to the automation.

03Decisions and exceptions

0/5

Where the process branches and where it breaks.

Every decision point is listed with the rule that decides itIf the rule cannot be written down, note that it is a judgement call and who makes it.
Approval points are listed with the approver and the thresholdWho approves, above what value or condition, and who covers when they are away.
Known exceptions are listed with how often each occursCount them from last month if possible. The exceptions decide the build cost, not the happy path.
The action for each exception is definedHandled by a rule, routed to a named person, or held until someone decides.
Variations between operators are documented and one path chosenIf three people do it three ways, the owner picks the way the automation will follow.

04People, volume and time

0/5

The baseline the automation will be measured against.

A named owner is accountable for the outcomeThe person who will answer for the result after automation, and who reviews the exception queue.
Everyone who touches the process today is listed with their stepIncluding the person who is only involved when something goes wrong.
Monthly volume is taken from the source systemCount records, emails or orders for the last three months. Note peaks such as month end.
Current time per item is measured on real itemsTime three items with a stopwatch from trigger to completion, including switching between systems.
Current error rate and rework are measuredCorrections, credit notes, re-deliveries and complaints from last month, divided by volume.

05Measures, failure and controls

0/4

How success is judged and what happens when it goes wrong.

At least one KPI is agreed and its current value recordedTurnaround time, items per person per day, error rate or backlog size, measured today.
The failure path is designed: who is told, what they see, what they doFailed items must be visible to a named person, with a time limit before they matter.
The manual fallback is written downHow to run the process by hand if the automation is switched off for a day or a week.
Actions that must never run unattended are listedPayments, deletions, customer-facing sends above a threshold. Each needs a human approval step.

Book a free process audit

A general audit framework. Add items for regulated processes, and treat the data sensitivity item as a starting point rather than legal advice.

Why Mapping First Saves Money

A process map is the specification for the automation. Every gap in it becomes a question during the build, and questions during the build are billed by the hour.

The map is the scope

A quote can only be as accurate as the description it is based on. When the trigger, inputs, systems and exceptions are written down, the vendor can price the actual work. When they are not, the quote covers the simple path and everything else becomes a variation.

Exceptions decide the build cost

The happy path is usually quick to automate. The cost sits in the cases that do not fit: the supplier who sends two invoices in one PDF, the customer who orders by phone, the approval that goes to someone different in December. Finding these before the build is the whole point of the audit.

You cannot measure improvement without a baseline

Volume, current time per item and current error rate are the numbers the automation will be judged against. Capture them now, from the source system, before anything changes. After go-live they cannot be reconstructed.

How to Run the Audit

Five sections, twenty-four items. Most single processes take two to three hours to audit properly, spread across two conversations.

1

Sit with the operator

Watch the person perform the process on real items. Ask what they do when something does not fit. Write down what actually happens, not what the procedure document says.

2

Follow the data

For each step, note which system is opened, what is read, what is typed and where the result goes. Every system touched is a connection that has to be built.

3

Pull the numbers

Get monthly volume from the source system, time three real items, and count last month’s corrections. These become the baseline the automation is measured against.

4

Check with a second person

If more than one person performs the process, have another one review the map. Differences between them are undocumented variation, and each one is a decision to make before building.

The Items Most Audits Miss

Four areas that are routinely skipped because they seem obvious or uncomfortable, and that generate the most rework when they surface during a build.

The real trigger

People describe a process as starting when they begin working on it. The real trigger is earlier: an email arriving, a form submitted, a date passing, a stock level dropping. An automation needs to detect the trigger, so it has to be something a system can see. If the trigger is a phone call or a conversation, that is the first thing to redesign.

Ask what event causes the work to exist, not when someone starts it
Confirm the trigger is visible to a system, not only to a person
Note whether items can arrive in batches or out of order
Record what happens if the trigger fires twice for the same item

Systems that are not officially systems

The spreadsheet on a shared drive, the notebook on the desk, the email folder used as a queue, the WhatsApp group where approvals happen. These carry real process state and are invisible in a systems inventory. Each one either gets replaced by the automation or becomes an integration nobody planned for.

Ask where information is written down between steps
Look for lookup tables kept in spreadsheets or on paper
Find approvals that happen in chat or by phone
Decide for each one: replace it, integrate it, or leave it manual

What happens when it fails

Every manual process has an informal recovery path: someone notices, someone phones someone, the item gets done late. An automation needs an explicit one. Who is told, what they see, how the item is retried or handed to a person, and how long it can sit before it matters. These are design decisions, and they are cheaper to make now.

Define how a failed item is surfaced and to whom
Decide whether failures retry automatically or wait for a person
Set the time limit after which a stuck item becomes a problem
Write down how to run the process manually if the automation is off

Data sensitivity and who may see it

A process that handles personal information, health details, payroll or financial data carries obligations under the Australian Privacy Principles, and the automation inherits them. Record what personal information is handled, where it is stored, who can access it and how long it is kept, before deciding which tools and which hosting are acceptable.

List every field that identifies a person or their finances or health
Note where the data is stored today and where it would be stored after
Confirm who is permitted to see each category of data
Decide whether any data may leave Australia or be sent to a third-party AI service

Next Steps

Automation Readiness Assessment

Score the business-wide foundations that decide whether the mapped process will build cleanly.

Assess readiness →

AI Agent vs RPA Decision Quiz

Now the process is mapped, work out which kind of automation fits it.

Take the quiz →

Automation Implementation Checklist

The five-phase rollout plan for after the map is done and the build is approved.

Plan the rollout →

Frequently Asked Questions

How long should a process audit take?

For a single process, two to three hours of real work, best spread across two sessions. The first session is watching the operator and drafting the map. The second, a few days later, is checking the draft with a second person and filling the gaps that came up. Audits that take a full day are usually trying to cover several processes at once, and the result is a shallow map of each. Do one properly, automate it, then do the next.

Who should be in the room?

The person who performs the process most often, and whoever owns the outcome. Not their manager’s manager, and not the vendor at first. Operators know the exceptions and the workarounds. Owners know what the result is for and what a failure costs. If those are the same person, add a second operator if one exists. Vendors are useful in the second session, once there is a draft to react to.

What if the process is done differently by different people?

That is a finding, not a problem with the audit. Document each variation and put them side by side. Often one version is better and the others are habit. Sometimes the variations reflect genuine differences in the items being handled, in which case they are decision points that belong in the map. Either way, the automation will follow one defined path, so the decision about which path has to be made before the build, by the owner, on the record.

How detailed does the map need to be?

Detailed enough that someone who has never done the process could follow it and produce the right result on a normal item, and would know what to do with an abnormal one. A page or two of numbered steps with the system and the data at each step is usually sufficient. Flowchart tools are optional. The test is whether a vendor could quote from it without needing to interview the operator again.

Do I need a KPI for every process?

You need at least one measure that will show whether the automation worked, and it has to be measurable today so there is a baseline. Time from trigger to completion, items processed per person per day, error rate, and backlog size are the usual candidates. Pick the one the owner actually cares about. A process with no measurable outcome is hard to justify automating, because nobody will be able to say afterwards whether it helped.

What is the free process audit this site offers?

It is this checklist, run by us with your team, for one process, at no charge and with no obligation. We map the process, capture the baseline numbers, identify the exceptions and tell you honestly whether it is a good automation candidate and roughly what a build would cost. If you have already worked through the checklist yourself, the audit is shorter and the estimate is more accurate.

Worked Through the List?

Send us the map. We will review it, point out the gaps we see in most audits, and tell you which parts of the process are worth automating first. If you would rather we ran the audit with you, that is the free process audit.

Book a free process audit Read the workflow automation guide