Business Process Documentation Template (With Real Filled-In Examples)

A copy-paste template for documenting any process, reverse-engineered from the real SOPs and process maps that run inside our production system, plus a worked example so you can see what "done" looks like.

A good business process document includes twelve things: the process name, the function it belongs to, the one role that owns it, the supporting roles, its status, its source, the trigger that starts it, the done that ends it, why it matters, the inputs, the numbered steps with a standard on each, and the gap between how it works today and how it should work. Below is a template with all twelve, a filled-in example, and how to capture the as-is versus the should-be. Copy it, fill it in with the person who actually does the work, and you will have a document a new hire can follow without asking you.

Why Most Process Documents Fail Before They Start

Almost every process document dies the same way. Someone opens a blank page, starts typing "Step one, log into the system," and three pages later has a document that is already out of date, that nobody owns, and that no new hire will ever finish reading. The instinct to write is right. The lack of a structure is what kills it.

The reason a structure matters is that a process is not just a list of steps. It has an owner, a trigger, inputs, decisions, standards, and outputs, and if the document leaves those out, it captures the motions but not the meaning. This is the exact failure mode behind the processes that live in your head: the knowledge is real, it works, but it exists only as habit in one or two people, so it can never be handed off cleanly.

We build these documents for a living. Inside our own delivery system we have 221 process maps and 49 written SOP drafts across construction, staffing, real estate, financial servicing, home services, and nonprofits. When you line them up, they do not look like random essays. They share a skeleton. The template in this article is that skeleton, pulled straight out of the real corpus and stripped of anything client specific.

What a Process Document Should Include: The 12 Fields

Every strong process document we have built carries the same header and the same body fields. The header is the metadata that makes the document findable and accountable. The body is the actual work. Here is the full set, in the order they appear.

Field	What It Captures	Example
Process name	The process, named as a verb plus an object so it reads as an action.	"Onboard a new client"
Function / group	The department or subject area it lives under, so related processes cluster.	Operations, HR, Sales, Servicing
Owner	The one role accountable for the process running. Marked explicitly.	"Operations Coordinator (owner)"
Supporting roles	Everyone else who touches it, each with their job in parentheses.	"Sales Rep (handoff source), Owner (escalation only)"
Status	Where the document is in its life: discovered, mapped, drafted, reviewed, published.	"Reviewed"
Source & last reviewed	Where the knowledge came from and when it was last confirmed true.	"Mapping session + screen recording, June 15"
Trigger / Done	The event that starts the process and the specific result that means it is finished.	"Signed agreement arrives" to "First deliverable scheduled"
Why this matters	One to three sentences on the purpose and the cost of doing it wrong.	"The first two weeks set the tone for the whole engagement."
Inputs	What you need in hand before you can start. Documents, data, access.	"Signed agreement, completed intake form, payment method"
Steps	Numbered actions, each led by a role and a verb, each carrying a standard.	"Ops Coordinator: send welcome email within 24 hours"
Standards & outputs	How "good" is defined (timing, tools, required fields) and what the process produces.	"Kickoff booked within 5 business days; client record created"
As-is vs should-be	How it really works today, how it should work, and the gap between them.	"As-is: hallway handoff. Should-be: required handoff note."

Two of these fields are the ones people always skip, and they are the two that matter most. The first is the owner. In our real SOPs the owning role is marked in the header every single time, often with a literal "(owner)" tag, because a process with no owner is a process that quietly stops. The second is the as-is versus should-be gap, which turns a static document into a live improvement plan. More on that below.

Process Document vs SOP vs Process Map

People use these three terms interchangeably and then wonder why their documentation is a mess. They are not the same thing. They are three zoom levels on the same work, and you build them in order.

Artifact	What It Answers	Form
Process map	How does the whole thing flow, and who does what?	One page flowchart with swim lanes, 5 to 15 steps
Process document	What are the steps, standards, inputs, and outputs, in order?	Structured one to two page write up (this template)
SOP	How exactly do I perform this one step correctly?	Detailed procedure or checklist for a single step

