document-template-system

Document Template System

A template is not a filled-out document with blanks - it is a decision made once so the team never makes it again. The costly failure is the over-built system: twenty templates nobody uses, each slightly stale, until authors quietly revert to copying last quarter's doc and the formatting drift returns. The best template systems are small, self-explanatory, and maintained by one named person.

Operating procedure

Audit before building, build before standardizing, standardize before naming - each step's output is the next step's input.

Step 1: Audit what the team actually produces

List the top 10 document types by frequency (count real docs from the last quarter; do not poll people on what they think they write). Build templates only for the top 5. Attempting to template everything produces a system nobody uses - every template below the frequency line is pure maintenance debt.

For each of the top 5 candidates, answer three questions before designing anything:

• Who authors this document, and how often?
• Who reads it, and what do they do with it? (A doc that drives a decision is structured differently from a doc that records one.)
• What varies between instances, and what should stay constant? The constant parts become required sections; the varying parts become variables.

If a candidate's answers are all "it depends," it is not one document type - split it or drop it.

Step 2: Build each template with the four-part anatomy

Every template contains exactly these four elements:

1. Purpose block - a single paragraph for the author's eyes stating what the template is for, when to use it, and what it is NOT for. This block is deleted before the document is sent.
2. Required sections - appear in every instance; label them REQUIRED.
3. Optional sections - relevant only sometimes; label them OPTIONAL - include if [condition] and remove the label when used. The condition must be decidable by the author alone ("include if budget exceeds $10k", not "include if relevant").
4. Variables - instance-specific placeholders written as [VARIABLE NAME IN CAPS] so they are visually distinct and findable with text search. A shipped document containing a raw [VARIABLE] is the system's most visible failure - capitalized bracketed variables make it nearly impossible to miss one.