Operating Manual
A lightweight business system for writing down how a small business actually runs, so that routine work does not depend on one person's memory.
Self-initiated example — not a client engagement.
Case 01 / 04
A lightweight business system for writing down how a small business actually runs, so that routine work does not depend on one person's memory.
Self-initiated example — not a client engagement.

The artifact
Operating knowledge becomes useful when the trigger, decision, owner, source and review cadence are explicit.
Every entry starts from a real, recurring moment the business already has — never an abstract category invented for the document.
Next to it, the decision or action someone actually takes — written as an instruction, not a policy summary.
Tied to a role, not a named person, so the entry still holds when someone is away or moves on.
One named place the current answer lives, so two people are never working from two versions.
Fixed on a schedule, so the record stays current because it keeps being checked — not because someone remembers to.
BeforeThe answer lives in one person’s memory.
AfterThe answer lives in a written entry anyone can find.
BeforeRoutine work stalls the moment that person is away.
AfterRoutine work continues because the record, not the person, is the reference.
BeforeA disagreement gets argued from memory.
AfterA disagreement gets resolved by editing the entry, not re-litigating it.
Most small businesses do not lack documentation because no one has time to write it. They lack documentation because the obvious format — a policy binder, a wiki, an onboarding deck — is the wrong shape for how the knowledge actually gets used. It gets written once during a busy week, drifts out of date within a quarter, and is quietly abandoned the first time it disagrees with how things are really done. The starting question for this piece was narrower than “write down what we do”: what is the smallest written record that stays current because people keep using it, not alongside the work they are already doing but as part of it.
The approach treats the manual as a by-product of a few recurring conversations, not a writing project on its own: which decisions get made every week and by whom, which tasks stall when one person is away, and what record would make each repeatable by someone else. Each answer becomes one entry, tied to a specific decision or task rather than an org chart, so the document grows in the order the business actually needs it to.