The process map comes first, because it shows you the whole route and tells you which documents and SOPs you actually need. The process document is the structured middle layer that most people mean when they say "document the process." The SOP is the close up for a single step where getting it wrong costs money, and our guide to how to write an SOP covers that level in depth. One clean signal from the real corpus: the map defines the swim lanes (roles like "Sales," "Transaction Coordinator," "Operations"), and those exact lanes become the roles in the document. The map and the document are the same process at two resolutions.

"The map shows the route. The document is the turn by turn. The SOP is how to parallel park at one specific stop. Build them in that order and nothing contradicts itself."

The Copy-Paste Process Documentation Template

Here is the template, built from the recurring shape of every real SOP in our system. Copy the whole block, paste it into your doc, wiki, or SOP tool, delete the bracketed prompts, and fill it in. Nothing in it is optional theater. Every field earns its place because leaving it out is what breaks handoffs.

PROCESS DOCUMENTATION TEMPLATE

Process name:      [Verb + object, e.g. "Onboard a new client"]
Function / group:  [Department this lives under, e.g. Operations]
Owner:             [The one role accountable, marked (owner)]
Supporting roles:  [Everyone else who touches it + their job]
Status:            [Discovered / Mapped / Drafted / Reviewed / Published]
Source & reviewed: [Where the knowledge came from + date last confirmed]

TRIGGER:  [The event that starts this process]
DONE:     [The specific result that means it is finished]

WHY THIS MATTERS:
[1 to 3 sentences: the purpose, and the cost of doing it wrong]

INPUTS (what you need before you start):
- [Document, access, or piece of data]
- [...]

THE STEPS:
1. [Role]: [Verb + object].  Standard: [timing, tool, or definition of done]
2. [Role]: [Verb + object].  Standard: [...]
   DECISION: [Yes/no question?]  -> Yes: [path]   No: [path]
3. [Role]: [Verb + object].  Standard: [...]

STANDARDS (how "good" is defined):
- Timing / SLA:        [...]
- Tools / systems:     [...]
- Required fields:     [...]

OUTPUTS (what this produces / hands off):
- [Document, record, or result + who receives it]

HANDOFFS & ESCALATION:
- Hand off to [role] when [condition]
- Escalate to [role] when [condition]

AS-IS vs SHOULD-BE:
- As-is (today):    [How it actually works now, workarounds included]
- Should-be (target): [How it should work once fixed]
- Gap to close:     [The one or two changes that get you there]

That is the entire structure. If you can fill this in for one process, you can fill it in for every process in your business. If you want the full method behind using it well, our guide on how to document business processes walks through the interview and capture steps in detail.

A Filled-In Example: Onboard a New Client

A blank template is only half the answer. Here is the same template filled in for a process almost every service business runs, new client onboarding. Notice how every step names a role and carries a standard, and how the as-is line tells the truth about how it really works today.

Process name:      Onboard a new client
Function / group:  Operations
Owner:             Operations Coordinator (owner)
Supporting roles:  Sales Rep (handoff source), Account Manager (kickoff +
                   first deliverable), Company Owner (escalation only)
Status:            Reviewed
Source & reviewed: Mapping session with the Ops Coordinator + screen
                   recording of the last two onboardings. Reviewed Jun 15.

TRIGGER:  A signed service agreement lands in the shared inbox.
DONE:     Client account is set up, kickoff is booked, and the first
          deliverable is scheduled.

WHY THIS MATTERS:
The first two weeks set the tone for the whole engagement. A clean
onboarding earns trust and prevents the "did they forget about us?"
email. A sloppy one creates rework and a client who is nervous before
you have done any real work.

INPUTS:
- Signed agreement (PDF)
- Completed intake form (contacts, goals, access, billing)
- Assigned Account Manager
- Payment method on file

THE STEPS:
1. Sales Rep: Mark the deal Won and hand off to Operations within 1
   business day.  Standard: handoff note states scope, price, and any
   promises made on the call.
2. Ops Coordinator: Create the client record and project folder.
   Standard: use the naming convention, no free-form folders.
   DECISION: Is the intake form complete?  -> Yes: continue.
             No: request the missing fields before proceeding.
