How to Create a Process Map: Example, Template and a Six-Step Guide

Almost every certified company has a process map. It hangs in the meeting room, sits on page 4 of the QM manual, and the auditor signed off on it. Ask the production manager what is actually on it, though, and in a lot of companies you get a shrug. That is a shame, because the process map is the only document that shows on a single page how a company earns its money - and who is responsible for which part of that.

This guide explains what a process map is and what it is not, works through an example for a company with 60 employees that doubles as a template you can copy, sorts out what ISO 9001 actually requires, and walks through the six steps of building one. At the end comes the question most process maps fail on: who keeps it current?

What is a process map?

A process map is the top level of process documentation: an overview of every process in a company on one page, sorted by the role each one plays in creating value. It answers three questions. Which processes do we have? How do they connect? And who owns each of them?

The proven split is into three process types:

Management processes steer the company: strategy and annual planning, setting objectives, management review, continuous improvement. They produce nothing the customer pays for; they set direction and boundaries.

Core processes (also called value-adding or business processes) are the ones the customer pays for. They start with a customer requirement and end with a delivered service or product: from the enquiry through engineering, production or service delivery to shipment and after-sales. On the map they usually form a chain running left to right.

Support processes keep the core processes running without being customer deliverables themselves: HR, purchasing, finance, IT, maintenance, document control.

A company with 20 employees typically has 8 to 12 processes on its map; one with 200 employees maybe 15 to 25. More than 30 is a warning sign: you have probably put sub-steps on the map that belong one level down.

What a process map is not

The most common mix-up is process map versus flowchart. A flowchart describes what happens inside one process - step by step, with decisions and loops. The process map describes how processes relate to each other. On the map, "order fulfillment" is one box. How order fulfillment actually runs belongs in the flowchart and in the process description underneath.

It is also not an org chart. The org chart shows who reports to whom; the map shows what the company does. Processes cut across departments: the core process "order to invoice" touches sales, engineering, production, shipping and accounting. Copy the map out of the org chart and you get a list of departments under a new title - and exactly the handover problems a map is supposed to expose stay invisible.

And it is not an assessment tool. The map does not say whether a process runs well, only that it exists, what it delivers and who owns it. Whether it takes too long, has too many handovers or is done twice is a question for process analysis - and that needs the map as its starting point, because you can only assess what you have named first.

Process map example: switchgear manufacturer with 60 employees

A concrete example makes the classification tangible. Take a switchgear manufacturer with 60 employees: it engineers and builds control cabinets for machine builders and industrial customers, commissions them on site and services them. The workforce splits into sales and project engineering (4), design (8), production and test bay (28), service and commissioning (10), purchasing and warehouse (4), administration including accounting and HR (4), plus management and QM (2).

Here is that company's process map as a table - one row per process, showing what it delivers, who owns it and where it hands over. The table is the template: copy it, delete what does not apply to you, and fill in the rest.

Drawn out, this becomes the familiar picture: management processes as a bar across the top, the five core processes in the middle as a chain of arrows from the customer enquiry on the left to the service work on the right, support processes along the bottom. Whether you do that in PowerPoint, draw.io or as a photo of a whiteboard is beside the point. The table is the substance; the graphic is the presentation.

Two things stand out in this example. First, 13 processes are enough for 60 people. The company also has a canteen, a vehicle fleet and occupational safety - deliberately not their own processes on the map, but part of S4 and S5. Second, the "Hands over to" column is the important one. It shows that C2 hands over to production and purchasing at the same time - and that double handover is exactly where the delays come from in practice, because the bill of materials reaches purchasing before the design is released, or the other way round.

The table needs a header block above it, otherwise the document cannot be controlled:

Process map [company]
Version: 3 | As of: 2026-09-08 | Approved by: Managing director
Maintained by: QM manager
Next review: 03/2027 or on any change to the organization

Process maps under ISO 9001: what the standard requires

ISO 9001:2015 requires in clause 4.4 that the organization determine the processes needed for its quality management system - including their inputs and outputs, their sequence and interaction, the responsibilities, and the criteria for controlling them. The words "process map" do not appear in the standard. So there is no ISO 9001 process map template in the strict sense; there are requirements that a one-page map satisfies if it is built properly.

In practice an auditor checks three things. Are all processes relevant to the product or service named (completeness)? Is it visible how they connect (interaction - in the table, the "Hands over to" column)? And does each process have an owner? Everything beyond that - metrics, risks, resources, individual steps - belongs in the description of the single process. How that is structured is covered in the process description template.

The good news for smaller companies: the standard prescribes neither a minimum number of processes nor a particular form of presentation. A table like the one above is audit-ready. What an auditor will not accept is a map nobody in the company can explain.

How to create a process map: six steps

Step 1: Define the purpose

What do you need the map for? Certification, onboarding new managers, groundwork for a digitalization project, handing the business to a successor? The purpose sets the altitude. A map for the audit needs completeness; a map for succession planning above all needs the "Owner" column - and a hard look at where only one single name sits behind a role.

Step 2: Collect processes from conversations, not from the org chart

This is the decisive step, and the one where most maps are already spoiled before anyone draws anything. The reflex is to take the org chart and turn each department into a process. The result is a map that explains nothing.

