Process documentation people actually use day to day
We capture your workflows so they are found and understood at the workplace: brief, current and stored where the work happens. That includes procedural documentation for tax-relevant workflows, an onboarding path for new colleagues and clear cover arrangements for holidays and sick leave.
Capture, delivery and upkeep · net plus VAT
- Capture on site instead of a questionnaire by email
- A few pages per workflow, in the language the team uses
- Procedural documentation for the tax-relevant workflows
- Upkeep agreed so the content still holds a year later
The process analysis is the entry point and starts at 1,900 € net: a survey of your workflows, a written report and a prioritised list of measures. The write-ups are built on that basis. Where an automation or interface follows, delivery starts at 4,900 € net as a fixed price set after the analysis. Ongoing upkeep of the documentation starts at 190 € net per month. All prices net plus VAT; third-party licences and fees are shown separately. The full breakdown is on the pricing overview.
Prices as of September 2026. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.
In many companies the knowledge about their own workflows lives entirely in people's heads: the workshop manager knows which supplier still delivers on rush orders, accounting knows the exceptions for interim invoices, and scheduling follows a sequence that is written down nowhere. As long as everyone is in the building, this works remarkably well. The moment someone is off sick, retires or starts new, every small thing turns into a question. Process documentation is the attempt to move that knowledge into a form that holds up in daily work. The most common mistake: a lengthy document is produced that nobody reads and that stops being accurate within months.
What a usable process description contains
Why documentation keeps getting postponed
Documentation rarely fails for lack of good will. It fails because it is treated as a project that is finished at some point. Forty pages are produced, the result moves into a folder on the file server, and from the day of handover the text drifts away from reality step by step. After two software changes and one staff change it is not wrong enough to throw away, but no longer right enough to follow. That is precisely the state in which documentation does harm: it creates confidence where none is left. Whoever reads it works to a state of affairs that no longer exists, and only notices once something goes wrong.
Written when there is no time
Documentation usually gets written between two jobs. What is produced in that situation is either too brief to help anyone, or so detailed that it never gets finished. We capture the workflow once, in a structured way, instead of asking people to write it up on the side.
Stored where nobody looks
A folder deep in the file store, an attachment in an old message, a printout on a shelf: if the route to the answer takes longer than asking a colleague, people ask instead of reading. Storage therefore belongs where the workflow actually happens.
Written for the wrong readers
Texts written from the system's point of view describe screens, fields and click paths. Someone new needs the sequence, the responsibility and the handling of exceptions. They will find the screen themselves; the decision they will not.
Without agreed upkeep
If nobody is named to adjust the write-up after a change, it decays inevitably. Upkeep needs a trigger, a responsible role and a point in time, otherwise it simply does not happen.
What belongs in usable process documentation
A write-up is usable when a briefed stand-in can carry on with it the next morning. That determines the content: not everything that could be described, but what is needed at the work step for the next decision. We work with six fixed components per workflow and deliberately keep them short. A workflow that needs more than a few pages is, as a rule, not one workflow but several that have not yet been separated.
Trigger and outcome
What starts the workflow, and how do you recognise that it is complete? We phrase both as observable events rather than intentions. Without these two points a workflow can neither be checked nor handed over cleanly.
Responsibility and cover
Who carries out the step, who decides in case of doubt, and who takes over during absence? Responsibilities sit where they are needed, not in a separate list at the end of the document.
Steps in the real order
We describe how the work is actually done, including the detours that have become habit. Only once the current state is on paper can you sensibly discuss which steps could be dropped.
Exceptions and special cases
The normal case is rarely the problem. So we explicitly record what applies to partial deliveries, complaints, rush orders or missing details, and who is allowed to decide those cases.
Systems and the leading source
Which system holds which information authoritatively? This decision prevents two places maintaining the same detail and contradicting each other later. It is also the basis for any later data integration.
Status and review trigger
Every write-up carries a date, a responsible role and the trigger that calls for a review: a software change, a change in the law, a change in the workflow. Without this part, everything else decays.
Procedural documentation to GoBD requirements
For tax-relevant workflows an internal work instruction is not enough. The German principles for the proper keeping and retention of books, records and documents in electronic form and for data access (GoBD, Federal Ministry of Finance) expect procedural documentation that makes the content, structure, sequence and results of the process used comprehensible. This applies to every business that captures documents electronically, scans paper in place of the original or files invoices digitally, which in practice means everyone who digitises documents. Books and records must be retained for up to ten years (German Fiscal Code); across that period it must also remain traceable how they came about and who was able to change them.
- General description: what is processed, to what extent and with which systems
- User documentation: how the people involved work with the process day to day
- Technical system documentation: programs, interfaces, data flows and storage locations
- Operating documentation: access rights, approvals, backup, restore and logging
- Change record: who changed what and when, and which version applied at which time
- Evidence of retention: immutability, legibility and findability across the retention period
We supply the basis, not the tax assessment
Onboarding and cover: the two situations where it counts
Onboarding: from watching to the first case of your own
In most companies new colleagues learn by watching. That works as long as someone has time to show them, and it collapses as soon as several people start at once or the experienced colleague is on holiday herself. From the existing workflow write-ups we build an onboarding path: a sequence of workflows that build on each other, each with what has to be understood beforehand, and with a real case to practise on. The path doubles as a checklist for the manager, because it stays visible what has been handed over and what is still outstanding.
- A sequence, not a pile of material: what comes first, what builds on it
- One real case to work through per workflow instead of a dry run
- Visible onboarding status for both sides
- Transition into training and rollout for larger changes
Cover: arranged before it is needed
Cover is usually organised on the day someone calls in sick. What is missing then is rarely the knowledge of the workflow but the access: the folder sits on a personal drive, the approval hangs on a single user account, and one person knows the credentials. For every documented workflow we set out who covers, what that person must be able to access, and which steps are explicitly not decided during cover but wait. This arrangement is unspectacular and becomes important on the day it is missing.
- A named stand-in per workflow instead of general responsibility
- Access and approvals clarified in advance, not during sick leave
- Explicit note on what may wait and what may not
- Storage in shared locations instead of personal drives
| Workflow | Stand-in | Access |
|---|---|---|
| Order intake | M. K. · Sales office | clarified |
| Goods receipt | T. B. · Store | clarified |
| Invoice approval | S. R. · Accounting | open |
| Scheduling | A. W. · Dispatch | clarified |
Why documentation without upkeep becomes worthless
A write-up is not a document but a promise: that this is how the work is done. As soon as that stops being true, the harm outweighs the benefit, because now someone follows an instruction that leads nowhere and relies on it while doing so. That is why we treat upkeep as part of the handover rather than an afterthought. We agree three things: a responsible role per workflow, a trigger for review, and a fixed date on which the write-ups are looked over even without a particular reason. Where we take on ongoing operations, that review is part of the service; where you maintain it yourselves, we set up the structure so a change costs a few minutes rather than half a day.
| Aspect | Documentation as a one-off project | Our approach: documentation as a component |
|---|---|---|
| Scope | One manual covering all areas | A short write-up per workflow, usable on its own |
| Language | System view: screens, fields, click paths | Work view: sequence, responsibility, exceptions |
| Storage location | A folder in the file store | Reachable where the workflow is carried out |
| Currency | Accurate at handover, unchecked afterwards | Date, responsible role and review trigger per write-up |
| Tax-relevant workflows | Not considered separately | Procedural documentation along the GoBD requirements |
| After handover | The project ends with the document | Review and adjustment from 190 € net per month |
How we work
Select and scope the workflows
Not everything needs to be described. Together we pick the workflows where staff absence, onboarding or evidence obligations create the most pressure, and we scope them cleanly: where does the workflow start, where does it end, and what explicitly does not belong to it. This scoping decides how long the write-up will later be.
Capture at the workplace
We watch where the work happens and ask questions at the points where decisions are made. Per workflow this usually takes a few hours and regularly surfaces steps that appear in nobody's mental picture of their own process. This capture is also the core of the process analysis.
Write up and have it checked
The capture becomes a short write-up per workflow with trigger, steps, responsibilities, exceptions and the systems involved. It is checked by the people who carry out the workflow, not by management alone: we describe what happens, not what was intended.
Store it where the work happens
The write-ups are made available where the workflow takes place: linked from the program in use, findable through search, sensibly named and under a fixed address that still works a year from now. A write-up you have to hunt for does not get read.
Agree upkeep and hand over
Finally we set the responsible role, the review trigger and the interval per workflow and brief the people involved. On request we take on the regular review as part of ongoing support and get in touch when a system change calls for an adjustment to the write-up.
Not everything needs to be described. Together we pick the workflows where staff absence, onboarding or evidence obligations create the most pressure, and we scope them cleanly: where does the workflow start, where does it end, and what explicitly does not belong to it. This scoping decides how long the write-up will later be.
We watch where the work happens and ask questions at the points where decisions are made. Per workflow this usually takes a few hours and regularly surfaces steps that appear in nobody's mental picture of their own process. This capture is also the core of the process analysis.
The capture becomes a short write-up per workflow with trigger, steps, responsibilities, exceptions and the systems involved. It is checked by the people who carry out the workflow, not by management alone: we describe what happens, not what was intended.
The write-ups are made available where the workflow takes place: linked from the program in use, findable through search, sensibly named and under a fixed address that still works a year from now. A write-up you have to hunt for does not get read.
Finally we set the responsible role, the review trigger and the interval per workflow and brief the people involved. On request we take on the regular review as part of ongoing support and get in touch when a system change calls for an adjustment to the write-up.
since 2013
experience with business IT
50+
projects delivered (project experience)
up to 10 years
retention of books and records (German Fiscal Code)
2-4 weeks
typical time to the first write-ups (project experience)
Three ways to hold on to process knowledge
Which one fits depends on how often the workflow changes and who is meant to work with it in future.
In the heads of experienced colleagues
- Included: Close to practice, because it comes straight from the daily work
- Included: No writing and no upkeep effort
- Not included: Unavailable during holidays, sick leave or after a resignation
- Not included: Onboarding permanently ties up your most experienced person
- Not included: Cannot be evidenced for audits or inspections
A large manual, written once
- Included: Covers many areas in one go
- Included: Looks convincing in an inspection situation at first
- Not included: Its sheer size means it is not read in daily work
- Not included: Out of date from the first change to the workflow
- Not included: Upkeep is not planned for and therefore does not happen
Short write-ups with agreed upkeep
- Included: A few pages per workflow, readable and editable on their own
- Included: Stored where the workflow is carried out
- Included: Responsible role, review trigger and status per write-up
- Included: Procedural documentation for the tax-relevant parts
- Not included: Needs a fixed responsibility, otherwise this route decays too
Typical starting points in documentation projects
Illustrative scenarios from typical project situations (project experience), anonymised and without client details.
What process documentation costs
Documentation cannot sensibly be sold at a flat rate, because the effort depends on the state of the workflows. Where responsibilities and leading systems are already settled, writing it down is quick. Where every second step first requires clarifying who actually decides and which system is right, the real work sits in that clarification. This is why the capture comes first and the binding price afterwards. All amounts quoted are entry prices and are net plus VAT.
The three building blocks at a glance
All prices net plus VAT. The binding fixed price for delivery is set after the capture.
Capture and current-state write-up
Capture of the selected workflows with a report and prioritised measures.
- Capture on site or by video call, depending on the workflow
- Current-state write-up with trigger, steps, responsibilities and exceptions
- List of findings covering media breaks, duplicate entry and waiting times
- Prioritised measures with an effort range and a suggested order
- Written report you may use freely, even without a follow-up order
Delivery per measure
Storage structure, procedural documentation and the automation derived from it.
- Storage set up with a fixed address, clear naming and searchability
- Procedural documentation for the tax-relevant workflows
- Onboarding path and cover arrangement per documented workflow
- On request an automation or interface from the same findings
- Handover with a briefing for everyone involved and agreed upkeep
Upkeep and review
So the write-ups still hold a year from now.
- Regular review of the write-ups at the agreed interval
- Adjustment after software or workflow changes within the agreed scope
- A heads-up when a system change calls for an adjustment
- One named contact instead of rotating ticket handling
- Cancellable monthly at the end of the agreed period
All prices net plus VAT. The binding fixed price for delivery is set after the capture. Third-party licences and fees are shown separately.
What happens at your company when a key person is away for two weeks?
Tell us the workflow that comes to mind first. We will tell you how much a capture would involve and whether a write-up or an automation is the better next step.
A write-up is good when the stand-in can carry on with it the next morning without picking up the phone.