Business Process Mapping: A One-Week Audit Before You Automate

You want to automate, but every vendor demo makes a different promise, and nobody on your team can say which process should go first. Business process mapping solves that: before you buy anything, you write down how the recurring work really happens today. This guide gives you a one-week process audit that a small team can run with a spreadsheet and a whiteboard, ending with a ranked list of what to automate first and a clear definition of success for the first two projects.

Why buying tools first usually backfires

Most small companies start automation from the tool side. Someone sees a good demo, the company signs up, and then the team looks for something to automate with it. That order causes predictable problems:

• You automate the visible task, not the expensive one. The process that annoys the owner is not always the one that eats the most hours or causes the costliest mistakes.
• You automate the happy path only. The demo shows the clean case. Your real process has exceptions: the customer who pays in two parts, the supplier who sends invoices by post, the order that needs a manager's OK. If nobody wrote those down, the automation breaks on the first one.
• You lock in a broken process. Automating a step that should not exist just makes a useless step faster.
• Nobody knows if it worked. Without a picture of the "before", you cannot measure the "after".

A short audit fixes all four. It also makes the tool decision easier, because you know which systems the first processes touch and what the automation has to handle.

Business process mapping: what this audit is (and isn't)

A process audit, in the sense we mean here, is a structured look at the recurring work in your company, done with the people who do it. The output is three things:

1. A process inventory: a list of recurring work, with rough volume, time and pain points.
2. A map of one or two processes end to end, including the exceptions.
3. A ranked shortlist of automation candidates, with a success measure for the top two.

It is not a BPMN modeling project, a quality certification or a consulting report that sits in a drawer. You do not need special software. Sticky notes, a whiteboard or a shared spreadsheet are enough for a team of 5 to 50 people. Aim for "good enough to decide", not "complete documentation of the company".

Plan for about one week of elapsed time, with only a few hours of effort spread across the team:

Step 1: List the recurring work with the people who do it

The person who does the work knows the real process. The manager knows the intended one. You need both, but start with the first.

Run short interviews

Talk to each person who handles recurring work for 20 to 30 minutes. Keep it informal. These questions work well:

• What do you do every day or every week that follows roughly the same steps?
• Where do you copy information from one place to another?
• What do you wait for? Who or what usually holds things up?
• What goes wrong, and how do you notice?
• If you were away for two weeks, what would pile up?

Write down every recurring task they mention, in their words. Do not judge or solve anything yet.

Build the inventory

Put each process in a row of a shared spreadsheet. One row per process, not per step. "Processing a new order" is one row; "copy order into the warehouse sheet" is a step inside it. For each row, capture:

• a short name and the trigger (what starts it: an email, a form, a date, a phone call)
• the systems involved (email, shop, accounting, spreadsheets, CRM, chat)
• the people involved
• how often it happens (per day, week or month)
• roughly how long one run takes
• what goes wrong, and what a mistake costs

Rough estimates are fine. "About 20 times a week, 10 minutes each" is more useful than a precise number nobody can agree on. If two people give very different estimates for the same process, note both: the gap itself is a finding.

Small teams often end up with 15 to 40 rows. If you see the same kind of work show up again and again, our overview of business processes worth automating can help you group and name them.

Step 2: Map one process end to end, including the exceptions

You do not map everything. Pick one process from the inventory that looks important and that people complain about, then map it properly. Mapping a single process well teaches you more than sketching ten.

How to map it

Get the two or three people who run the process in front of a whiteboard or a shared document for about an hour. Then:

1. Start at the trigger and end at the result that matters (the invoice is booked, the customer has the goods, the new hire can log in).
2. Write each step as verb plus object: "check stock", "create invoice", "email tracking number".
3. Note who does it and in which system. If the step moves between people or systems, that handoff is worth marking. Handoffs are where things wait and get lost.
4. Mark decisions as questions with two or more exits: "Is the item in stock?", "Is the amount above the approval limit?".
5. Walk through real recent cases, not the ideal case. Pull up last week's orders or tickets and trace them.

Collect the exceptions

This is the part most mapping exercises skip, and it decides whether an automation survives contact with reality. Ask:

• What happens when information is missing or wrong?
• Which customers, suppliers or products are handled differently?
• What did you have to fix by hand last month?
• When does someone have to make a judgement call?

List each exception with a rough frequency. Some will be rare enough to keep manual. Others happen every day and must be part of the design. A process where every second case needs judgement may be a candidate for AI support rather than fixed rules; our comparison of agentic workflows and traditional automation explains that trade-off.

Fix before you automate

Mapping often shows steps that exist for historical reasons: a report nobody reads, a double check that a system already does, an approval that is always granted. Remove or simplify those first. It costs nothing and makes any later automation simpler.

Step 3: Score each process by volume, error cost and stability

Now go back to the full inventory and score each process. The goal is a simple, transparent rule that the team can argue about, not a precise model.

A simple scoring rule

Rate each process from 1 (low) to 3 (high) on four criteria:

Add the four scores for a total between 4 and 12. Treat the result as a conversation starter. A process that scores 11 but depends on a system you plan to replace next quarter is not a good first project. A process that scores 8 but is a daily source of stress may be.

Watch for two traps

• High volume, unstable rules. If the process changes every few weeks, automation becomes a maintenance job. Stabilize the process first, or automate only the stable part.
• Low digital input. If the trigger is a phone call or a paper form, the first project may be getting the input into a digital form (a web form, a shared inbox), not automating what comes after.

If you want to put money on the table for the top candidates, our guide to measuring the ROI of automation shows how to estimate the benefit with your own time and error numbers.

Step 4: Pick the first two automations and define success

From the top of your ranked list, pick two processes. Two, not five. Two is enough to learn how automation works in your company, and few enough that people still have time for their normal jobs.

What makes a good first project

• It has a clear start and end, and you mapped it (or can map it in an hour).
• It runs often enough that people will notice the difference within weeks.
• A mistake in the automated version is visible and can be corrected, so the team can trust it step by step.
• The people who run it today want it changed.

A good pattern is to pick one "quick win" that can be live in a few weeks, and one process with a bigger impact that needs more care.

Define success before anyone builds anything

Write down, for each project, in one or two sentences:

• The baseline: how it works today, with the numbers from your inventory.
• The target: what should be different, measured the same way. For example, time per run, number of manual corrections per week, or time until a customer gets an answer.
• What stays manual: which exceptions still go to a person.
• The owner: who decides whether it works and who gets the alerts when it does not.
• The review date: when you look at the numbers again, for example four and eight weeks after launch.

To give a sense of what a clearly scoped first project can deliver: in our e-commerce automation project, automating order processing brought the time per order down from 15 minutes to under 30 seconds and cut manual data entry by 80%. Those results came from one well-understood process, mapped first and built second.

A simple template you can copy

You can run the whole audit with one spreadsheet. Create a sheet with these columns:

The rows above are examples to show the format. Fill in your own processes and numbers.

Add a second sheet for the process map of your chosen process with four columns: step number, step (verb plus object), who and which system, and exceptions or decisions. That is all the structure you need.

Frequently asked questions

Do we need BPMN or process mapping software?

No. For a team of 5 to 50 people, a whiteboard and a spreadsheet are enough to decide what to automate. Formal notation can help later, for example when a developer needs a detailed specification, but it should not slow down the first audit.

How long should a process audit take?

For a small company, about a week of elapsed time, with a few hours of effort for the lead and 20 to 30 minutes per interviewed team member. If it takes much longer, you are probably documenting in more detail than you need to make a decision.

Who should run it?

Someone who knows the business and is trusted by the team, often the owner, an office manager or an operations lead. The important part is that the people doing the work are interviewed and see the results.

What if the team is skeptical about automation?

Involve them from the first interview and ask about their pain points, not about automation. When the first projects remove work they dislike, and the exceptions they named are handled, skepticism usually turns into suggestions for the next project.

Should we automate the highest-scoring process first?

Usually, but not blindly. Check the top candidates against upcoming changes (new systems, reorganizations) and against how visible and correctable mistakes will be. A slightly lower-scoring process that is easier to get right can be the better first project.

Next step: get an outside view on your audit

A process audit is something your team can run on its own, and this method is designed for that. If you would like a second pair of eyes, our Business Consulting for Digitalisation service includes automation audits: we interview the people doing the work, review your inventory and scores, and deliver a written roadmap with priorities, costs and quick wins, with scope and price fixed before we start. We can build the automations afterwards, or brief your team or IT provider. The roadmap is yours either way.