Most companies have a written version of how a process works and a real version that people follow. The written one says an order is checked, approved and sent. The real one includes a spreadsheet nobody mentioned, a phone call to a colleague and a rule that only one person remembers.
If you want to improve a process, move it to a new system or automate part of it, you need the real version. The fastest way to get it is a two-hour walkthrough with the people who do the work. This article describes how to run one.
Before the meeting: pick the process and the people
Choose one process that has a clear start and end, such as "a customer order arrives and is delivered" or "a supplier invoice is received and paid". If you are still deciding which one, our article on choosing which process to digitize first gives a simple way to compare candidates.
Invite two or three people who do the work every week. Add the process owner if there is one, but ask them to listen first. Managers tend to describe the intended process; people doing it describe what happens. If the owner speaks first, the others often agree politely.
Ask each person to bring one recent real case. An order, an invoice or a request that they handled last week works well, because they can open the actual email, file or screen.
During the meeting: follow one case
Do not start with "describe your process". People answer with a summary that skips the awkward parts. Instead, take one real case and follow it from the first moment it appeared.
Use the same short questions at every step:
- What happened next? Ask for the actual action, such as "I open the email and copy the number into the sheet".
- Who did it? Write the role and the person, if they differ.
- Where? Which system, file, mailbox or paper form.
- What did you need to know? Which information they had to look up, and where they found it.
- How long did it wait? Time spent on the task and time spent waiting for someone else.
Ask people to show rather than tell. A screen share or a printed example uncovers steps that nobody would remember to mention.
Ask about what goes wrong
After the first case, ask for a second one that went badly. Ask "when does this not work the first time?" and "what do you do when the information is missing?".
These answers are the most valuable part. Exceptions, workarounds and informal rules usually do not appear in any manual, and they are exactly what breaks when a process is changed or automated. If you plan to hand part of the work to software, the article on describing a process before building an AI agent explains why exceptions and data sources need to be written down first.
Pay attention to phrases such as "usually", "unless", "I just know" and "ask Petra". Each one points to a rule that lives in someone's head.
How to behave as the facilitator
- Do not fix problems during the meeting. Write them in a separate list. If you start solving, people stop describing.
- Do not judge shortcuts. If someone has a workaround, you want to hear it. If they feel criticised, the next ones will be hidden.
- Ask for the reason. "Why do you do it this way?" often reveals an old problem that the step was invented to solve.
- Keep the time. Two hours is enough for one process. If you run out, schedule a second session rather than rushing.
What to write down
The output should fit on one page. A simple table works:
| Step | Who | Where | What goes wrong | Time |
|---|---|---|---|---|
| Order arrives by email | Sales assistant | Shared mailbox | Order sent to a personal address | 5 min |
Below the table, add three short lists: the exceptions people described, the places where work waits, and the questions that nobody in the room could answer. The third list is the follow-up work.
Then send the page to the participants within a day and ask them to correct it. They will usually fix two or three details, and that correction is what makes the page trustworthy.
After the meeting: owner and check
Give the page one named owner and a date, a few weeks later, to compare it with a new real case. A process description that nobody checks becomes the next outdated manual.
Use the page for the decision it was made for. It might show that the process has three redundant steps and needs no software. It might show that one step is repetitive and has clear rules, which makes it a good candidate for automation. Or it might reveal that the real cost is waiting time, in which case the article on the true cost of manual processes can help you put numbers on it.
Common mistakes
- Inviting only managers, so the meeting produces the official version.
- Asking for a general description instead of following a real case.
- Skipping the bad case, so exceptions are missing.
- Solving problems on the spot and losing the thread.
- Producing a long diagram that nobody reads, instead of one page that people correct.
Summary
A two-hour walkthrough with the people who do the work, built around one real case and one bad case, gives you the real steps, the exceptions and the open questions. Write them on one page, let the participants correct it, and give it an owner. That page is a far better starting point for any improvement than the manual on the shared drive.
Sources
- Our related articles linked above.
- The meeting format, questions and one-page layout are a working practice, not a standard; adapt them to your company. The example table row is illustrative. No client results or market figures are claimed in this article.
