Business Process Documentation: What Should You Document First?

When a company starts growing, the phrase “we need SOPs” can quickly become a request to document everything. That is usually too broad to begin with. A better question is: which processes create enough repeated work, risk, handoffs, or customer impact that a shared reference would help people do the work more consistently?

The answer is rarely a large manual. It may be a one-page checklist, a clear approval path, a template, a short screen recording, or a full procedure. Document only what helps someone act, decide, check, or recover from an exception.

This article is an operational decision framework, not a requirement to adopt a quality standard or any particular notation. The framework below is editorial guidance for prioritisation; it is not a measured formula or a guarantee of efficiency.

Start with the work that repeats

Make a rough list of recurring activities that cross people or teams. Look for work that begins from memory, varies by person, generates repeated clarification, or is frequently handed from one role to another. Common examples might include responding to a qualified inquiry, approving a supplier, onboarding a new colleague, preparing a recurring report, handling a refund, or checking a customer deliverable.

Do not start by asking every team to write down its responsibilities in general terms. Start with a concrete outcome: “A new customer has the access and information needed for the first delivery,” or “A supplier invoice is checked and routed to the right approver.” Specific beginnings and endings make it easier to see the steps and handoffs.

For each candidate process, ask:

These questions create a shortlist. They do not imply that every repeated activity deserves a formal procedure.

Prioritise by impact and uncertainty

Frequency is useful, but it should not be the only filter. A monthly process that moves a large payment or makes a consequential customer decision may deserve clearer controls than a daily task with an easy correction. A one-off unusual event may need an escalation guide even though it is not a routine SOP.

Use four qualitative lenses:

Choose one process with visible friction and a manageable scope. Include the people who do the work and the person accountable for the outcome. The UK Department for Education’s business-process notation standard, which applies within that department, describes elements such as actors, decisions, task order and outcomes. ISO’s 2026 quality-management principles brochure includes a process approach that considers activities as interconnected processes. These are references for the concepts, not universal requirements: neither says that every SME must document every activity or obtain certification.Sources: [1], [2]

Keep the document proportional to the decision

A checklist is enough when the work is short and stable

A checklist can be useful when the steps are easy to understand, the sequence is simple, and the main failure mode is forgetting one or two checks. Examples include confirming required fields before submitting a routine request or checking a standard meeting handoff. Keep each item observable: “Confirm the customer contact and agreed delivery date” is clearer than “Review the account carefully.”

A workflow is useful when handoffs or choices matter

Use a simple flow when different people act at different points or when a decision sends work down different paths. Show who owns each step, what information is needed, what approval is required, and what happens if information is missing. Avoid drawing every click or exception at the start. Capture enough to explain the normal path and the important branches.

A standard operating procedure may be appropriate when context matters

A longer SOP can help when an unfamiliar owner needs context, quality checks, system instructions, escalation rules, or guidance for several exceptions. It should state its purpose and scope, owner, prerequisites, roles, steps, evidence or records, exceptions, escalation, and review date. Use screenshots only when they add clarity, and assign responsibility for replacing them after the interface changes.

The format is secondary to whether the intended person can use it at the moment of work. If a document is hard to find, written for an auditor rather than its user, or longer than the task requires, simplify it.

Document decisions, not only actions

Many failures occur at decision points: who can approve a discount, when an inquiry is qualified, when a delivery needs rework, or which issue must be escalated. Record the decision owner and the information they need. Where policy or professional judgement is required, link to the authoritative policy or escalation contact instead of paraphrasing it in a way that may become stale.

For an important process, capture:

Do not collect personal or sensitive details in a process document unless they are necessary and approved. Describe the action and the authorised record; avoid copying real customer or employee information into examples.

Make the process easy to find and maintain

Choose a single agreed location for the current version. Include a plain title, process owner, last review date, and a short note about where related templates or policies live. If older versions need to be retained, label them clearly so staff do not mistake them for current instructions.

Assign a review trigger, not just an arbitrary annual reminder. Revisit the guidance after a system change, policy change, repeated exception, customer complaint, control failure, or shift in who owns the work. The interval should fit the importance and volatility of the process. Do not leave updates to “whoever notices.”

Test a draft with someone who did not write it. Ask them to complete a realistic example and point out where they need to guess. A short walkthrough often reveals missing prerequisites, ambiguous verbs, undocumented approvals, and dead links. Keep the final version concise enough that the team can find the answer while working.

Stabilise before automating

Documentation can expose unnecessary steps, inconsistent inputs, unclear ownership, and exceptions. Address those issues before building automation around the current workflow. Automating a process that changes every week can make changes harder to diagnose; automating poor data entry can move the same errors faster.

Once the path is stable enough, identify what is rule-based, what requires judgement, what data is needed, and what happens when a step fails. Then compare the cost and risk of automation with a checklist, integration, notification, or process change. See When Should a Growing Business Invest in Automation? for the separate question of when to invest, and Technology & Automation for the related service.

A practical first-week exercise

Ask each team to nominate one recurring process that creates rework, uncertainty, risk, or customer friction. Collect the nominations in one list. Score them with words—high, medium, low—against repeatability, consequence, and coordination rather than pretending to calculate an exact return. Choose one modest, observable process and create the smallest useful guide.

After the team tries it, note what changed in the work and what did not. If the guidance did not help, determine whether the process itself is unclear, the document is difficult to use, ownership is missing, or the team lacks a tool or authority. Do not measure success by the number of pages produced.

Frequently asked questions

How do I choose which processes to document first?

Start with repeated work, high-consequence tasks, customer-facing steps, approvals, and processes with multiple handoffs or frequent rework. Include the people who perform the work, then select one process whose scope can be described and tested.

Does every business process need an SOP?

No. Some work needs no formal document; some needs a checklist, template, workflow, or escalation note. Use the simplest form that helps the intended person complete or review the work safely and consistently.

What is the difference between a checklist and an SOP?

A checklist reminds someone to verify a small set of known steps. An SOP explains context and how to perform work, including roles, decisions, checks, and exceptions. The distinction is practical rather than universal; businesses may use different names for similar materials.

When should a documented process be automated?

Consider automation after the normal path, inputs, ownership, exception handling, and intended outcome are clear enough to specify. If the workflow is unstable or depends on judgement that has not been defined, clarify the process first.

A focused next step

Pick one process where unclear ownership or handoffs repeatedly slow the work. Map its start, finish, people, decisions, and exceptions before choosing a documentation format. Specular’s Business Consulting service can help teams examine operating processes; Technology & Automation is relevant when a stable process may benefit from a tool or integration.