How to Document a Process: A Step-by-Step Guide That Doesn't Suck

Most process documentation is terrible.

You know the kind: walls of text, outdated screenshots, vague instructions like "work with the team to finalize," zero indication of why anything happens the way it does.

Nobody reads it. Nobody updates it. It sits in a folder somewhere gathering digital dust until someone deletes it during a cleanup.

The problem isn't that process documentation is inherently boring. The problem is most people are writing it wrong.

They're documenting what to do, not how to do it. They're writing for themselves, not for the person who comes next. They're creating reference material when what's needed is a guide.

Here's how to document a process in a way that people will actually use.

Before You Start: When to Document a Process

Not everything needs documentation. Don't waste time documenting one-off tasks or things that change constantly.

Document a process when:

It repeats. Monthly close, employee onboarding, customer setup, quarterly planning. If it happens more than twice, document it.

Multiple people need to do it. If only you do something and you always will, keep it in your head. But if anyone else might ever need to do it—document it.

It's high-stakes. Compliance reporting, security protocols, financial controls. Things where mistakes are costly.

Knowledge is at risk. If only one person knows how to do it and they might leave, get promoted, or move to a different role—document it.

You're explaining it repeatedly. If you've answered the same "how do I...?" question three times, stop answering and document it.

Don't document for the sake of documentation. Document when it actually prevents problems.

Step 1: Figure Out Who This Is For

The biggest mistake: writing documentation for nobody in particular.

You need a specific reader in mind. Who will actually use this?

• The new hire who's never done this before?
• The occasional user who does it once a quarter and forgets in between?
• The backup person who needs to cover when the primary person is out?
• The auditor who needs to verify the process is compliant?

Each of these needs different documentation.

The new hire needs detailed step-by-step with explanations. The occasional user needs a quick refresher with clear steps. The backup person needs to know where to find things and who to ask for help. The auditor needs to see controls and approval workflows.

Pick your primary audience. Write for them.

(You can have secondary audiences, but optimize for one.)

