Process mapping in a company: how to map a process step by step

What is process mapping and why do it?

A process map shows how work actually flows through a company: who starts it, where the data lives, where someone waits and where mistakes happen. You make one so that decisions rest on numbers rather than on a feeling that “everything takes too long”.

Two things get mixed up constantly, so it's worth separating them:

• A process landscape is a top-down view of the whole company: the main processes (sales, delivery, invoicing, hiring) and how they connect. It fits on one page.
• A process map breaks one process into steps, roles, data and time. That's where you see what to automate.

I start with the landscape, because in an hour it shows where to look at all. Then I map exactly one process in detail, the one that hurts most. Mapping everything at once ends in a binder nobody opens.

Mapping is the first step before process automation. If you automate a process without a map, you move its mistakes and pointless steps into software too; they just run faster.

How do you map a process in six steps?

You map a single process in six steps: set the boundaries, list the steps, assign roles, record the data, measure the time and collect the exceptions. The first four usually take one conversation with the people who do the work. The fifth and sixth need a normal working week of note-taking.

1. Boundaries. Write one sentence on what starts the process and what ends it. For example: “it starts when a customer emails an order and ends when the invoice has been sent”. Without boundaries the map spreads across half the company.
2. Steps. List what happens in order, starting each step with a verb: “enters”, “checks”, “sends”. One step is one action by one person.
3. Roles. Note who does each step. A job title is enough; you don't need names. Every hand-over between people is a place where work usually waits.
4. Data. Note where each step takes data from and where it leaves it: email, PDF, spreadsheet, invoicing software, phone. Steps that only copy data from one place to another are your main automation candidates.
5. Time. For a week, everyone notes how many minutes a step takes and how many times they did it. Estimates from memory tend to be far too low, because nobody counts interruptions, searching and phone calls.
6. Exceptions. Write down what happens when something goes wrong: a missing VAT number, a wrong price, a customer changing the order. Exceptions eat time out of all proportion to how rarely they happen.

I collect exceptions last on purpose: only measuring shows which ones really happen and which are an anecdote from last year.

A process map template: the table you fill in a spreadsheet

A process map needs a spreadsheet with seven columns: number, step, step type, minutes per run, runs per month, who and where the data is. Below is a sample for an “order by email to invoice” process. It's an example, not data from a real company.

The “Type” column matters most, because it decides what you do with each step:

How do you turn a process map into hours and decide what to automate?

The arithmetic is simple: time per step multiplied by runs per month, summed separately for each step type. Then take the total for steps that move data and estimate how much of it automation would take over. That's your monthly saving, and it decides whether the project is worth starting.

In the sample table, the steps that move data add up to 3 + 6 + 2 + 3 = 14 minutes per order. At 400 orders a month that's about 93 hours. If automation takes over 70% of that work, you get back about 65 hours a month, or roughly PLN 4,600 at a full cost of PLN 70 per hour. That's an estimate for the example, not a result from a real company. My automation projects start from PLN 15,000 excl. VAT, so this process would pay back in about 3 months, before you subtract running costs.

You can try your own numbers in the automation savings calculator. I describe how to pick the first process and the payback formula in detail in where to start with business automation.

The map also shows things no calculator will:

• Step 6 costs more than it looks. It happens on one order in ten, but it takes several times longer than a normal step. The cheapest fix is often checking the VAT number and price at step 1, not getting better at fixing errors.
• Step 3 can disappear. If stock levels are in software, checking availability becomes a rule rather than someone's job.
• Hand-overs between people cost waiting time. You won't see it in the table until you add a “waiting from–to” column. For a first map, it's enough to mark where work changes hands.

An example from Reefa: the “bank to invoice” process

A good example from Reefa, my cleaning company, is matching bank transactions to invoices. The process has one rule at the entrance: every movement on the account needs coverage. Income needs an invoice; an expense needs a cost document.

Matching a transfer to an invoice turned out to be only part of the work. The exceptions, which look minor at first glance, needed handling of their own:

• an invoice number split across two lines of the bank statement,
• the same transfer imported twice, once from an MT940 file and once through the bank connection,
• transactions that can't be matched automatically and need a person to explain them.

So the system doesn't pretend to understand everything. On the first day of the month it goes through the transactions of three companies, matches them with invoices, shows anything without coverage in red and sends it to me on Telegram. The decision on exceptions stays with a person, because it is a “decides” step, not a “moves data” one.

The second lesson is about measuring. Before I trusted the reading of bank statements, I checked it against 14 cash withdrawals that had been settled by hand earlier: every one matched. Only then did I reconcile the petty cash across 21 closed months. When I built the delivery of supplies to our sites, I measured the “before” state first: on average 9.4 days passed between order and delivery. Without a number like that from the map, you can't honestly say later whether anything improved.

I describe the whole system that grew out of this in the case study an operating system for a service company.

BPMN, flowchart or table: which notation should you use?

For a first map in a small company a table works best, because everyone can fill it in and you can calculate with it straight away. A flowchart helps show branches, and BPMN makes sense when a process crosses several departments or a system is meant to run it.

BPMN, Business Process Model and Notation, is a process notation standard maintained by the Object Management Group. According to the OMG specification page (as of 19 October 2026), the latest formal version is 2.0.2, from January 2014. It has symbols for events, tasks, decision gateways and lanes for roles, so it describes complex processes well. The price is time: the team has to learn the symbols before it can improve the map.

My practice: a table first, a flowchart when the team needs to see the branches, BPMN only when someone is going to build a system from it. Then the precision of the symbols saves misunderstandings at the quoting stage. If you're wondering whether existing software can handle such a process or you need your own, read how to choose between a custom system and an off-the-shelf tool.

The most common process mapping mistakes

A map usually goes wrong because the wrong person draws it or because it stops at a diagram without numbers. Both are easy to fix if you know about them before you start.

• The manager draws the map instead of the person doing the work. You get the process as it was meant to be. Sit down with whoever does it every day.
• No boundaries. A “sales” map with no start and end point grows until nobody finishes it.
• No time or repetitions. Without minutes and run counts you can't choose what to automate; you're guessing.
• Exceptions stay in people's heads. They're what most often breaks the automation later, when it hits a case nobody wrote down.
• The map is made once and dies. Processes change. If the map is to be useful, the process owner updates it whenever a rule changes.
• The tool is chosen before the map. Map first, then decide whether a feature in your current software, an off-the-shelf connector or your own code will do.

If AI comes up as an idea for the process, a map matters even more. It shows which steps are rules and which are decisions, and that settles where AI makes sense. More on that in AI in small and mid-sized firms: what works, what fails.

When doesn't process mapping pay off?

Mapping doesn't pay off when a process happens a few times a year, when it's about to change anyway, or when the problem is a missing decision rather than a missing description. The map will only show you what you already know.

There's also no point mapping everything at once. One well-mapped process with counted hours gives you more than twenty diagrams without numbers. And you don't always need to build anything afterwards: sometimes reordering the steps or adding one notification is enough.

Where to start mapping processes in your company?

Pick the one process that hurts most in the last week of the month and map it in the table from this article. After a week of measuring you'll know how many hours it takes and which steps only move data.

If you'd like to check first how ready your company is for automation and AI, take the free AI readiness assessment. The full AI and process audit, two weeks of interviews with your team, a process map, counted hours and a rollout plan, starts from PLN 6,000 excl. VAT. You can also book a 30-⁠minute call and walk me through one process; the scope of automation projects is on the process automation page.