Procedure vs Process

A process is the broader flow of work that turns an input into an outcome. A procedure is the specific set of instructions someone follows to complete a task within that flow.

The practical difference is scope. A process helps people understand how work moves across roles, systems, and handoffs. A procedure helps someone complete one repeatable piece of that work the same way every time.

Teams usually don’t confuse process and procedure because the words are hard. They confuse them because the work is tangled. A customer refund, employee onboarding flow, quote approval, or month-end close may include a broad sequence of activities and several task-level instructions. If everything gets called a procedure, the document becomes too big to follow. If everything gets called a process, the document becomes too vague to execute.

The distinction matters because each artifact answers a different question:

• A process answers, “How does this work move from start to finish?”
• A procedure answers, “What should I do next, exactly?”

A useful documentation system usually needs both levels. The process keeps the team aligned on the path. The procedure keeps the task repeatable.

You are probably looking at a process when the work involves multiple roles, stages, approvals, or handoffs. A process has a beginning, an end, and a result that matters to the business.

For example, "new customer onboarding" is a process. It may include kickoff scheduling, account setup, data import, training, success plan creation, and handoff to ongoing support. No single person performs all of that as one task. The value of the process view is that it shows how the pieces connect.

A strong process document makes ownership visible. It should show what triggers the workflow, who owns each stage, what decisions change the path, what output is expected, and where work can stall. It doesn’t need to describe every click unless those clicks change the outcome.

You are probably looking at a procedure when the reader needs to perform a repeatable task without guessing the sequence. A procedure narrows the work until the person can act.

Inside the customer onboarding process, "create a customer workspace," "send the kickoff agenda," or "verify imported data" may each need a procedure. The procedure should name the system, the required inputs, the exact steps, the decision rules, and the evidence that the work was completed.

The test is simple: if a trained employee would still ask, "Where do I click? What value do I enter? What do I do if this is missing?" the document probably needs procedure-level detail.

The most reliable documentation pattern layers a process overview with task-level procedures.

Start with the process when people are unclear about ownership, sequence, or the reason the work exists. Then add procedures for the steps where consistency matters. That avoids a common failure mode: a clean workflow diagram that can’t train anyone, or a long step-by-step guide that never explains why the step matters.

For example, a refund process might show intake, eligibility review, approval, payment processing, customer communication, and ticket closure. The eligibility review step might link to a procedure that tells a support agent how to check the account, confirm the policy, record the decision, and escalate exceptions.

That layered structure helps managers improve the workflow without rewriting every task guide, and it helps frontline employees complete the task without reading the whole operating model first.

Use the reader’s question to choose the document type.

If the reader is asking where work starts, who owns each stage, how handoffs happen, or why delays occur, create a process document. If the reader is asking what steps to follow, what standard to apply, or what evidence to save, create a procedure.

The tradeoff is detail. A process document should be detailed enough to show responsibility and sequence, but not so detailed that it turns into a click-by-click manual. A procedure should be detailed enough to prevent variation, but not so broad that the reader has to navigate an entire workflow before acting.

The first mistake is using “procedure” as a catch-all label. That can bury policies, process maps, work instructions, and checklists inside one overloaded document type. The title should tell the reader what kind of help they’re getting.

The second mistake is documenting procedures before the process is understood. Teams can create polished task guides for a workflow that is still broken. If ownership, approval rules, or handoffs are unclear, procedure writing may lock in the confusion.

The third mistake is stopping at the process map. A process map can show the right path without giving enough instruction to run it. If a step is frequent, risky, compliance-sensitive, customer-facing, or easy to do inconsistently, it likely deserves its own procedure.

Trails is especially useful at the procedure layer. It captures a workflow as someone performs it, then turns that work into a polished step-by-step guide. Teams can use those guides as procedure links underneath broader process documentation, and they can create AI-narrated video versions for training or sharing.

That layered approach keeps the process view clean while making the execution steps easier to create and maintain.

Is a process bigger than a procedure?

Usually, yes. A process describes a larger flow of work, while a procedure explains how to complete a specific task inside that flow.

Can one document include both a process and procedures?

Yes, but it should be structured clearly. Put the process overview first, then link or nest the detailed procedures under the relevant steps.

Is an SOP a process or a procedure?

An SOP is usually procedure-level documentation, but some teams use the term broadly. The better question is whether the reader needs workflow context, execution steps, or both.