The Practice Voice & Templates

Every practice has a voice, whether it has ever written it down or not - a level of formality, a way of opening and closing, a set of words it uses and a set it would never touch, a stance that is warmer or drier than the average. Clients feel it even when they could not name it, and it is part of what makes a practice recognisable. The problem with using Claude across a studio is that the model actively erodes that voice unless you actively defend it.

Here is the mechanism. Claude produces the most plausible text for a request, and in the absence of your specifics, the most plausible business writing is the average of all business writing - smooth, competent, and completely anonymous. Ask three people in your office to draft a client email with Claude and you will get three different tones, none of them quite yours, all of them drifting toward that bland centre. Relying on each person to fix this by hand, every time, is relying on willpower and taste that varies by who is at the keyboard and how rushed they are. It does not scale, and it fails exactly when you are busiest.

The alternative is to make the voice a shared asset the tool carries for you. Instead of each person describing the tone from memory in each chat, you document the voice once and load it where every draft can inherit it. The figure shows the shape: project knowledge (your sample letters, a short style note, approved boilerplate) plus custom instructions (who you are, your register, your rules) combine inside a Project so that every chat starts already sounding like the practice - and the person at the keyboard spends their effort on the specifics, not on re-deriving the tone.

A practice voice you can hand to Claude is not a mood or a memory - it is a short, concrete document. The good news is it takes an afternoon to write and pays back for years. Aim for one page, and make it specific enough that a stranger could match your tone from it.

Cover a few things. Register: where you sit on the warm-to-formal dial, and how that shifts for different readers (a long-standing client versus a statutory authority). Openings and sign-offs: how you actually begin and end letters and emails - Claude gets these wrong constantly, and fixing them removes half the not-quite-you feeling. Words you use and words you ban: your own vocabulary, and a blacklist of the AI and corporate tells you never want to see - delighted to have the opportunity, in today's fast-paced world, we pride ourselves, the piled-up adjectives. Stance: are you plain-spoken or elaborate, do you hedge or commit, how do you handle bad news. And the single most powerful ingredient: real examples. Two or three of your best past letters and emails, de-identified, teach Claude more than any description, because it matches a concrete sample far better than an abstract instruction.

A compact custom-instruction block might read:

You are drafting for [Practice], a [size/kind] design practice.
Voice: warm but concise; we commit rather than hedge; plain
English, short sentences. Open with the person's name, no throat-
clearing. Sign off "With regards". NEVER use: "delighted",
"reach out", "fast-paced", stacked adjectives, exclamation marks.
Match the sample letters in project knowledge. Keep client emails
under 150 words unless asked. When a figure, date or commitment
is needed and not supplied, insert [TO CONFIRM] - never invent it.

Notice that the never-invent rule from Lesson 5.1 lives here too: the voice document is also where your safety rules become standing policy, applied to every draft automatically instead of remembered case by case. That is the quiet power of writing it down - a rule you keep in your head protects only the drafts you happen to be thinking carefully about, while a rule loaded into the Project protects every draft, including the one dashed off at the end of a long day when your guard is lowest. Encoding your standards is how you stay careful even when you are tired.

The second half of the system is templates - reusable shells for the things you write on repeat. The library from the figure is a good starting set: a proposal and fee-letter shell, a client-update email, a minutes format, a stage-report structure, a presentation-deck arc, a site-visit note. Each one bakes in the structure and voice you settled in the earlier lessons, so a new job starts from your best version rather than a blank page or a random Claude draft.

The discipline that makes templates safe is a single rule: a template is a shape plus rules, never real specifics. It holds the structure, the standard exclusions, the section headings, the tone - and marked slots where the real content goes, written as [CLIENT NAME], [FEE - CONFIRM], [DATE]. It never holds a real fee, a real client's terms, or last project's numbers, because a template that carries stale specifics is how the wrong figure or a previous client's confidential detail ends up in a new document. When you use a template, you consciously fill every slot for this job - and the bracketed markers make an unfilled slot impossible to miss.

Hold the templates as project knowledge, and they become shared studio property: everyone drafts from the same proposal shell, the same report structure, the same update format, and the output converges instead of scattering. Keep them lightly maintained, too - when you find a better exclusions paragraph or a cleaner report order, update the template so the whole practice inherits the improvement. This is the seed of the studio knowledge base that Module 9 builds out fully; here, the point is simply that templates plus a documented voice turn Claude from a clever individual tool into something that makes the whole practice sound like one considered hand.

Start small and let the library earn its size. One genuinely good template - the document you write most, built once and used well - beats six half-finished shells nobody trusts. Add the next only when a real repeated need appears, and retire any that stops matching how you actually work.

A voice document and a template library are not set-and-forget, and they do not remove you from the loop - they make the loop faster and more consistent, which is the whole point. Three habits keep the system honest.

Read every draft still. A consistent voice and a good template raise the floor of quality dramatically, but they do not make output correct. Every safeguard in this module still applies on top of the system: the numbers are still yours to verify, the minutes still have to match the room, the commitments are still yours to own. The system means you are checking a draft that already sounds like you and already follows your rules - a far quicker read - not that you are checking nothing.

Keep it current. Voices evolve, boilerplate gets superseded, better phrasings emerge. Set a light habit - a review every few months, or whenever something reads stale - to refresh the voice note and the templates so the practice keeps improving rather than fossilising around an old version of itself.

Mind the confidentiality line. The moment you are loading real past letters, client terms and practice standards into a Project, you are handling client-adjacent material, so this is where you check your plan's data settings and keep genuinely confidential specifics out of shared knowledge - the subject of Module 10.1. De-identify your example letters; keep templates free of real client data.

Get those habits right and you have built something quietly valuable: a practice where quality writing is the default, not a personal heroic act; where the newest joiner sends work that sounds like the studio on day one; and where the hours this whole module saves compound, because the system does not have to be rebuilt for every job. That is the difference between using Claude and running a Claude-augmented practice - and it is exactly where Module 9 picks up. The tool will keep changing; models come and go, buttons move. A documented voice and a disciplined set of templates are the parts that stay yours through all of it, because they encode not the software but the studio.