Process Documentation: Documenting Processes in Mid-Sized Companies

Most mid-sized companies have documented their processes at some point. Often there is a folder called "Processes_final" somewhere, a QM manual from 2021 or a wiki where some pages are well kept and others are waiting for their next revision.

This guide shows what belongs in process documentation, how to document processes step by step and which format suits which purpose. It also covers how the documentation stays current over months and years.

What Is Process Documentation?

Process documentation is the written record of business processes and workflows: the individual steps in order, the roles and responsibilities, the systems and resources involved, and the handovers between people and departments. It shows how the work actually runs, so that others can carry it out, cover for colleagues and improve it.

Depending on the purpose, process documentation takes different forms, from a one-page process map to a detailed work instruction. The section on formats below shows which one fits where.

Process documentation and the three versions of every process

In every company, every process exists three times:

1. The documented process. What is written in the manual, the wiki or the ISO documentation, often created in a workshop two years ago.

2. The assumed process. The picture management has of the workflow: "The order goes through SAP, then sales reviews it, then it goes to production."

3. The real process. What actually happens. The order comes in by email, and Ms. Behrens types it into an Excel list because she finds the SAP screen "clunky". Then she calls across the hall to ask whether production has capacity. It has worked for years and so far is written down nowhere.

Good documentation captures version 3, and for that it needs the people who run the process every day. They are not always in the workshop. In a group, not everyone finds it easy to say: "I've been doing this a little differently from what's on the wall for years." In one-on-one conversations this comes up much more readily.

The second point is effort. Traditionally, documenting processes means scheduling workshops, taking people out of their day-to-day work and finding someone to write everything up afterwards. With 20 processes and a thin roster, this often only reaches the first few processes. The ones left over are frequently those that live in a single person's head. How to break up such knowledge silos is covered in a separate guide.

The third point is upkeep, and it gets its own section below.

What good process documentation contains

Useful process documentation answers the questions a new colleague asks in week two, and exactly those. As a checklist:

The steps

• What triggers the process? (An order, a phone call, month-end close, an error report)
• Which steps follow, in what order?
• What is the outcome, and how do you know the process is finished?

Roles and responsibilities

• Who performs each step, as a role and by name?
• Who decides when things are unclear?
• Who covers when the main person is on vacation? (If the answer is "nobody", you have just documented a knowledge risk, a bus factor of 1, and that is a valuable insight. A skills matrix shows who can already take over which task.)
• Who is responsible, who contributes, who is consulted or informed? With many people involved, a RACI matrix sorts these roles for each step.

Systems and required resources

• Which tools are used in which step, including the unofficial spreadsheets on the local drive?
• Where does the data live, and who has access?
• Where is information transferred from one system to the next, automatically or by hand?
• Which resources does the process need, such as licences, materials or a person's time?

The handoffs

• At which points does the process change departments or people?
• How is it handed off: by ticket, by email or with a word in passing at the workbench?
• Most errors arise at handoffs, so it pays to document them with particular care.

The edge cases

• What happens with rush orders, complaints, missing information?
• These exceptions are often known to one person only, and they are what people reach for the documentation for later.

The glossary

• What does "released" mean at your company? What's an "OC"? What does sales mean by "done"?
• Internal jargon is the biggest hurdle for new hires. Three lines of glossary save thirty follow-up questions.

If you need a process documentation example, take order intake. The trigger is an order by email or from the web shop. The steps are entry, review and confirmation, done by inside sales, with the head of sales for special pricing. The systems are the ERP plus the price list in Excel. The handoff to production runs by ticket, by phone for urgent cases, and a rush order is approved directly by the CEO.

That fits on two pages, and after reading it a new hire can ask specific questions because the basics are already clear.

Documenting processes step by step

You document a process in five steps: choose and scope it, talk to the people who run it, record the individual steps, review and approve the result, and decide how it stays current.

Step 1: Choose the process and set its boundaries

Start with the processes that depend most on individual people. Which process grinds to a halt if a specific person is out tomorrow? Which one regularly produces errors? These come first, and the complete overview can wait.

