A process is the "what" and "why," the high-level sequence that turns inputs into a business outcome. A procedure is the "how," the exact steps a person follows to execute one piece of that sequence. Confuse the two and you end up with documentation nobody trusts: maps too detailed to skim, and instructions too vague to follow. Map the process first, then write procedures for each step that needs one.
TL;DR:
- Mapping the process first ensures documentation captures the full workflow and decision points before creating specific task instructions.
- Procedures should include purpose, scope, owner, entry and exit criteria, detailed steps, tools, measurements, and exceptions to ensure consistency.
- Processes focus on the overall outcome across roles and teams, while procedures target repeatable tasks within a single role, with different update frequencies and audiences.
- Documenting the reasoning behind each step, including exceptions, helps preserve knowledge if personnel change or leave.
- Using hierarchical documentation like runbooks and playbooks correctly involves linking them to processes and choosing based on the level of coordination or exactness required.
Table of Contents
- What Is a Process, and When Should You Document One?
- What Does a Good Procedure Actually Include?
- How Do Process and Procedure Differ in Practice?
- What Do Process and Procedure Look Like as Examples?
- How Do Runbooks, Playbooks, and Procedures Fit Together?
- How Do You Document a Process and Its Procedures?
- What Mistakes Wreck Process and Procedure Documentation?
- Why Capturing the Reasoning Behind a Step Matters
- Turn Tribal Knowledge Into a Real Procedure Library
- Sources
- FAQ
What Is a Process, and When Should You Document One?
A process is the sequence of connected activities that carries work from a trigger to a finished outcome, often crossing departments and roles along the way. Order fulfillment is a process. Employee onboarding is a process. Neither belongs to one person's desk, and that's the point: a process document has to describe flow, not keystrokes.
A solid process document captures a specific set of elements:
- A clear start point and end point
- The inputs required and the outputs produced
- Who owns each stage (roles, not names)
- The decision points where the path branches
You need one when work regularly crosses team boundaries, when new hires can't tell where a task starts or ends, or when leadership wants to measure a stage that nobody has ever formally described. The SEI's guidance on process and procedure treats processes as the operational blueprint, the level where goals, roles, and outcomes live before anyone touches a checklist.
What Does a Good Procedure Actually Include?
A procedure is single-role, single-task, and unapologetically literal. It doesn't describe the business goal. It tells one person exactly what to click, type, measure, or sign in what order, so the outcome is the same whether it's Monday morning or the person's third week on the job.
A procedure worth keeping includes these fields, every time:
- Purpose. What this specific task accomplishes and why it exists.
- Scope. Who this applies to and what it explicitly does not cover.
- Owner. The role responsible for keeping the steps current.
- Entry and exit criteria. What has to be true before you start, and what "done" looks like.
- Steps. The exact sequence, numbered, with no ambiguity about order.
- Tools. The systems, forms, or scripts the steps depend on.
- Measurements. What you check to confirm the step worked.
- Exceptions. What to do when the standard path doesn't apply.
Procedures earn their keep in compliance audits, staff onboarding, and anywhere automation is on the table. ISO 9001's quality management framework leans on exactly this kind of controlled, repeatable procedure to make consistency provable, not just claimed.
How Do Process and Procedure Differ in Practice?
Line them up side by side and the gap becomes obvious fast:
- Scope: a process covers a full outcome across roles; a procedure covers one task inside one role.
- Audience: a process serves managers and cross-functional teams; a procedure serves the frontline person doing the work.
- Flexibility: a process tolerates variation between cases; a procedure is written to eliminate variation.
- Frequency of change: processes shift when strategy or org structure shifts; procedures shift whenever a tool, form, or regulation changes.
Pro Tip: If a document has more than one owner and covers more than one role's actions, it's almost certainly a process wearing a procedure's name.
The decision rule that saves the most rework: map the process before you automate or standardize any procedure inside it. Operations research on process mapping points to a consistent failure pattern: teams automate the steps they already have documented, without checking whether those steps still serve the outcome. You end up with a faster version of a broken sequence.
What Do Process and Procedure Look Like as Examples?
Abstract definitions rarely stick. Concrete pairs do.
- Baking a cake. The process is "bake a cake": gather ingredients, mix, bake, cool, frost, serve. The procedure is the recipe card, exact quantities, oven temperature, and timing, written so precisely that two different bakers get the same cake.
- Employee onboarding. The process covers the stages: offer accepted, paperwork completed, equipment provisioned, first-week training, thirty-day check-in. The procedure is the laptop provisioning task: which ticketing system to open, which image to install, which credentials to issue, in what order.
- IT incident response. The process is the incident lifecycle: detect, triage, escalate, resolve, review. Inside it, a playbook coordinates the response across security, engineering, and communications teams, while a runbook gives one engineer the exact commands to restart a service or roll back a deployment.
Each pair follows the same shape: one document answers what and why across a sequence, the other answers exactly how for one piece of it.
How Do Runbooks, Playbooks, and Procedures Fit Together?
Think of documentation as a hierarchy with the process at the top. Below it sits the playbook, which supplies context, strategy, and the decision gates a team uses when a situation doesn't have one obvious answer. Below that sits the procedure or runbook, the literal steps. At the very bottom sits the work instruction, often a single screenshot or a one-line command.
Picking the right artifact comes down to two questions: does this need coordination across people and judgment calls, or does it need exact, repeatable steps? Coordination points toward a playbook. Exact steps point toward a runbook or procedure.
- Use a runbook when a task is technical, scripted, and needs consistent output, such as automated deployment steps with defined rollback behavior.
- Use a playbook when multiple teams and open decisions are involved, not just one script.
- Link every document to the level above and below it instead of duplicating content between them.
Pro Tip: If you find yourself copying the same three steps into both a process map and a procedure, delete them from the process map. The process should reference the procedure, not repeat it.
How Do You Document a Process and Its Procedures?
Start broad, then narrow. Skipping straight to procedures without a process map is the single most common reason documentation programs stall out after the first few pages.
- Scope and map the process first. Define the start and end points, the inputs and outputs, and who owns each stage. Don't write a single step yet, just the shape of the outcome.
- Identify which steps need procedures. Not every stage needs one. Flag the stages where errors are costly, where new hires struggle, or where a task will be automated. Draft the steps, list the tools, and set entry and exit criteria for each.
- Assign ownership and set a review cadence. Every procedure needs a named role responsible for keeping it accurate, a version number, and a scheduled review, quarterly for anything tied to compliance, annually for lower-risk tasks.
- Train, link, and iterate. Walk the team through the new documents, link procedures back to their parent process, and revisit both based on what actually breaks in practice, not just what looked clean on paper.
Pro Tip: Write the procedure with the person who does the task, not about them. Their exceptions and workarounds are usually the most valuable part of the document, and the part a generic template never captures.
Skipping step 1 and jumping straight to procedure writing is how teams end up with twelve well-formatted documents for a workflow nobody has ever actually mapped.
What Mistakes Wreck Process and Procedure Documentation?
Four mistakes account for most of the documentation that ends up ignored:
- Mixing levels in one document. A page that tries to be both map and instruction manual satisfies neither. Split it.
- No named owner or review date. Documentation without an owner rots the moment the person who wrote it changes roles.
- Overcomplicated frontline procedures. A procedure with twenty steps and three caveats per step gets skipped, not followed. Keep it short and task-focused, per BPM documentation guidance.
- Automating before mapping. Building a workflow tool around undocumented steps locks in whatever inefficiency was already there.
Fix all four and most documentation programs stop needing constant rescue work.
Why Capturing the Reasoning Behind a Step Matters
Most documentation records the step and drops the reasoning behind it, the exception a veteran employee makes without thinking twice about. That reasoning is exactly what disappears when someone leaves. Kept's conversational capture approach is built around pulling that judgment out in a person's own words, alongside the steps, so a procedure survives the departure of the person who wrote it, not just the task list attached to it.
— Anthony
Turn Tribal Knowledge Into a Real Procedure Library
Some platforms are built for the exact gap this article describes: the space between a process map and a working procedure, where the reasoning and exceptions usually get lost. Instead of asking someone to sit down and write a formal document from scratch, they run a guided conversation and turn what a person says, in their own words, into a structured, searchable procedure a team can actually use.
For engineering teams, that means onboarding new hires from what the team already knows instead of from whatever got written down two reorganizations ago. For the person who's been quietly the only one who knows how a task actually works, it means getting that knowledge out of their head before it walks out the door with them.
Check Kept for you and Kept for business pricing to see which plan fits your team, or start a conversation to see how it captures your first process.
Sources
- Software Engineering Institute (SEI) — Process and Procedure definitions and guidance
- ISO 9001 — Quality management systems
- SolarWinds — Runbook vs Playbook: What's the difference
FAQ
What's the Difference Between a Process and a Procedure?
A process is the high-level sequence of activities that produces an outcome, spanning roles and often teams. A procedure is the detailed, step-by-step set of instructions for completing one task inside that sequence, and the SEI's process and procedure guidance treats this as the core distinction between the two.
What Is the Difference Between a Method and a Procedure?
A method is a general approach or technique, often flexible and open to judgment, while a procedure is a fixed, exact sequence of steps meant to produce the same result every time. A method might describe an overall style of doing something; a procedure pins that style down into a checklist.
Are Processes and Procedures Really Different Things?
Yes. A process defines what happens and why across a workflow; a procedure defines how one task inside that workflow gets done. Treating them as interchangeable is the most common reason documentation ends up either too vague to follow or too detailed to skim.
Can You Give an Example of a Process and a Procedure?
Employee onboarding is a process: offer, paperwork, equipment, training, check-in. Laptop provisioning is a procedure inside that process: the exact steps to open a ticket, image a device, and issue credentials. The same pattern shows up in IT operations, where a runbook handles the technical steps while a playbook coordinates the broader response.
Is an SOP a Process or a Procedure?
An SOP (standard operating procedure) is usually written at the procedure level, with exact steps for one task, though the label gets applied loosely across companies. Whether a given SOP functions as a process map or a true procedure depends entirely on how specific and role-bound its steps are.