Write SOPs and documentation that actually run the business

For a one-person agency, the documentation is the product. Clients buy results, but what lets me deliver a result the same way every time, hand part of the work to a contractor, or turn it into an automation is the written procedure behind it. A process that lives only in my head can be done by one person, from memory, on a good day. This page covers what I document, the shape each kind of document takes, and the habits that keep documents true after the work changes.

Treat documentation as what makes work repeatable

Every recurring job in a small agency, from onboarding a client to checking a server, runs either from memory or from a document. Memory is fast until you are tired, busy, or away, and it cannot be handed to anyone. A document can be followed by you on a hectic Friday, by a contractor you bring in for a week, or by a script.

Documentation is also the only road to automation. You cannot automate a procedure nobody has written down, because nobody has decided what the steps are. Write it, run it by hand a few times, fix the steps that turned out wrong, and then automate it.

Keep a clear line between the two. An SOP says how the business runs a procedure, whoever or whatever does it. A script or tool is how a machine executes part of it. When a tool already covers the mechanics, the SOP names the tool and links to it instead of copying its steps, so there is only one place to update.

Write an SOP for anything you do more than twice

The first time, you figure it out. The second time, you notice you are figuring it out again. The third time, write it down. Also write one right after a procedure fails in a way that costs money or trust, while the details are fresh.

These are the procedures that earn an SOP first in a small agency, and the failure each one prevents:

Give every SOP the same parts

Keep each SOP to one page, and give every one the same shape so you always know where to look.

SOP-005: Monthly billing check

Owner:    Me
Trigger:  The first business day of each month
Links:    Client list, invoicing tool, pricing sheet

Purpose
One or two sentences on the outcome this procedure guarantees.

Steps
1. Invoice every active client from the client list, not from memory.
2. Confirm every active client has a written rate.
3. Reconcile invoiced revenue with the revenue in my records.
4. Log a one-line profit and loss for the month.

Done when
Every invoice is sent, the numbers agree, and this month's line is logged.

Failure mode
A client who had left was still counted as revenue for months.
Rule: the ledger is the source of truth, and everything else is
corrected to match it every month.

Log every server and process change in six parts

SOPs cover recurring procedures. Changes to systems need a different document: a running change log with one entry per change, written the day the change is made. The change is not finished until its entry exists. Every entry has the same six parts:

## Noindex every staging subdomain
Added: 2026-04-14

Why it matters
Staging sites and internal tools should never appear in search results.

What was configured
A snippet file, snippets/noindex.conf, containing one line:
  add_header X-Robots-Tag "noindex, nofollow" always;
Each staging site's server block includes it:
  include snippets/noindex.conf;
The always flag sends the header on error responses too.

How to repeat it
Add the include line to the new subdomain's server block, then run
nginx -t and reload nginx.

How to verify it works
Run curl -I against the subdomain and confirm the response includes
X-Robots-Tag: noindex, nofollow.

How to undo it
Remove the include line, test, and reload. Search engines can index
the subdomain again after they recrawl it.

Keep one master index of every document

A document nobody can find does not exist in practice, and two documents that disagree are worse than none. Keep a single index with one row per document: the title, what it is for, where it lives, and its status.

Four rules keep the index honest:

• Every new document gets its row the day it is created. An unregistered document effectively does not exist.
• Whoever changes a document, or the fact it describes, updates its row in the same sitting.
• When two documents disagree, the conflict is listed in the index with the version to follow until it is resolved.
• A superseded copy becomes a short pointer to the current version instead of a competing duplicate.

Add a short reading order at the top: the handful of documents to read first. It makes the index useful to anyone new, whether that is a contractor on day one or an AI assistant starting a fresh session.

Give every client the same folder structure

Every client and prospect gets one folder with the same subfolders, so each document has one obvious home and a new engagement starts from a template instead of an empty directory.

clients/
  example-roofing/
    00-brief/     agreement, business profile, brand rules, account IDs
    10-audits/
    20-site/
    30-reports/
    40-data/
prospects/        same layout; the folder moves to clients/ on signing
archive/
  clients/        where a client folder goes when the engagement ends
inbox/            unsorted material, cleared weekly

Deliverables never sit loose at the top level. Agency business, internal tools, infrastructure notes, and reusable templates each get their own top-level home, apart from client work.

Put documents and site files under version control, with an off-site copy

Documents and code need different kinds of backup.

• Documents such as audits, reports, briefs, and SOPs can live in a synced folder, as long as a second copy exists somewhere else, such as external storage.
• Code and site files belong in version control, one private repository per client site. Every change is recorded and reversible, each repository's history is that client's changelog, and handing a site over means handing over one repository.

Write commit messages that say why, not what. "Tighten hero copy per client email" tells a future reader more than "update index.html," and at month end the commit log is raw material for the client report. Turn on two-factor authentication for any account that can push to client sites, and keep repositories private by default. When a client leaves, archive their repository read-only, or transfer it if they own the code.

A backup is proven only once you have restored from it. Restore a file from each backup now and then, on purpose, before you need to.

Never put credentials in a document

Documents get synced, backed up, shared with contractors, pasted into chats, and committed to repositories. A password written into one spreads to every copy, and you can never be sure you found them all. Credentials live in a password manager or a server's environment file. Documents hold pointer notes that say where a secret lives, never what it is.

Hosting control panel:  password manager, item "Example Roofing / hosting"
Domain registrar:       client's own account, delegate access (see access log)
Form handler API key:   the server's environment file, not this repository

In repositories, list environment files in .gitignore from the first commit, and keep deploy secrets in the hosting or CI platform's secret store. If a secret does land in a commit, rotate it first and clean the history second. Rotation is the fix; rewriting history only tidies up.

Change the documents in the same sitting as the process

Documentation rots in the gap between changing how you work and updating the page that describes it. Close the gap by treating the document update as part of the change:

• Edit the source of truth first, then every copy, template, or generated checklist that repeats it. A copy says it is a copy and points back to the original.
• Update the index row at the same time.
• Put a last-reviewed date at the top of every document.
• Touch one drifted document during each weekly close, and re-check every status in the index once a quarter.
• Keep an improvement log: the date, what changed, why, and later, whether it worked.