Ops · Processes

How to Describe a Business Process So It's Actually Used

A simple document format and templates that people actually read and apply.

Why Describe a Process at All?

• So that any new person can jump into a task without an hour-long onboarding.
• So that errors are predictable, not a daily surprise.
• So that you can automate: without clear steps, there's nothing to automate.
• So that agreements don't live 'in one person's head.'

A good process document isn't a 'company-wide regulation,' but 1–3 pages that are actually used.

Document Format

A minimal framework that covers 80% of cases:

• Title: process name + goal in one sentence.

  “New Employee Onboarding: Achieve productivity in 14 days.”

• Trigger: at what point the process begins.

  “Offer signed,” “request received,” “client hasn't paid for 7 days.”

• Inputs: what is needed to start. Documents, data, access, initial artifacts.
• Steps: step-by-step, 5–10 steps. Each step: who does it → what they do → what counts as “done”.
• Outputs: what should be the result for the process to be considered complete. A document, a system status, an email to the client, a completed payment.
• Process Owner: the role or specific person responsible for the result. Not “everyone together,” but one.
• SLA (Service Level Agreement): what is considered a normal timeframe.

  “Response to client — by the end of the business day,” “onboarding — 14 days.”

• Metrics (optional): 1–2 numbers that show if the process is alive or dead.

  cycle time, % of errors, % of delays.

Fundamental Principles of a Process That Gets Used

1. Brief > Detailed Better 1.5 pages that are read than 30 pages that are waved around during an audit.
2. One Page — One Process Don't mix “sales,” “delivery,” and “procurement” in one document.
3. Step = Action + Result Bad: “Check the order.” Good: “The manager checks the payment and sets the status to Paid in the CRM.”
4. One Owner If “everyone is responsible” — no one is responsible.
5. The Process Must Reflect Reality Not how “we would like to work,” but how we actually work now. And only then improve it.
6. Updatability is More Important Than Perfection A process that can be fixed in 5 minutes is better than a perfect diagram that everyone is afraid to touch.

Parallel Viewpoints: How Different People See the Same Process

1. The Entrepreneur's View

“Process = money and risks.”

• Task: to not lose revenue and not let chaos grow.
• Important to see:
  • where money “gets stuck”;
  • where the bottlenecks are;
  • where you can automate and reduce manual labor.

A good document for an entrepreneur answers the questions: “How long does this take, who gets stuck, and what happens if this person leaves?”

2. The Operations Manager's View

“Process = a manageable assembly line.”

• Task: to make every day look predictable.
• Important:
  • clear steps and roles;
  • understandable SLAs;
  • control points: where we check quality.

A manager doesn't need poems. They need to see: “Who? Does what? By what deadline? Where will I see that everything has broken?”

3. The Executor's View

“Process = how I should work so I don't get nagged.”

• Task: to understand what exactly is expected of them.
• Important:
  • examples (“done is when…”);
  • minimal bureaucracy;
  • “if something goes wrong — who to go to.”

If after reading the document an executor thinks: “Okay, tomorrow I will do it like this” — the process is described well.

4. The Analyst's/Automator's View

“Process = a set of steps and data for automation.”

• Task: to see what can be handed over to a system or a bot.
• Important:
  • clear inputs and outputs;
  • where data appears and where it should go;
  • which steps are tied to specific people and which can be turned into scripts.

A good process description can almost be directly turned into a BPMN diagram, n8n-scenario, or bot.

5. The New Employee's View

“Process = a survival guide.”

• Task: to move from chaos to a clear routine in minimal time.
• Important:
  • simple language without jargon or corporate-speak;
  • examples of emails, screenshots, phrasing;
  • indicated points where one can ask for help.

If a junior after reading the document can complete the task on their first day — the process is described well.

6. The Client's View (External or Internal)

“Process = quality and deadlines.”

• Task: to get a predictable result in a clear timeframe.
• Important:
  • that SLAs are realistic and met;
  • that there are no endless “we'll check and get back to you.”

A process description with a clear output and deadline reduces the number of conflicts and “follow-up” messages.

Mini-Template for a Process Document

# Process Name

**Goal:**
Briefly: why the process exists and what result is considered a success.

**Trigger:**
From what moment the process starts (event or condition).

**Inputs:**
- What is needed to begin (data, documents, access).

**Steps:**
1. Role/Person — Action — Step Result.
2. Role/Person — Action — Result.
3. ...

**Outputs:**
- What should be the result (document, status, action, notification).

**Process Owner:**
- Role/Name, responsible for the overall process result.

**SLA:**
- Normal execution time for the process or key steps.

You can copy-paste this as a basic template and fill it in for a specific process.

Common Mistakes in Describing Processes

• Too much text. When it's easier to ask a colleague than to find it in the document.
• No trigger and output. People don't understand when to start and when “to consider it all done.”
• Roles are described vaguely. “Manager,” “specialist,” “responsible person” — without names and specifics.
• No SLA. Execution time is always “well, as it turns out.” It usually turns out badly.
• The process is described “as a dream,” not as it is. On paper it's beautiful, in reality — no one does it that way.
• The document is not alive. It cannot be quickly corrected, and there is no one responsible for updating it.

Quick Self-Check: Is Your Process Document Good?

Answer three questions:

1. Can a new person complete the task using this document without an additional call?
2. Is it clear who is responsible for the result, and not just “doing the steps”?
3. Looking at the document, can you understand where the work is currently “stuck”?

If the answer to at least one question is “no” — the process should be reconsidered.