Fernside Studio
Background
Archive
Journal Entry

Process Documentation That Actually Gets Used

Documented
Capacity
7 MIN READ
Domain
AI & Automation

You’ve documented processes before. They sat in a Google Drive folder, got outdated within a month, and nobody referenced them. Here’s how to write process documentation that people actually use, and that doubles as an automation specification when you’re ready to build.

Why Most Process Docs Fail

Ops managers get told to “document everything” and produce one of two failure modes.

Too detailed. A 12-page walkthrough of every click in your CRM. Nobody reads it, and it’s obsolete the moment the interface changes.

Too vague. “Follow up with the client and move them to the next stage.” Useless to a new hire, useless to whoever eventually tries to automate it.

Beyond length, three other problems kill documentation:

  • Not maintained. Written once during onboarding, never touched again. Six months later it describes a process you no longer follow.
  • Not accessible. Buried three folders deep in a shared drive nobody browses. If people can’t find it in ten seconds, they’ll ask a colleague instead, and the doc dies quietly.
  • Wrong format. Walls of prose. Readers scan in an F-shaped pattern, hitting the first few words of a line and skipping the rest, a pattern well established in usability research going back to Jakob Nielsen’s original eyetracking studies. Dense paragraphs simply don’t get read.

This is the same failure pattern we cover in mapping your business workflows, documentation and workflow mapping are the same discipline wearing different clothes. If the map is wrong, the automation you build on top of it will be wrong too.

The Dual-Purpose Format

Write documentation once, for two readers: the human doing the job today, and the future automation (or the developer building it).

Both readers need the same six things:

  1. Trigger: what starts this process? (New enquiry submitted, invoice overdue by 7 days, contract signed.)
  2. Inputs: what information or materials does the process need to begin?
  3. Steps: the sequence of actions, in order, at a consistent level of detail.
  4. Decisions: where does the process branch, and on what condition?
  5. Outputs: what exists at the end that didn’t exist at the start?
  6. Exceptions: what happens when something goes wrong or doesn’t fit the standard path?

This is the Docs as Code philosophy borrowed from software teams: treat documentation as a structured artefact with a predictable shape, not free-form prose. It’s also, not coincidentally, close to how you’d specify a workflow automation: trigger, inputs, logic, outputs map directly onto how tools like n8n or Zapier are configured. Write it this way once and you save yourself rewriting it later when you’re ready to automate.

The Right Level of Detail

The hardest judgement call is granularity. Too much and nobody reads it. Too little and it’s not actually documentation.

Use the new-hire-with-context test: could a competent new starter, who already understands your industry and has read the doc once, follow this process correctly on their second day, without pinging a colleague?

That bar rules out both failure modes:

  • It rules out documenting every mouse click, because a competent new hire doesn’t need “click the blue button”, they need “approve the invoice in Xero.”
  • It rules out vague platitudes, because “follow up with the client” doesn’t tell a new hire what to actually send, when, or what triggers the next step.

If you’re unsure whether a step needs more detail, ask: would a new starter make a different decision than an experienced person at this point? If yes, spell it out. If no, leave it as a single line.

Keeping Docs Alive

Documentation isn’t a project with an end date, it’s a system that needs maintenance, the same way your website’s page speed needs monitoring after launch, not just at launch.

Institutional memory loss is a real, measured cost. Panopto’s 2021 workplace knowledge study found the average UK employee wastes over 5 hours a week either recreating existing knowledge or waiting on colleagues who hold it, a knock-on cost researchers estimated in the tens of thousands of pounds per employee per year across large organisations. Documentation that’s actually used is a direct offset against that cost.

Four habits keep docs alive instead of letting them rot:

  • Link from where the work happens. Attach the doc to the relevant task or project in your task management tool, not just a folder. If people encounter it mid-task, they’ll actually open it.
  • Assign an owner. Every process doc needs one named person accountable for its accuracy, not “the ops team,” a person.
  • Review quarterly. Put a recurring calendar reminder against each doc’s owner. Ten minutes to check it still matches reality.
  • Version it. Note the date and what changed at the top of the doc. When a process shifts, update the doc in the same sitting, not “later.”

Template and Worked Example

Here’s the structure. Copy it directly.

## Process: [Name]
Owner: [Name]
Last reviewed: [Date]

**Trigger:** What starts this process?

**Inputs:** What do you need before you can start?

**Steps:**
1. ...
2. ...
3. ...

**Decisions:**
- If [condition], then [branch A]
- If [condition], then [branch B]

**Outputs:** What exists when this is done?

**Exceptions:** What happens when it doesn't go to plan?

Worked example, client onboarding:

## Process: Client Onboarding
Owner: Priya (Ops Lead)
Last reviewed: 2026-07-01

**Trigger:** Signed contract received via DocuSign.

**Inputs:** Signed contract, client contact details, service tier.

**Steps:**
1. Create client folder in shared drive using naming convention [ClientName-Year].
2. Add client to CRM with service tier tag.
3. Send welcome email (template: Onboarding-01) within 1 business day.
4. Schedule kickoff call within 5 business days.
5. Add client to relevant Slack channel if Studio Site tier or above.
6. Create project board from onboarding template.

**Decisions:**
- If service tier is Launch Sprint, skip step 5 (no ongoing channel).
- If client doesn't respond to welcome email within 3 days, owner sends manual follow-up.

**Outputs:** Client active in CRM, kickoff call booked, project board live.

**Exceptions:** If contract is signed but payment hasn't cleared, hold onboarding until payment confirms, flag to finance.

Notice this example hits the new-hire-with-context bar. It’s specific enough to follow without hand-holding, and structured enough that an automation could be built directly from it: trigger, conditional branches, and outputs are already separated out.

What Happens Next

Once a handful of processes are documented this way, two things usually happen. First, people actually start using them, because they’re short, scannable, and linked from where the work happens. Second, you’ve quietly built a specification for whichever processes are worth automating first, see our guide on what to automate first if you’re not sure where to start.

Documentation and automation aren’t separate projects. Written well, one becomes the blueprint for the other.

Need help documenting processes for automation, or turning existing docs into a working system? Get in touch or read more about our advisory work. Soft start: pick one process, document it this week using the template above, and see if your team actually opens it.

Sources