The Difference Between a Process, a Procedure, and a Policy
Process, procedure, and policy sound interchangeable. They aren't. The simplest version: process is what you do, procedure is how you do it, and policy is when you do it. Here's why the distinction matters and how to use all three together.
Key Takeaway
The three terms get used as if they mean the same thing. They don't. Process is the sequence of work. Procedure is the detailed how-to for each step. Policy is the rule about when, by whom, or under what conditions. Once you can keep the three straight, your documentation gets clearer, your training gets faster, and your team can tell what they're looking at the moment they open a document.
The Quick Definition
You've probably heard the terms process, procedure, and policy used as if they were the same thing. They're not. Each one answers a different question about the work.
The sequence of tasks and decisions that produce the outcome. The big picture of how the work flows.
The detailed instructions for each step. The exact mechanics that turn a step into a result.
The rule about timing, ownership, and conditions. The boundaries that govern when and by whom.
That's the entire framework. Process is the what. Procedure is the how. Policy is the when. Three sentences. Most teams can hold all three in their heads after one quick walkthrough.
Why Confusing These Three Causes Problems
If you don't have a clear distinction between the three, you lose a really useful teaching framework. Your team can't tell whether they're being taught what to do, how to do it, or when it has to happen. They remember less of any of it because the layers are blurred together.
Here's where the cost shows up:
- SOPs that try to be everything. A document that mixes the sequence, the detailed mechanics, and the timing rules ends up being too long for any of them and too vague for all of them. The team stops opening it.
- Training that doesn't stick. If you don't separate "what to do" from "how to do it" from "when to do it," the team can't tell which part they're supposed to memorize and which part they can look up. Everything gets treated as equally important, which usually means nothing gets remembered.
- Inconsistent enforcement. When policies (the when) aren't separated from procedures (the how), it's easy to skip a policy because it looked like a piece of detailed advice rather than a rule. The team isn't being negligent — they couldn't tell which part was the rule.
Keeping the three distinct lets you teach each layer cleanly. The team can grasp it without having to reverse-engineer what you actually meant.
A Real Example: All Three for an Inbound Sales Rep
The fastest way to make this stick is to see all three for the same job. Here's an inbound sales rep at a small business.
| Layer | Example |
|---|---|
| Process — what they do | Answer the phone → qualify the customer → offer a solution that fits → close the sale on the call (or schedule the follow-up). |
| Procedure — how they do it | The opening script when they pick up. The qualifying questions and how to score the answers. How to position each product against each common pain point. The closing script and how to handle the most common objections. |
| Policy — when they do it | All inbound calls must be answered within three rings. If a call is missed, it must be returned within 30 minutes. Calls that go past 20 minutes must be flagged for manager follow-up. Quotes over $5,000 require a manager sign-off before being sent. |
One job. Three layers of documentation. Each layer answers a different question and the rep needs all three to do the work well.
The process by itself is too high-level — it tells you the shape of the work but not how to actually run it. The procedure by itself doesn't tell you the rules that govern timing or escalation. The policy by itself doesn't tell you what the work even is. Together, they describe the job completely.
Which One Should You Document First?
Document the process first. Always.
The process is the highest level. It defines the sequence of tasks and decisions with a clear role attached to each. Once the process is mapped, the procedures and policies have a structure to attach to. They each become "for this specific step in the process, here's the procedure" and "for this specific step in the process, here's the policy."
Trying to write procedures or policies first usually produces fragments that don't fit together. You end up with detailed how-to documents for individual tasks but no overall map of how the tasks connect. The team has all the pieces and no way to see how they form a whole job.
Once the process map exists, you can:
- Identify which steps need detailed procedures. Not every step does. The complex or judgment-heavy ones do. The obvious ones might just need a one-liner.
- Identify which steps need policies. The steps with timing rules, sign-off rules, escalation conditions, or compliance requirements. Mark them on the map.
- Build out the procedures and policies as separate documents. Linked from the process map but living separately. That way each document does one job and stays scannable.
For more on prioritizing which processes to document first, see the 80/20 rule for process documentation. For the process-mapping format itself, see process mapping for small businesses.
How the Three Work Together as a System
Process, procedure, and policy describe the same work from three different angles, and they reinforce each other when they're aligned. The process gives you the sequence. The procedures fill in how to do each step well. The policies set the boundaries — when, by whom, and how fast.
When the three are aligned, the team has everything they need. They can see the map (process), they can find the detailed how-to where it matters (procedure), and they know the rules they have to operate within (policy). Decisions get made faster because the answer is usually in one of the three documents.
When they're not aligned, you get gaps. Common ones:
Gaps That Show Up When the Three Don't Match
Process exists, but procedures don't match. The team knows the sequence but not how to execute it well. Quality varies between operators.
Procedures exist, but policies are missing. The team knows how to do each step but isn't sure what the rules are. Things drift past their deadlines without anyone noticing.
Policies exist, but no one tied them to the process. The team has rules but doesn't know which steps the rules apply to. They miss the policy because they didn't know it was relevant.
The fix is to keep the three documents linked. The process map is the spine. Procedures and policies hang off specific steps. Anyone looking at the work can navigate from any layer to the others.
The Right Format for Each One
Different layers benefit from different formats. Don't try to use one format for everything.
| Layer | Best Format | Why |
|---|---|---|
| Process | Process map (visual flowchart) | The visual makes the sequence obvious and surfaces inefficiency. Text-based processes hide the structure. |
| Procedure | Short-form video with transcript, hosted in PlaybookBuilder, Trainual, or similar | The how is best taught through demonstration. Video captures the nuance and the transcript makes it searchable. |
| Policy | Written document, marked on the process map at the steps where it applies | Policies are rules, and rules need to be unambiguous. Written and visible. |
The combination is powerful. A team member working on a step can see where it fits in the process map (visual sequence), watch the video procedure for the detailed how-to, and check the policy markers on the map for the rules that apply. Three formats, all reinforcing each other.
If you want the mechanics of capturing procedures on video, see how to turn a 10-minute screen recording into a complete SOP.
How to Explain This to Your Team
Don't overcomplicate it. Three sentences:
- Process is what you do.
- Procedure is how you do it.
- Policy is when you do it.
That's the entire teach. The team doesn't need a 30-minute lecture. They need to be able to remember it and apply it the next time they open a document. Three short sentences are easier to remember than a paragraph.
If you want to reinforce it, give them an example from your own business — like the inbound sales rep example above — and have them point at which layer is which. Once they can do that, they have the framework, and the next time they look at a piece of documentation, they can tell what it is at a glance.
The Trap of "We Have It All in One Document"
Some owners write a single mega-document that covers process, procedure, and policy together for one job. It feels efficient. It almost never gets used. The team can't tell what part is what, the document is too long to scan, and updates to one layer (a policy change, for example) require editing the whole thing. Keep them separate documents that link to each other, and the maintenance gets easier and the usage goes up.
Where to Start This Week
Pick one job in your business. Walk through these three questions:
- What's the process? Sketch the sequence — the major steps and decisions, in order, with names attached.
- Which steps need procedures? The complex ones, the ones with judgment, the ones where quality varies. Plan a short video for each.
- Where do policies apply? Mark the steps with timing rules, sign-off rules, escalation conditions. Write the policies as one-line rules.
Half a day of work later, you have the three documents for one job. Show them to the team. Watch them be able to point at each layer and say "this is what, this is how, this is when." That clarity is the entire payoff. Once they have it, every future piece of documentation gets easier.
For the broader systemization arc, see The Systemization Roadmap. For the practical framework on building out a single repeatable system, see how to build repeatable systems that free up your time.
Want Help Mapping Your First Process?
The Systems Effect builds process maps, procedures, and policies for owner-operated businesses, organized so your team can actually use them. We start with the process closest to revenue and work outward.
Book a Discovery CallFrequently Asked Questions
What is the actual difference between a process, a procedure, and a policy?
The simplest version: process is what you do, procedure is how you do it, and policy is when you do it. A process names the steps that produce the outcome. A procedure spells out how each step should be performed in detail. A policy sets the rules that govern when, by whom, and under what conditions the work happens. The three describe the same work from three different angles, and a real system uses all three.
Why does confusing the three cause problems in businesses?
When you blur the three terms together, you lose a really useful teaching framework. Your team can't tell whether they are being taught what to do, how to do it, or when it has to happen, so they remember less of any of it. Keeping the three distinct lets you teach each layer cleanly and lets the team grasp it without having to reverse-engineer what you actually meant.
Can you give a real-world example of all three?
Take an inbound sales rep. The process is the sequence of work — answer the phone, qualify the customer, offer a solution, close the sale. The procedure is the script of exactly what to say when the phone is answered. The policy is the rule that all inbound calls must be answered within three rings or returned within 30 minutes. Same job, three layers of documentation. Each layer answers a different question for the rep.
Which one should a small business focus on documenting first?
Document the process first. The process is the highest level — the sequence of tasks and decisions with a clear role attached to each. Once the process is mapped, the procedures and policies have a structure to attach to. Trying to write procedures or policies first usually produces fragments that don't fit together because the bigger picture wasn't drawn yet.
How do processes, procedures, and policies work together as a system?
They describe the same task from three different angles, and they reinforce each other. The process gives you the sequence. The procedures fill in how to do each step well. The policies set the boundaries — when, by whom, and how fast. When the three are aligned, the team has everything it needs. When one contradicts the others, you get gaps the team has to navigate by guessing.
What format works best for documenting each one?
Process maps are the best format for processes — the visual makes the sequence obvious and surfaces inefficiency. Procedures work best as short-form videos with transcripts, hosted in a real platform like PlaybookBuilder or Trainual. Policies usually live alongside SOPs and can also be marked on the process map at the steps where they apply. Different formats for different layers, all pointing at the same work.
How do you explain these distinctions to your team without overcomplicating it?
Keep it three sentences. Process is what you do. Procedure is how you do it. Policy is when you do it. That's it. The team doesn't need a 30-minute lecture on the framework. They need to be able to remember it and apply it the next time they see one of the three documents. Three short sentences are easier to remember than a paragraph.