Then set the boundaries. Name the trigger where the process starts and the result where it ends. "Order processing from incoming order to invoice" is a process you can document. "Sales" is an area that contains several processes. A one-page SIPOC helps to agree on suppliers, inputs, outputs and customers before you start.

Step 2: Capture the process by talking to the people who run it

Talk to the person who runs the process, ideally one-on-one. In individual conversations people say things like "officially we do it this way, but actually ...". That sentence is the core of process documentation that matches practice. How the interview compares with workshops, observation and self-documentation is covered in the guide on as-is process mapping.

Follow the references. In almost every conversation someone says "Max handles that part" or "Hanne maintains that list". These sentences are your map, so talk to Max and Hanne next. That way you work your way from one knowledge holder to the next and always know whom to ask.

Step 3: Record the individual process steps

While documenting, it is tempting to improve things straight away and write down how they should be. First capture how it runs today, with the Word template from 2019 and the inbox serving as the filing system. You can improve afterwards, based on facts, and that is the job of process analysis and of process optimization after it.

Give each step a role, a system and a result. When statements contradict each other, for example "it runs through SAP" and "it runs through three spreadsheets and that one USB stick", write both versions down with their sources. The contradiction is a finding in its own right.

Step 4: Review and approve

Have the people who run the process read the draft. They spot missing steps and wrong terms fastest. Resolve the contradictions together, then the process owner approves the documentation with a date and a version. Often that resolution is worth more than the documentation itself.

Step 5: Decide how the documentation stays current

Decide this before you write the first page, so that upkeep is part of it from the start. Name an owner and the events that trigger an update. The section on upkeep below shows how.

When there is no time for the conversations

Mid-sized companies often lack the capacity for steps 2 to 4. There is now a further option for that, AI process documentation. At wissa.ai, an AI interviews your employees individually in a chat, around 15 to 20 minutes per conversation and whenever it suits them. If "Max and Hanne handle that" comes up in a conversation, the AI suggests inviting both, following the same snowball principle as in step 2.

Contradictions between statements appear side by side with their sources, and every statement in the finished documentation is traceable back to its source, usually the interview. Try one interview for free

Documenting business processes: which format for what

The right format depends on the question the document has to answer. Most companies use several formats side by side, each at its own level of detail:

A proven order is to start with the process map as an overview, then write a process description for each important process. Work instructions follow where a single step needs more detail. How those documents come together in a lean quality manual, and why ISO 9001:2015 no longer requires a manual as such, is covered in a separate guide.

Documenting workflows in small teams

Small teams can document their workflows with simple means. Three forms go a long way:

• A checklist for recurring tasks such as month-end close or onboarding a new customer.
• A table with step, role, system and result for workflows with several people.
• Photos or screenshots as attachments where a picture explains more than a sentence, for example at a machine or in a software screen.

Keep everything in one place the whole team knows, such as a shared folder or a knowledge base. One page per workflow is usually enough.

Upkeep: how the documentation stays current

Once process documentation is finished, the business keeps moving. A new tool is introduced, a colleague leaves, a step is dropped. The documentation keeps up when someone is responsible for it and there is an occasion to update it. Otherwise upkeep easily becomes invisible work in the day-to-day.

After a year perhaps 70 percent of the documentation is still accurate, and nobody knows exactly which 70 percent. New hires then rely on information that no longer applies, and experienced colleagues stop looking. A few rules keep the documentation reliable:

• Name one owner per process. A named person who updates the page when things change.
• Tie upkeep to events. A fixed date like the "quarterly review" tends to slip in daily work. It is more reliable when every tool rollout, every personnel change and every process change triggers a documentation update.
• Keep it small. Two current pages help more than twenty stale ones. Cut everything that doesn't answer a question a new colleague would ask.
• Living documentation. The documentation is continuously fed by recurring conversations and is never quite finished. At wissa.ai, for instance, the process documentation continues after every interview with a visible diff against the previous version. You see exactly what has changed since the last state.

A simple yardstick helps: if someone can say when your documentation was last updated, it is in good hands.

Process documentation template: when Word is enough and when it isn't

Searching for a "process documentation template" turns up hundreds of Word and Excel templates. A full process documentation template with every field and a filled-in sample is covered in its own guide. To get started, this skeleton is enough, with the six fields from the checklist above plus a glossary, ready to copy:

