In short
A template converts a decision you have already made into one you never make again. Build them for anything produced more than monthly, starting from your best recent example rather than from a blank page, and strip out what was specific to that instance. The two failure modes are templates nobody can find, which is a filing problem, and templates that are wrong often enough to be distrusted, which is a maintenance problem. Both are solved by giving each template an owner and a location, not by making better templates.
Key takeaways
- Blank-page cost is real and uncounted: the time, plus re-deciding things you already decided.
- Build from your best recent example, not from first principles.
- Mark clearly what must change each time, or people will send the last client's name.
- A template nobody can find does not exist. Put it where the work starts.
- One wrong template teaches people to distrust the whole library. Assign owners.
The cost of starting from nothing
Ask someone how long it takes to write a proposal and they will tell you about the writing. The writing is the smaller half. The larger half is the deciding: what order the sections go in, how much detail the pricing needs, whether the case studies go before or after the approach, what to say about timelines when the client has not confirmed a start date.
Those decisions were made last time, and the time before that, and they are made again because nothing recorded them. That is the real cost of a blank page: not the typing, but the re-litigation of settled questions by someone under time pressure who will settle them slightly differently.
There is a second cost, which is variance. Ten proposals written from scratch are ten different documents of ten different qualities, and the worst of them went to a client. Consistency is not the reason to build templates, but it is a reliable side effect.
A template is a decision you already made, saved. The saving is not the typing time; it is not having to make the decision again while tired.
What is worth templating
The threshold is lower than most people assume. Anything produced more than about monthly, with a recognisable shape, is a candidate.
| Strong candidates | Why |
|---|---|
| Proposals and statements of work | High stakes, high frequency, and the structure is settled |
| Project briefs | Incomplete briefs are the largest single cause of rework |
| Client reports and updates | Repeated monthly, and consistency is itself valued by clients |
| Recurring emails: onboarding, chasing, handover | Written from scratch dozens of times a year, each slightly worse than the last |
| Checklists for anything with a sequence | Cheapest possible template, and often the highest return |
The brief template is the one that returns fastest, because it operates upstream. A brief that cannot be submitted without the three things the work always needs prevents the rework described in rework: why your team keeps doing things twice, and it does so at the only point where prevention is cheap.
What is not worth templating: anything genuinely different each time, and anything where the structure is currently in dispute. Templating an unsettled process just freezes an argument.
Build from your best example
The wrong way to build a template is to design one. The right way is to find the best real example you have and strip it back.
- Pick the best recent instance. The proposal that won, the report the client praised, the brief that produced work needing no revisions.
- Remove what was specific to it, leaving the structure, the section headings and the sentences that would be true every time.
- Keep the good phrasing. The paragraph that explains your approach well is an asset. Rewriting it generically makes it worse.
- Add a note at the top saying when this template does not apply. One line. It prevents the failure where a template is used for work it does not fit.
Good real example beats any amount of template design. It has already been tested against a client, which is a standard no invented structure can meet.
Make the variable parts obvious
The characteristic template failure is sending a document with the previous client's name in it. It is embarrassing out of proportion to its size, and it is entirely preventable by design rather than by care.
- Mark every variable field distinctively. Square brackets, a highlight colour, capitals. Anything that is visually impossible to skim past.
- Never leave real data in a template. A real client name in the placeholder position will eventually be sent. Use an obviously fake one.
- Separate must-change from may-change. Names and figures must change; the approach section usually does not. Distinguishing them tells the user where to concentrate.
- Put the instructions inside the template, in a form that is deleted as it is used, rather than in a separate document nobody opens.
The last one matters more than it sounds. Guidance held anywhere other than inside the artefact is guidance that gets skipped, for the same reason a procedure stored three folders away from the work does not get read.
Findability is most of the value
A template that takes ninety seconds to locate will lose to a blank page, every time, because the person is already working and the alternative is immediate. This is the single most common reason template libraries fail, and it has nothing to do with template quality.
Three placements, in order of effectiveness:
| Placement | Effect |
|---|---|
| Built into the tool where the work starts, as a native template | Best. Choosing the template is the act of starting |
| Linked from the process document or the project checklist | Good. Found at the moment of need |
| Stored in a templates folder on a shared drive | Weakest. Requires remembering it exists and where it lives |
If you are stuck with the third, at least apply a consistent naming pattern so search works, as described in where things live. A template that is findable by search from anywhere beats one that is filed perfectly and remembered by nobody.
Keeping them from going stale
Templates decay in a specific and damaging way. One goes out of date, someone sends it, a client sees old pricing or a defunct address, and the whole library loses credibility at once. After that, people build from scratch again, which is where you started.
Three practices prevent it, and none is heavy:
- One named owner per template, shown inside the file. Not a team.
- A review date, also inside the file, six months out. Unowned and undated templates are the ones that go wrong.
- Update on the trigger, not the calendar. New pricing, new branding, a new legal requirement: the change to the template is part of the change, not a follow-up task.
- Template debt
- The accumulated gap between what templates say and what is currently true. It is invisible while templates sit unused and becomes visible all at once, usually in front of a client, which is why it damages confidence in the whole library rather than in the individual file.
One further habit worth establishing: when someone improves a template while using it, they update the template rather than only their copy. Without that, every improvement is made repeatedly and none of them accumulates, which is the same pattern that keeps undocumented knowledge trapped in individual heads. The Mayim Ops assessment measures manual handling and repeated effort directly, and rebuilt-from-scratch work is one of the larger components in businesses that consider themselves reasonably organised.
Frequently asked questions
What should you create templates for?
Anything produced more than about once a month with a recognisable structure: proposals, briefs, reports, recurring emails, meeting agendas, checklists. Frequency multiplied by the effort of starting from scratch is what determines value, and the effort is usually underestimated.
How do you create a good business template?
Take your best recent example of the thing, remove what was specific to that instance, and mark clearly which parts must be changed each time. Building from a real example captures the decisions that worked; building from first principles produces a structure nobody has tested.
Why do people not use templates?
Usually because they cannot find them quickly, or because a previous template was out of date and produced an embarrassing error. Both are solved by location and ownership rather than by better templates, and until they are solved, adding more templates does not help.
How often should templates be reviewed?
Every six months, and immediately after anything that changes their content: new pricing, new branding, a new legal requirement. Assign each template one owner, because a template library with no owners degrades silently and is discovered only when a customer receives something wrong.
Can templates make work worse?
Yes, when they are applied to work that needs a fresh approach, or when placeholders are missed and the previous client's details are sent. The first is a judgement problem worth naming in the template itself; the second is prevented by making variable fields visually impossible to overlook.