Step 2: Watch Someone Do It (Don't Just Write From Memory)

Here's the thing: you don't remember your own process as accurately as you think.

You've internalized shortcuts. You skip steps that are "obvious" (to you). You have context that helps you navigate ambiguity without thinking about it.

If you document from memory, you'll leave stuff out.

Instead, actually watch someone do the process. Ideally someone who's relatively new to it, so they're still following the steps consciously.

Take notes:

• What they do first, second, third
• Where they hesitate or get confused
• What they have to look up
• Questions they ask
• Tools they switch between
• Decisions they make

Better yet: record it. Video if it's a screen-based process, audio if it's in-person work. Then transcribe and extract the steps.

This is exactly what Understudy does—record someone doing the work, and it generates documentation automatically. Way faster than writing from scratch.

Step 3: Structure It Like a Recipe

Good process documentation is structured like a recipe.

Title: What this process accomplishes Context: When and why you do it Prerequisites: What you need before starting Steps: Numbered, sequential, specific Outcome: What success looks like Troubleshooting: Common problems and fixes

Let's break that down.

Title

Be specific. Not "Monthly Reporting" but "How to Generate and Submit the Monthly Financial Report to the Board."

The title should tell someone exactly what outcome they'll achieve by following this.

Context

Why does this process exist? When do you do it?

"We generate this report by the 5th of each month to keep the board informed of financial performance. It's required by our bylaws and used for strategic planning."

This helps people understand priority and importance. It also helps them know when to use this documentation vs. something else.

Prerequisites

What do you need before you start?

• Access to specific systems
• Data from other departments
• Approvals or sign-offs
• Tools or templates

List them. If someone's missing a prerequisite, they can go get it before wasting time starting the process.

Example:

• Access to the accounting system (request from IT)
• Prior month's expense reports (from Finance)
• Board report template (in shared drive: /Templates/Board)

Steps

This is the core. Numbered steps, in order, specific enough that someone could follow them without asking questions.

Bad:

1. Pull the data
2. Create the report
3. Send it to the board

Good:

1. Log into QuickBooks (credentials in password manager under "Finance-QuickBooks")
2. Navigate to Reports → Custom Reports → Board Financial Summary
3. Set date range to prior month (e.g., if today is March 5, select Feb 1 - Feb 28)
4. Click "Export" → choose Excel format → save to /Reports/Board/YYYY-MM/
5. Open the Board Report Template (Google Sheets: Board Reports → Template)
6. Click "Make a copy" → rename as "Board Report YYYY-MM"
7. Go to the "Financial Data" tab → delete existing sample data
8. Open the QuickBooks export → copy columns A-F → paste into the template starting at cell A2
9. Check that formulas in columns G-J auto-calculate (you should see percentages, not errors)
10. Review the "Summary" tab → verify totals match QuickBooks export
11. Add narrative context in the "Notes" section (explain any unusual variances over 10%)
12. Share the report with the ED for review (File → Share → add ED email with "Can edit" permissions)
13. Wait for ED approval (usually within 24 hours)
14. Once approved, export as PDF (File → Download → PDF)
15. Email to board-members@company.com with subject line "Board Report - [Month] [Year]"
16. CC the ED and move the Google Sheet to /Reports/Board/YYYY-MM/Archived

See the difference?

The good version assumes zero prior knowledge. It includes specific paths, file names, what to do if something's wrong, who to ask for approvals.

Outcome

What should the result look like?

"The board receives a PDF report by email by the 5th of the month. The ED confirms receipt. The Google Sheet is archived in the proper folder."

This lets someone verify they did it right.

Troubleshooting

What goes wrong, and how do you fix it?

Problem: QuickBooks export shows $0 for all categories Fix: You probably have the wrong date range selected. Double-check the start and end dates match the prior month.

Problem: Template formulas show #REF! errors Fix: You pasted over the header row. Undo, make sure you're pasting starting at cell A2, not A1.

Problem: ED hasn't approved within 24 hours Fix: Slack them directly. If still no response, email and CC the CFO.

This is the stuff people actually need but never gets documented.

Step 4: Add Visuals (But Not Too Many)

Screenshots help. But not everywhere.

Add visuals for:

• Navigation (where to click, which menu to use)
• What success looks like (the correct output)
• Error states (what to do if you see this)

Don't add screenshots for:

• Every single step (they'll get outdated fast)
• Things that are self-explanatory ("click the Save button")
• Text-heavy screens (just describe what to look for)

Annotate your screenshots. Circle or arrow the relevant part. Add text labels. Don't make people guess what they're looking at.

And here's the thing about screenshots: they go out of date. UI changes, and your screenshots don't match anymore.

So use them strategically. And consider alternatives:

• Screen recordings (show the full workflow)
• Diagrams (for process flows)
• Gifs (for short interactions)

Step 5: Include Decision Points

Most processes aren't perfectly linear. There are decision points.

"If X, do Y. If Z, do A instead."

Make these explicit.

Example:

Step 8: Check if the invoice is over $5,000

• If yes: Get approval from the Finance Director (email approval required before proceeding to Step 9)
• If no: Proceed directly to Step 9

Don't hide decision logic in paragraph form. Make it visually obvious. Use bold, bullets, indentation.

Step 6: Explain the Why (When It Matters)

Most process docs just list steps. The good ones explain why.

Not for every step—that's overkill. But for steps that seem unnecessary, bureaucratic, or confusing, explain the reason.

Example:

Step 12: Forward the approval email to compliance@company.com

Why: This creates an audit trail for SOC2 compliance. Auditors check this inbox quarterly.

Understanding why helps people in two ways:

1. They remember the step (context aids memory)
2. They know when they can skip it (if circumstances change)

If you don't explain why, people assume it's bureaucratic BS and skip it.

Step 7: Test It on Someone New

You can't verify your documentation alone. You're too close to it.

Hand it to someone who's never done the process before. Watch them try to follow it.

Don't help them. Don't explain. Just watch.

Where do they get stuck? What do they have to ask about? What do they interpret differently than you intended?

Those are the gaps.

Fix them. Then test again.

The best process documentation works for someone with zero context. That's the standard.

Step 8: Make It Easy to Update

Process documentation goes stale. Systems change. Workflows evolve. People discover better ways.

If your documentation lives in a PDF or a locked-down wiki, it won't get updated.

You need:

• Easy editing: One-click to suggest changes
• Version history: See what changed and when
• Ownership: Someone responsible for keeping it current
• Review reminders: "This hasn't been updated in 6 months—still accurate?"

The easier it is to update, the more likely it stays current.

Step 9: Link to Related Processes

No process exists in isolation.

Your "Monthly Board Report" process probably connects to:

• How to access QuickBooks
• How to request system access from IT
• How to share Google Sheets with external users
• What to do if the ED is out of office

Link to those. Don't re-document them.

Good documentation is a web, not a silo.

Common Mistakes (And How to Avoid Them)

Mistake #1: Writing for yourself, not the reader

You know the context. They don't. Assume zero knowledge.

Mistake #2: Using vague language

"Work with the team" means nothing. Who specifically? How? What's the output?

Be specific: "Email marketing@company.com with the draft. Wait for Sarah's approval (usually 24 hours). If no response, Slack her directly."

Mistake #3: Documenting edge cases as primary flow

Don't start with "If the customer is an enterprise client in the EU..." when 95% of customers are SMBs in the US.

Document the common path first. Edge cases go in a separate section.

Mistake #4: No indication of time/effort

How long does this process take? Helps people plan.

"Time: 30-45 minutes. Best done when the office is quiet (fewer interruptions)."

Mistake #5: Forgetting to explain who does what

If a process involves multiple people, make that clear.

"Step 5: [Finance team] reviews the data for accuracy Step 6: [You] wait for their approval (typically 1 business day) Step 7: [You] upload the approved file..."

Use role labels, not names (names change, roles persist).

Mistake #6: No troubleshooting

Stuff goes wrong. If you don't document it, people get stuck.

Capture common errors, weird edge cases, and what to do.

Mistake #7: Burying important info in paragraphs

Use formatting. Bold, bullets, headings, whitespace.

Make important stuff visually obvious. Nobody reads walls of text.

Real Example: Documenting a Sales Process

Let's see what this looks like in practice.

Bad documentation:

"Sales Process: Qualify the lead, demo the product, send proposal, negotiate, close. Follow up regularly."

Good documentation:

How to Move a Lead from Demo to Close

When to use this: After a demo call where the prospect confirmed interest and fit

Who this is for: Account Executives

Prerequisites:

• Completed demo (recorded in HubSpot)
• Prospect confirmed budget and timeline
• Technical requirements documented (use the Discovery Checklist)

Time required: 2-3 weeks from demo to close (typical), 30 min of work per deal

Steps

1. Log demo outcome in HubSpot

• Open the contact record → Activity tab → "Log Activity" → "Demo Completed"
• Note which features they cared most about
• Note any concerns or objections
• Set deal stage to "Demo Complete"

2. Send proposal within 24 hours

• Use the proposal template: Templates → Sales → Standard Proposal
• Customize the "Use Case" section to match their specific needs (copy from demo notes)
• Pricing: If under 50 users, use self-serve pricing. If over 50, ping Sales Ops for custom quote.
• Send via DocuSign (not email attachment)
• CC your manager on deals over $25K

3. Follow up if no response within 3 business days

• Send the "Proposal Follow-Up" email template
• If still no response after 2 more days, call directly (don't just email)

4. Handle objections

• Price too high: Offer quarterly payment option (use "Payment Plan" contract template)
• Need more features: Loop in Product team (Slack #sales-product-questions)
• Need security review: Send SOC2 report (in Drive: Sales/Security Docs)

5. Negotiate terms

• You can discount up to 15% without approval
• Discounts over 15%: Get VP Sales approval via Slack (usually responds within 2 hours)
• Contract terms: Legal can turn around edits in 1 business day if you flag urgent

6. Close

• Once DocuSign is fully executed, mark deal as "Closed Won" in HubSpot
• Forward executed contract to contracts@company.com (required for finance)
• Introduce customer to onboarding team via email (use "Customer Handoff" template)
• Update deal notes with any special agreements or context

7. Log it

• Add win to #sales-wins in Slack (team celebrates, plus visibility)
• If you learned something useful during the process, add it to Sales Playbook

What success looks like

• Deal marked "Closed Won" in HubSpot
• Contract sent to finance
• Customer introduced to onboarding
• First invoice sent within 5 business days

Common issues

Problem: Prospect goes dark after proposal Fix: Call, don't just email. Often there's an internal blocker they haven't mentioned.

Problem: Legal review takes forever Fix: Ask prospect if they can prioritize. If not, check in weekly. Most legal teams move faster with regular nudges.

Problem: Pricing doesn't match their budget Fix: Don't immediately discount. First explore if they can reduce scope (fewer users, fewer features). Discounting should be last resort.

Questions? Slack #sales-help or ask your manager

See how much more useful that is?

It's specific. It includes context. It anticipates problems. Someone who's never closed a deal could follow this and probably succeed.

The Maintenance Part Nobody Talks About

Documentation isn't a one-time task. It's ongoing.

When to update:

• The process changes (obviously)
• Someone discovers a better way
• A step is consistently confusing (people keep asking about it)
• Tools or systems change
• Every 6 months, even if nothing changed (verify it's still accurate)

Who should update:

• The person who owns the process (primary)
• Anyone who uses it regularly (suggested edits)
• New hires (they find gaps immediately)

Make updating easy. If it requires submitting a ticket or getting approval, it won't happen.

Better: let anyone edit directly, with version history so you can roll back if needed.

Tools: What to Use

You don't need fancy software. But you do need something better than Word docs or PDFs.

Minimum requirements:

• Easy to search
• Easy to edit
• Version history
• Accessible to everyone who needs it

Options:

Internal wiki (Notion, Confluence, etc.)

• Pros: Familiar, flexible
• Cons: Quickly becomes a dumping ground, hard to keep organized

Knowledge base (Understudy, Guru, etc.)

• Pros: Built for process docs, easy to update, AI can help capture knowledge
• Cons: Another tool to adopt

Google Docs/Sheets

• Pros: Everyone has access, commenting works
• Cons: No structure, hard to find things as you scale

GitHub/internal docs

• Pros: Version control, great for technical teams
• Cons: Not accessible to non-technical folks

Pick based on your team. The best tool is the one people will actually use.

The ROI of Good Process Documentation

Let's be honest: documenting processes takes time.

Is it worth it?

If you're training someone new:

• Without docs: 4-8 hours of your time explaining + their trial-and-error
• With docs: 30 min of your time answering questions + they self-serve the rest

If someone's covering for you:

• Without docs: They text you constantly while you're on vacation
• With docs: They handle it, you actually disconnect

If knowledge walks out the door:

• Without docs: Next person spends 3-6 months rediscovering what the last person knew
• With docs: Next person is productive in weeks

If you're scaling:

• Without docs: You have to personally train every new person (doesn't scale)
• With docs: Training scales without you

Time invested: Maybe 2-4 hours to document a complex process well.

Time saved: Hundreds of hours over the life of the documentation.

It's not even close.

Just Start

The hardest part is starting.

You don't need to document everything. Pick one process. The one that:

• Happens frequently
• Is often taught to new people
• Is currently in someone's head and shouldn't be

Document that. See if it helps. Iterate based on feedback.

Then do the next one.

Within a few months, you'll have a library of actually useful process documentation that saves time and prevents knowledge loss.

The work you do today makes everyone's job easier tomorrow.

Make process documentation actually useful. Understudy helps teams capture processes while people are doing the work—no more writing from scratch. See how it works or check out pricing.