Process: <name>          Owner: <role>          As of: <date>

1. Trigger          What starts the process?
2. Steps            No. | What happens | Result of the step
3. Owners           Who performs each step (role)? Who covers?
4. Systems          Which tools, spreadsheets, folders - unofficial ones too?
5. Handoffs         Who does it go to next, and how (ticket, email, word of mouth)?
6. Edge cases       If <situation>, then <action>.
Glossary            Internal terms and abbreviations

More detailed templates are available as Word downloads: the process description template (.docx) and the work instruction template (.docx). Here is a calm look at when a template like this is enough.

A template is enough if you have five to ten processes, one person treats the documentation as their job and your workflows rarely change. A two-page template with the fields from the checklist above is then perfectly sufficient. If you need a formal document for an ISO audit, a standard operating procedure follows a similar structure with a few additional sections. You can capture order intake well without BPMN software or swimlane diagrams.

You need more than a template if the actual task lies beyond the form. A template gives structure. Getting the knowledge out of people's heads, making the gap between documented and real process visible and keeping the documentation current are three further tasks. The "edge cases" field fills up in conversation. With 30 processes, high turnover or critical knowledge held by individuals, it is worth planning a separate route for these three tasks.

As a rule of thumb: the template settles the question of structure. For capture and upkeep you need a routine or a tool that handles both.

If you would like to try the second path, you can start with wissa.ai right away. A free trial package to start with (10 credits, once per company, terms) usually covers a first interview. Interviewees need no account, the platform is hosted in Germany, and a data processing agreement under Art. 28 GDPR is included. The interviews describe workflows, roles and systems, and wissa gives no scores or rankings for individuals. In Germany, if there is a works council, agree the rollout with it beforehand, since the rollout usually requires codetermination under section 87(1) no. 6 BetrVG. Try one interview for free

FAQ

What belongs in process documentation?

Process documentation contains the trigger, the individual steps in order, the roles and responsibilities, the systems and required resources, the handovers between people and departments, and the edge cases. A short glossary explains internal terms. Each document also carries an owner and the date of its last update, so readers can tell whether it is current.

Which format suits documenting business processes?

It depends on the question. A process map shows all processes and how they connect, and a process description shows how one process runs with steps, roles and systems. A flowchart shows branches and loops, and a work instruction explains a single step in detail. Most companies start with the map and one description per important process.

How do I document workflows that only one person knows?

Talk to that person one-on-one and ask open questions about their daily work, including exceptions and what happens during their absence. Write down the answers as they are, then have a second person carry out the workflow once with the documentation. The guide on knowledge silos shows further strategies.

Where do I start when nothing is documented yet?

Pick the two or three processes with the biggest risk, meaning those where knowledge hangs on a single person or errors happen regularly. Talk to the people who do the work, write down the as-is state on two pages and name an owner. Then move on to the next process. The complete overview can wait.

How detailed does process documentation need to be?

Detailed enough that a new colleague can keep working after reading it. Click-by-click instructions with screenshots go stale quickly and belong in a work instruction. Trigger, steps, owners, systems, handoffs and edge cases on one to three pages is almost always the right level.

Who should document the processes, the manager or the team?

The content comes from the people who do the work, so that the documentation shows practice. The manager prioritizes, resolves contradictions and makes sure there is time for it. If the writing is delegated to someone who doesn't run the process themselves, that person should talk to the right people.

Do I need special software for process documentation?

For a few stable processes, a Word template or a wiki is enough. Software becomes worthwhile when capturing knowledge from many heads or keeping things current is the actual task, that is, with many processes, turnover or knowledge spread across individuals. The page on process documentation software shows how wissa.ai supports both.

How often does process documentation need to be updated?

Events work better than a fixed schedule: a new tool, a personnel change or a modified workflow each trigger an update. If you want a schedule on top, having the owner reread each process once a year is very manageable and usually holds up better in daily work than a quarterly review.

Sources

• ISO 9001:2015, clause 4.4 (Quality management system and its processes) and clause 7.5 (Documented information)