Better: talk to the people who do the work. Not only to department heads, but to the people who create the order, check the bill of materials, hand the installation over to the customer. Do not ask "Which processes do we have?" Ask: "What arrives at your desk, what do you do with it, and who do you pass it to?" The answers from 10 to 15 people produce the chain of core processes almost by themselves - along with the surprises: the process that officially does not exist because a colleague has been handling it on the side for years; the handover that works because someone shouts across the room and therefore appears nowhere. Which method of gathering suits which company is compared in the guide on capturing as-is processes.

This step can now largely be automated. At wissa.ai an AI runs the conversations: 15 to 20 minutes per person, by chat or voice. When an employee names a colleague they hand over to, that colleague is invited next - so the system works its way through the company along the actual handovers rather than the org chart. The process map is generated from those statements, complete with owners and interfaces, and every row can be traced back to the statement it came from. If sales says design only hands over after release, and production says it gets the drawings earlier, the contradiction is flagged rather than smoothed away.

Step 3: Draw the levels

Sort the collected processes into management, core and support - and decide what belongs on the map and what belongs one level down. Rule of thumb: a process goes on the map if it needs its own owner, its own output and its own description. "Incoming goods inspection" is a sub-step of "purchasing and warehouse", not a process of its own. "Complaint handling" can be either: a sub-step of service, or a process in its own right if complaints are frequent and expensive enough in your business that someone should own them separately.

Step 4: Name the interfaces

For each process: what triggers it, what is the output, and which process does it go to? The "Hands over to" column forces precision. If you cannot fill it in, either the process is cut wrong or the handover really is unclear in daily work - both are worth knowing. Points where one process hands over to two others at once, or where two processes claim the same output, are your first candidates for improvement later.

Step 5: Assign owners as roles

Every process gets exactly one process owner. Not two, not "the team". Write roles, not names: "Head of Design" survives a change of personnel. And keep a second, internal list showing who currently fills each role and who covers for them. If the same name appears against three core processes on that second list, the map has already earned its keep.

Step 6: Set an expiry date

Put into the header block when the map will be reviewed at the latest and who does it. Annually is a good rhythm, plus every change to the organization as a trigger: new department, new business line, a change of process owner. A review is allowed to take ten minutes and end with "no changes". Without a date and a name it does not happen at all.

Common mistakes when creating a process map

The map shows the target state, not reality. The quality manager draws how the company should work according to the manual. The company works differently. The audit will not catch it; daily work catches it constantly. The map becomes a document with no bearing on the actual job and loses all authority. Where lived practice differs from the plan, document the practice first - then change the practice if it deserves changing. Not the other way round.

Too much detail. Forty boxes, sub-processes with sub-numbers, arrows in three colors. A map you cannot explain in two minutes is not a map, it is a flowchart in the wrong format. Everything below process level belongs in the documentation of the individual process; how the levels below are built is described in the process documentation guide.

Copied from the org chart. See step 2. You can spot it because the core processes carry department names and not one process crosses a departmental boundary.

Nobody maintains it. The most common mistake and the most expensive. The map is created for the certification audit and then not touched for three years while the company keeps developing. At the recertification audit the work starts from scratch. The antidote is step 6 - plus the insight that a map born out of conversations can be kept current with conversations. Talk to the people involved every few months and you notice when a process has been added, dropped or re-cut before the auditor does.

Treating the map as the goal. It is the beginning. A map with no process descriptions underneath it is a table of contents without a book. That is fine as a first step, but plan the second one straight away.

If you want to shortcut the gathering step: wissa.ai interviews your employees via AI chat and builds the process map from it, including owners, interfaces and a source reference for every row - then updates it after each further conversation with a diff against the previous version. GDPR-compliant with EU hosting, voluntary participation, no performance assessment. The first 3 interviews are free; after that, 12 interview credits cost 149 euros net. Register for free

Conclusion

A good process map fits on one page, distinguishes management, core and support processes, and names for each process an output, an owner and the handover to the next process - with a date on which it gets reviewed. It comes out of conversations with the people doing the work, not out of the org chart, and it shows what is, not what should be. The table above is meant as a template: for most companies between 10 and 200 employees, 10 to 20 rows are enough.

FAQ

What is a process map?

A process map is the one-page overview of all the processes in a company, grouped into management, core and support processes. It shows which processes exist, how they connect and who owns them. It is the top level of process documentation; what happens inside each process belongs in the process descriptions and standard operating procedures below it.

What is the difference between a process map and a flowchart?

The flowchart describes the sequence inside one process, step by step and with decision points. The process map describes how the processes relate to each other: which ones exist, what they deliver, who they hand over to. On the map a process is a single box; its flowchart is the detailed view of that box.

Is a process map mandatory under ISO 9001?

The standard does not use the term, but clause 4.4 requires that the processes of the QM system be determined together with their interactions and responsibilities. A process map is the most widespread way of meeting that requirement. Neither a particular form of presentation nor a minimum number of processes is prescribed - a table listing process, output, owner and interfaces is audit-ready.

How many processes belong on a process map?

For companies between 10 and 200 employees, 10 to 20 processes is normal. A process belongs on the map when it needs its own owner, its own output and its own description. More than 30 entries suggests that sub-steps have made it onto the map that belong one level down.

Who should create the process map?

Formally it is owned by management and usually drafted by the quality manager. The content, however, has to come from the employees who run the processes every day - they know the real handovers and the processes that appear on no org chart. A proven division of roles: the practitioners supply the content via interviews, QM structures it, management approves it.