Process Documentation Template: Fields, Example, and PDF Tips

A good process documentation template has ten fields: purpose, owner, trigger, roles, inputs, steps, decisions and exceptions, outputs, tools, and a revision record. Most templates stop at the steps. The part that actually saves you when someone leaves is the decisions and exceptions field, and that is the one most templates leave out. Below you will find the full template, a filled-in sales example, and a plain method for keeping it accurate.

TL;DR

• Use ten fields: purpose, owner, trigger, roles, inputs, steps, decisions and exceptions, outputs, tools, revision record.
• A process says what happens and who is involved. A procedure says how one person does one task. Write both, and keep them apart.
• The most valuable field is "decisions and exceptions". It records the judgment calls that steps alone never capture.
• Name an owner and a review trigger for every document, or it will be stale within a year.
• A PDF is a good export format, not a good home. Keep the living version somewhere searchable.

Table of Contents

• Process, procedure, workflow: which template do you need?
• The process documentation template
• A filled-in example: documenting a sales process
• How to write a process document from start to finish
• Adapting the template for onboarding, retention, and complex work
• Keeping documentation accurate over time
• Using a process documentation template as a PDF
• Our perspective
• Capture the reasoning, not just the steps
• FAQ
• Sources

Process, procedure, workflow: which template do you need?

People search for "process documentation template," "procedure documentation template," and "workflow documentation template" as if they were three different things. They overlap, but the distinction is useful. Software engineering guidance from Carnegie Mellon's Software Engineering Institute puts it this way: a process defines what needs to be done and which roles are involved, while a procedure defines how to do the task and usually applies to a single role.

In practice:

If you are documenting how a lead becomes a signed customer, that is a process. The steps for entering a quote in your CRM are a procedure inside it. Mixing the two is a common reason documents get long, hard to scan, and ignored. We wrote about what breaks when process and procedure get confused, especially once you try to automate.

The process documentation template

Copy this structure into whatever tool your team already opens every day. Each field has a job.

The identification code and the approval signature are not our invention. They show up in formal administrative guidance too: Argentina's UNNE university specifies identification codes and authorization signatures in its guide to administrative procedures. You may not need signatures, but you do need to know who approved the version people are following.

What documents hold, and what people hold

The table above has two kinds of fields. Most of them capture what a document can easily hold: sequence, roles, inputs, outputs. One field captures what the person holds: why a step exists, when to skip it, what to do when the customer is an exception.

A template that only has a steps box produces documentation that reads cleanly and fails the first time something unexpected happens. That's why the decisions and exceptions row is not optional.

A filled-in example: documenting a sales process

Sales is where readers most often ask for examples, so here is a compact one for a B2B inbound lead process. The numbers are illustrative, not benchmarks.

Title: Inbound lead to signed order (SAL-003) Purpose: Turn qualified inbound requests into signed orders within an agreed response time. Owner: Head of Sales Trigger: A demo request arrives through the website form or an email to the sales inbox. Roles: Sales development rep (qualifies), account executive (runs demo and negotiates), sales operations (contract and handoff), finance (credit check above the threshold).

Steps:

1. Rep checks the CRM for an existing account and owner.
2. Rep qualifies the request against the fit criteria (team size, use case, timeline).
3. Qualified leads are assigned to an account executive.
4. Account executive runs the discovery call and demo.
5. Account executive sends a proposal.
6. Contract is reviewed and signed.
7. Sales operations hands the account to onboarding with the handoff notes.

Decisions and exceptions:

Outputs: Signed contract in the contract folder, closed-won record in the CRM, handoff note delivered to onboarding.

Notice what the example does. The steps take seven lines. The decision table is where a new hire would otherwise have to ask someone. For more worked cases, see our process documentation examples that capture exceptions.

If you document a sales process as a playbook, the same idea applies. Each play needs a trigger, a target, steps, assets, and a point where you stop. The difference is audience: a playbook coaches a seller, while a process document lets someone else run, audit, or hand off the work.

How to write a process document from start to finish

The template is the container. Filling it well is the work. This is the order we recommend.

1. Pick one process and one reason. "Onboarding new customers" is a process. "Everything operations does" is not. Start with something that is painful, frequent, or held by one person.
2. Name the owner and the reader. A document for an auditor reads differently from one for a new hire on day three.
3. Capture the process by talking, not typing. Ask the person who does it to walk you through the last real case. Real cases surface exceptions that a blank page never does. Investigators and oral historians work this way for the same reason: people remember through specific events, not summaries.
4. Draft the steps. Verbs first, one action per line, no more than about a dozen steps. If you have more, you have two processes.
5. Interrogate the decisions. For every "if" or "it depends," ask: what did you look at, what threshold did you use, and when have you broken that rule?
6. Test it on someone unfamiliar. Give it to a person who has never done the task and watch where they stop. Our seven steps to create SOPs that pass an unfamiliar user test go deeper on this.
7. Publish where people already work, with a review date and the owner's name on it.

For a longer version of this method, see our seven steps to process documentation that keeps decisions. If you want to draw the flow as well as write it, our process mapping guide covers workshop steps and decision capture.

Adapting the template for onboarding, retention, and complex work

The ten fields are a baseline. Different jobs need different emphasis.

For onboarding

