How to Document a Manual Process Before You Automate It
To document a manual process before automating it, you need to capture five things in writing: who does each step, what triggers it, what decisions get made along the way, what systems or files are touched, and what the output looks like. Do this before you speak to any developer or pick any tool. Without it, you will either build the wrong thing or spend your budget on a scoping exercise that you could have done yourself in an afternoon.
Why Documentation Comes First
Most failed automation projects share one root cause: the process was documented after the build started. Someone describes how a workflow should work, the developer builds it, and then the exceptions, edge cases, and informal handoffs surface during testing. At that point, fixing them costs significantly more than if they had been captured upfront. A written process document is not a bureaucratic formality. It is the specification your tool will be built from.
Tip
If your process lives entirely in one person's head, start by recording a screen-share walkthrough with them narrating what they do. Transcribe it, then use the steps below to turn that transcript into a structured document.
How to Document a Business Process: A Step-by-Step Method
- Name the process and define its boundaries. Give the process a plain-English name (for example, "New client onboarding" or "Monthly supplier invoice reconciliation"). Define where it starts (the trigger) and where it ends (the output). Without clear boundaries, documentation sprawls and becomes unusable.
- List every person or team involved. Write down every role that touches the process, even briefly. Use job titles rather than names so the document stays valid when staff change. Note whether each role is internal or external (for example, a client, a supplier, or an accountant).
- Walk the process from trigger to output, one step at a time. Do this with the person who actually does the work, not just the manager who thinks they know. Write each step as a single action with a subject: "Finance assistant exports the aged debtors report from Xero." Avoid bundling multiple actions into one step.
- Mark every decision point. Anywhere the process branches, write out all the possible paths. For example: "If the invoice total exceeds £5,000, the Finance Director must approve before payment is released. If below £5,000, the Finance Assistant can approve directly." Decision points are the most commonly missed part of informal process capture.
- Record every system, file, and data source involved. List the software tools used at each step (spreadsheets, email, accounting software, CRMs, shared drives), the file formats data moves between, and any manual data entry that bridges two systems. These gaps are usually where automation saves the most time.
- Note the exceptions and workarounds. Ask the person doing the work: "What happens when something goes wrong?" and "Is there anything you do differently for certain clients or cases?" These informal workarounds are critical. Automating a process without accounting for them produces a tool that breaks on day two.
- Capture volumes and frequency. How many times does this process run per day, week, or month? How many records, invoices, or requests does it typically handle? Volume data shapes whether automation makes commercial sense and helps a developer size the solution correctly.
- Validate the document with everyone who touches the process. Send the draft to each role involved and ask one question: "Is there anything you do that is not captured here?" Do this before handing the document to any developer. A fifteen-minute review at this stage saves weeks of rework later.
What a Good Process Document Looks Like
You do not need specialist software to produce a useful process document. A shared Google Doc or Notion page is sufficient for most small and mid-sized businesses. What matters is structure, not presentation. A well-structured document includes a summary section at the top, the step-by-step flow in the body, a separate section for decision rules, and an appendix listing every system touched. Below is a simple template structure you can copy.
| Section | What to Include |
|---|---|
| Process name | Plain-English title and a one-sentence description of its purpose |
| Owner | The role responsible for the overall process running correctly |
| Trigger | What starts the process (an email, a calendar date, a form submission, etc.) |
| Steps | Numbered list, one action per step, with the responsible role named |
| Decision rules | Every if/then branch written out explicitly |
| Systems and data | Every tool, file type, and data source involved |
| Exceptions | Known edge cases and how they are currently handled |
| Volume and frequency | How often the process runs and at what scale |
| Output | What a successful completion looks like (a sent email, an updated record, a filed document, etc.) |
Common Mistakes That Derail Process Documentation
- Documenting the ideal process, not the real one. People naturally describe how a process should work rather than how it actually works. Push for the real version by asking "show me the last time you did this" rather than "walk me through how it works".
- Skipping the exceptions. The 80% of cases that follow a clean path are usually straightforward to automate. It is the remaining 20%, the edge cases and manual overrides, that determine whether a tool is actually usable in practice.
- Using vague step descriptions. "Process the order" is not a step. "Copy the customer's delivery address from the order email into the dispatch spreadsheet" is a step. Specificity is what makes a document actionable for a developer.
- Not updating the document after validation. The first draft is never final. Build in a review loop before treating the document as a specification.
- Confusing process mapping with flowchart software. A BPMN diagram in specialist software is useful for complex enterprise workflows, but for most UK SME processes, a clearly written numbered list is faster to produce and easier for all stakeholders to understand and challenge.
How to Use the Document Once It Is Done
A completed process document serves three purposes. First, it is the brief you hand to a developer or automation partner, so that what gets built reflects reality. Second, it surfaces whether automation is actually the right answer: some processes, once written down clearly, reveal that the underlying problem is a missing policy or a data quality issue, not a software gap. Third, it becomes your acceptance criteria: when the tool is built, you test it against every step, decision rule, and exception in the document.
Note
If you are working with Bedrock Team on a custom tool or internal app, bringing a completed process document to your first conversation significantly shortens scoping time and reduces the chance of scope creep during the build.
Deciding What to Automate First
Once you have documented several processes, you need to prioritise. The strongest candidates for automation combine high frequency (the process runs many times per week), high manual effort per run, low tolerance for human error, and a clear, consistent set of rules with few exceptions. Processes that are highly irregular, depend on subjective judgement, or involve complex external negotiations are usually poor early targets, regardless of how painful they feel.
| Factor | Good Automation Candidate | Poor Automation Candidate |
|---|---|---|
| Frequency | Runs daily or multiple times per week | Happens once a quarter or ad hoc |
| Rules | Clear, consistent decision logic | Heavily dependent on context or judgement |
| Data | Structured, consistent input formats | Free-text, variable, or unstructured inputs |
| Exceptions | Few and well-defined | Many, unpredictable, or poorly understood |
| Error cost | Errors are costly or create compliance risk | Errors are easily caught and corrected manually |
Process Documentation as an Ongoing Practice
The most operationally resilient UK businesses treat process documentation as a standing habit rather than a one-off pre-automation exercise. When a new hire joins and asks how something works, a written document already exists. When a process breaks, the document is the starting point for diagnosing where. When you bring in an external technical partner to build a tool, the handoff is clean and fast. Building this habit does not require a dedicated ops team. It requires a consistent template, a shared place to store documents, and the discipline to update them when the process changes.