Skip to content

Documenting a business process: questions and examples

Documenting is the step that yields the most and goes wrong the most. This text gives the questions that work and names the places where the interesting answers lie.

  • Who it is forAdministration, departments, management
  • LevelGuide
  • Reading timeabout 7 minutes
  • Last updated16 October 2026

What you will learn

  • Whom to ask — and whom better not to ask alone
  • Which form of question produces usable answers
  • What to note down, and in what form
  • Why the detours are the most valuable finding

Whom to ask

Ask the person who does the process every day — not the one who described it once. Between the two descriptions there are often several years of quiet adjustments.

If several departments are involved, speak with each one individually before you bring everyone together. In the joint session, the version that is presented most loudly otherwise prevails — and contradictions between the departments are precisely what is interesting.

The form of the question determines the answer

  • Instead of "How does that work?", better "What was it like yesterday?". The first question yields the ideal process, the second the real one.
  • Instead of "Are there exceptions?", better "When did you last have to correct something by hand?". Those involved often do not regard exceptions as exceptions.
  • Instead of "What takes a long time?", better "What do you get stuck on?". Time is poorly estimated, annoyance is well remembered.
  • Always: "What happens when you are not there?" This question reveals unwritten responsibilities.

What to note down

Four details for each step, no more:

  • Who does it.
  • What comes in, what goes out — and in what form: email, file, entry in a piece of software, a shout across the room.
  • What it can fail on.
  • What the step waits for before it can begin.

The last point makes the waiting times visible. In most processes it is not the handling that is long, but the waiting between the steps — and that is exactly where the gain lies.

An example from practice

The detours are the real finding

Note down what happens alongside the official process: the spreadsheet someone maintains on the side, the email to oneself as a reminder, the printout for the filing, the note on the monitor.

These detours are not carelessness, but indications of a gap in the system. Anyone who automates only the official process builds the gap in too — and wonders why the spreadsheet is still being maintained.

In one business, an employee had kept an overview of all open cases for years. It did not appear in the official process. It existed because the specialist software did not provide this view, but everyone needed it. The most valuable requirement of the entire project was in no document.

What happens after the documentation

Read the description out to those involved. Not to get a nod, but to find the places where someone says: "That is what it says there, but in reality …". That sentence is the goal of the exercise.

Only then is the question worth asking what should be automated. A process that cannot be described in sentences cannot be captured in rules either.

Common misconceptions

Anyone who can listen and does not know the business can do the documenting — not knowing it is an advantage, because it forces the questions that nobody internally asks any more.

One process is enough to start with. A complete map is a project of its own and often outdated before it is finished.

A visibly broken process should not be automated. But an imperfect one often only becomes understandable through the documentation — tidying up is part of the work, not a prerequisite for it.

Further reading

Which processes are suitable?The assessment after the documentation.
Where to start?The approach in five steps.
Avoiding duplicate data entryWhat the detours usually cause.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and concept design and writes here about decisions that come up in real projects.

Questions about the article? Write to us