3. Ops Coordinator: Send the welcome email + scheduling link.
   Standard: sent within 24 hours of the handoff.
4. Account Manager: Run the kickoff call, confirm goals, set the first
   deliverable date.  Standard: kickoff booked within 5 business days.
5. Ops Coordinator: Set up billing and confirm the payment method.
   Standard: first invoice scheduled before kickoff.
6. Account Manager: Post the onboarding summary and mark it complete.

STANDARDS:
- Timing / SLA:    Welcome email within 24 hrs; kickoff within 5 days.
- Tools / systems: CRM, shared drive, scheduling tool, billing platform.
- Required fields: Record must have contact, goals, scope, billing, and
                   Account Manager before onboarding is marked complete.

OUTPUTS:
- Client record in the CRM -> visible to the whole team
- Kickoff call on the calendar -> invite to client + Account Manager
- Onboarding summary -> posted in the client channel

HANDOFFS & ESCALATION:
- Hand off to the Account Manager once the record exists and kickoff
  is booked.
- Escalate to the Company Owner when scope or price on the signed
  agreement does not match the CRM, before kickoff.

AS-IS vs SHOULD-BE:
- As-is (today):    Sales tells Ops in a hallway chat. Half the intake
                    fields are missing, so the coordinator chases the
                    client for a week and the kickoff slips.
- Should-be (target): A standard handoff note carries scope and price,
                    the intake form is required before a deal can be
                    marked Won, and the welcome email fires automatically
                    when the record is created.
- Gap to close:     Make the handoff note mandatory and require the
                    intake form to close the deal.

Read that top to bottom and you can run the process. That is the bar. It took a page. Not every process needs six steps, and not every business calls these roles the same thing, but the shape holds whether you are onboarding a client, closing the books, or following up on a quote.

How to Capture the As-Is vs the Should-Be

This is the field that separates a filing exercise from a business improvement, and it is the one our real SOPs treat as a first class section rather than an afterthought. In the corpus it shows up with headings like "The Gap We're Closing," and it always follows the same discipline: document how the process runs today, honestly, then document how it should run, and name the specific change that closes the distance.

The order matters. Capture the as-is first, and capture it with the workarounds intact. The most common mistake is documenting the ideal, the polished version you would describe to a customer, which produces a fantasy nobody follows. Sit with the person who does the work and write down what actually happens, including the part where they re-key the same data twice because two systems do not talk. The processes worth documenting first are usually the ones where the as-is is most painful.

Only once the real version is on the page do you write the should-be. This is the target state after you remove the obvious breakpoints: the missing handoff note, the manual step that should be automated, the approval that should not need the owner. Then you name the gap, the one or two changes that move you from current to ideal. In the filled example above, the whole gap came down to two changes: make the handoff note mandatory, and require the intake form to close the deal. That is a plan, not a wish.

From Document to a Trained Team

A process document is a means, not an end. Its whole job is to let you delegate, improve, and train against the process instead of holding it in your head. Once the document exists, the path forward is short.

The fastest way to turn a document into training is not to write more prose. It is to have the person who owns the process record their screen once while doing the work, then turn that screen recording into an SOP. The document told you what to record and in what order. The recording captures the how, including the small judgment calls that never make it into text. You end up with a readable document and a watchable version that both point at the same steps.

You also do not need to document everything before you get value. Following the 80/20 of process documentation, the handful of processes that cause the most pain or run through you most often will deliver the vast majority of the relief. Document those first, to this template, and hand them to someone who is not you. Do that across your top five or six processes and you have built the thing most owners never do: a business that can run a week without you in the room.

The Bottom Line

A process document is not a wall of text and it is not corporate theater. It is a short, structured capture with a predictable shape, twelve fields, one owner, numbered steps that each carry a standard, and an honest as-is versus should-be that turns the document into a plan. We did not invent that shape. We reverse-engineered it from 221 process maps and 49 SOP drafts that run real businesses, and it repeats because it works.

You do not need to document your whole company this month. Copy the template, pick the one process that is causing the most pain, sit with the person who actually does it, and fill it in. One honest page is worth more than a hundred perfect ones you never wrote. That first document is how you stop being the bottleneck.