How to Document Your Agency's Processes (So You're Not the Bottleneck)
You're the bottleneck because nobody knows how to do things except you.
New team member starts? You spend a week explaining processes.
Critical decision comes up? Someone asks you because the process isn't documented.
Documentation fixes this. But most documentation is boring and nobody reads it.
This post covers lightweight documentation that actually works.
Why Documentation Matters
Onboarding: New people become productive 30% faster with good documentation.
Consistency: When processes are documented, everyone does them the same way. Quality is consistent.
Scaling: You can't scale if every process lives in your head.
Continuity: If someone leaves, their knowledge doesn't leave with them.
Peace of mind: You can take vacation and the business runs.
The Documentation Problem
Most documentation is:
- Too long and detailed
- Written once and never updated
- Stored in a place nobody checks
- Written by someone not doing the work
So nobody reads it. And it falls out of date.
Good documentation is:
- Short and actionable
- Updated regularly
- Stored where people work
- Written by people doing the work
Lightweight Documentation Framework
Instead of massive process documents, use this framework:
1 - Process Overview (1 paragraph)
"The website redesign process takes 12 weeks. It includes discovery (2 weeks), design (4 weeks), development (4 weeks), and launch (2 weeks).
Multiple team members are involved. PM coordinates."
One paragraph. High level. Done.
2 - High-Level Flow (1 image or list)
Discovery → Strategy → Design → Development → Testing → Launch
Show the phases. Add key deliverables. That's it.
3 - Key Decision Points (list)
Where does sign-off happen?
- After discovery: client approves approach
- After design: client approves design direction
- After dev: QA approves functionality
- Before launch: PM approves go-live readiness
Short list. Clear authority.
4 - Responsible Party
Who does what?
"PM: Overall coordination, client communication Designer: Visual design, design assets Developer: Code, implementation QA: Testing, bug reporting"
Simple roles. No ambiguity.
5 - Tools and Templates
What tools are used? What templates exist?
"PM tool: Asana. Template: Website Redesign project.
Kickoff document: [link]. Feedback form: [link]."
Links to the actual templates. Make it easy to use them.
6 - Common Issues
What problems come up? How to solve them?
"Client feedback is vague → Ask clarifying questions in the feedback form. Design takes longer than estimated → Assess scope creep. Add revisions as change order."
Helps the team troubleshoot without asking you.
Storage and Structure
Store documentation where people work.
Option 1: Wiki (Notion, Confluence, GitBook). Everything in one place. Easy to search.
Option 2: Google Drive folder. Easy to share. Less structured.
Option 3: PM tool documentation. If your PM tool has docs, use it. One place to check.
Structure:
- Processes (organized by function: Design, Dev, Project Management)
- Templates (design templates, documents, checklists)
- Tools (which tools and how to use them)
- FAQ (common questions and answers)
Make it easy to find.
Getting Stuff Documented
You can't document everything at once. Start with:
- Your most common process. Website redesign, brand launch, whatever.
- Your bottleneck. What do people ask you about most?
- Your training needs. What do you explain to every new hire?
Document those. Then add others.
Who writes it? The person doing the work. The designer documents design process. The developer documents dev process. Not you.
How long should it be? 30 minutes of work to document a process. One-page overview. Short.
How to keep it updated? Add "update documentation" to the process. When the process changes, update the docs immediately. Don't wait.
Tools for Documentation
Notion: Flexible, visual, easy to use. Free tier works.
Confluence: More structured, great search, Atlassian integration. Paid.
GitBook: For technical docs. Clean design. Paid.
Google Drive: Simple, free, but less structured.
Wiki in your PM tool: Asana, Monday, etc. have built-in wikis. Convenience of everything in one tool.
Examples
Design Process Overview:
"Projects go through concept, design, and handoff phases. Designer creates 3 concepts, client picks one, we do 2 revision rounds, then handoff to dev.
Figma for all design work. Project template: [link]"
One paragraph. Deliverables clear. Tools referenced. Done.
Hiring Process Overview:
"Open roles are posted to LinkedIn, referral program, and job boards. Applications reviewed by PM. Phone screen with PM (30 min).
Portfolio/code review with team (1 week). Final interview with owner (1 hour).
Decision within 1 week. Offer negotiation and onboarding starts."
Clear steps. Clear timeline. Who's involved.
Frequently Asked Questions
What if the documentation is wrong? Update it. Documentation is always evolving as you learn better ways.
How do we get people to read the documentation? Link to it often. "See the onboarding guide." Make it part of onboarding. Make it part of PM project. If people need it, they'll read it.
What if people do things differently than the doc? Have the conversation. Either the process is wrong (update the doc) or they're off track (bring them back).
Should clients see documentation? Some parts yes (your process, timeline). Some parts no (internal tools, internal decisions). Be selective.
How much documentation is enough? Enough that someone could onboard without you. Enough that critical processes are clear. Start there.
What's the best platform for documentation? Whatever your team will actually use. If they live in Google Drive, use Google Drive. If they live in Asana, use Asana's wiki. Convention matters.
Documentation is unglamorous. But it's the difference between a flexible agency and one that can't grow beyond the owner.
Start documenting. Your team will thank you.