Add a "first week" lens. For each process, mark the three things a new hire must get right and the three they can learn later. Add a "who to ask" line with a role, not a name, so it survives reorganizations. Newcomers don't need every exception on day one, but they need to know exceptions exist.

For knowledge retention

When the goal is protecting what a departing expert knows, flip the proportions. Keep the steps short and spend most of the page on decisions, thresholds, and the reasoning behind them. Record the expert's own words where you can. Paraphrase flattens judgment into rules, and the rules are the part everyone already had. Our post on capturing decisions, not steps explains why.

For complex or multi-team workflows

Split the document. Keep one process-level page that shows the whole flow and the handoffs, and link to a separate procedure for each role's tasks. Add a "depends on" and "feeds into" field so people can see what breaks if they change something. When processes cross systems, a diagram exported in a standard notation helps; we cover that in AI process mapping with BPMN export.

For specific functions

IT teams have their own recurring patterns, such as tickets, escalations, and runbooks, and our 90-day plan and templates for IT help desk documentation shows how to stage that work. For project teams, the template that matters most is the handoff; see four project handover templates that get used.

Keeping documentation accurate over time

Most process documents are accurate for about a month. After that, the work changes and the page doesn't. Three habits prevent most of the drift.

Give every document an owner and a review trigger. A calendar date is fine, but event triggers are better: a tool changes, a role changes, a customer complaint reveals a gap, an auditor asks a question you can't answer from the page.

Record changes, not just versions. The revision record should say what changed and why. Our guide on making process change documentation audit-ready lists what reviewers look for.

Keep the field and the office on the same page. Teams that work away from a desk, such as crews, technicians, or site supervisors, often have the most drift between the documented process and the real one. Practices from construction document control show how controlled, field-to-office records can keep everyone working from the current version.

Also make documents searchable. People who can't find a process in thirty seconds will ask a colleague, and the document dies. Use plain titles, the words your team actually says, and a consistent ID. Search should return the answer and the page it came from, so readers can check it.

Using a process documentation template as a PDF

A PDF is useful in three situations: you need a fixed copy for an audit or a customer, you are sending the process to someone outside your tools, or you want a printable checklist for a workstation.

It is a poor home for a living process, for two reasons. Every copy goes out of date the day the process changes, and nobody can search across fifty loose files. A sound approach:

1. Write and maintain the document in one shared, searchable place.
2. Export to PDF when you need a snapshot, and put the version number and date in the footer.
3. Store snapshots in a clearly marked archive so nobody mistakes one for the current version.
4. For a blank template, keep a one-page PDF or Word file with the ten fields so teams can start from the same structure.

If you build your template in a word processor, use heading styles and tables rather than manual spacing. They export cleanly and stay readable on a phone.

Our perspective

We built Kept because we kept watching the same failure. A company documents a process, files it, and six months later the person who knew how it really worked leaves. The document says what to do. It does not say what the person would have done when the form was incomplete, the client was a long-standing exception, or the rule contradicted common sense.

Templates are not the problem. A template with a decisions and exceptions field is a good template. The problem is that writing is the wrong way to capture judgment. Experts are rarely good at describing their own expertise from a blank page, because the most important things feel obvious to them. A good interviewer asks "what happened last time?" and "when would you not do that?" and the answers appear.

That's the idea behind guided, conversational capture: let people explain the work in their own words, ask the follow-up questions a sharp colleague would, and structure the result afterward. The structure should serve the knowledge, not the other way round.

Whatever tool you use, test your documentation with one question: if our best person were gone tomorrow, could someone competent make the same call? If not, the template is missing a field.

— Anthony

Capture the reasoning, not just the steps

If you would rather talk through a process than fill in ten fields, Kept for Business guides employees through an interview, structures what they say into a process document, and keeps workspaces opt-in, with clear control over review and deletion. Individuals can use it for their own work too. You can see the options on the pricing page, and teams focused on new hires can look at the onboarding use case.

FAQ

How do you write a process document?

Start with one process and a named owner. Have the person who does the work walk through a real recent case, list the steps with verbs first, then ask about every decision point and exception. Test the draft on someone who has never done the task, and publish it with a review date.

What should a process documentation template include?

At minimum: title and ID, purpose, owner, scope, trigger, roles, inputs, steps, decisions and exceptions, outputs, tools, and a revision record. Formal guides such as UNNE's administrative procedure guide also require identification codes and authorization signatures, which help when a process needs approval.

What is the difference between a process and a procedure?

A process describes what has to happen and which roles take part. A procedure describes how one person carries out a task, usually within one role. Carnegie Mellon's SEI draws the same line, and keeping the two documents separate makes both easier to maintain.

Is a PDF a good format for process documentation?

It works for snapshots, audits, and printed checklists. It is a poor format for the working version, because copies go stale and can't be searched together. Maintain the live document in a searchable tool and export PDFs with a version and date.

Sources

• Software engineering process and procedure definitions, Carnegie Mellon Software Engineering Institute (2007)
• Guide to administrative procedures, Universidad Nacional del Nordeste (2023)

Recommended

• Managers: Process Documentation Examples That Capture Exceptions
• Managers: Seven Steps to Process Documentation That Keeps Decisions
• Managers: 4 Things That Make Process Change Documentation Audit-Ready
• Map First: How Confusing Process and Procedure Breaks Automation