The short version
- Any note a client gives twice is a rule nobody has written down yet.
- Write the rule as a prohibition with a target you can point at. A note like too salesy tells a writer nothing until it names which words are banned and where.
- Keep the rule file where the drafting happens. A guide a writer has to go looking for gets applied by whoever happens to remember it.
- Confirm the wording with the client before it goes in the file.
Codifying a client’s taste means turning the edits they keep making into written rules, then handing the mechanical ones to a script. One newsletter programme we run has nine standing editorial rules and a QA script. Eleven issues have gone out under that setup, numbers 20 to 30.
What does it mean to codify a client’s taste?
Record every note the client gives twice, in their own words, then rewrite each one as a rule that forbids something specific. Split the list by who can check it, a script or a person. The output is a file that lives with the copy, not a shared understanding held by whoever was on the call.
Classes of repeat note, and the form each has to take before anything can enforce it:
| Class of note | What it has to become | Where it lives | Who checks it |
|---|---|---|---|
| A banned character | The character itself, named, with a count of zero | Validator config | Script |
| The casing of a name | One approved form, everywhere it appears | Validator config | Script |
| A structural gap | A minimum count of the missing element | Validator config | Script |
| A sentence shape they dislike | A named list of shapes with an example of each | House style file | Script for the literal strings, person for the rest |
| Register | A rule about what the opening sentence may contain | Voice guide | Person |
| A claim they will not make | Nothing goes out that is not already published elsewhere | Fact bank | Person, fact-check pass |
| A byline mismatch | One voice file per named author, read before drafting | Author voice file | Person |
A note is not a rule until somebody has decided what it forbids and who is responsible for catching it.
Why does the same edit keep coming back?
Because feedback arrives as an instance and gets treated as an instance. The client says one paragraph is too salesy, the writer softens that paragraph, and the preference underneath it is never recorded anywhere. Next issue, different paragraph, same note.
How do you turn a note into a rule?
Ask what the note would forbid if it were a rule, then write the forbidding version. Too salesy is a mood and nobody can act on it. No benefit adjective in the subject line, open on the number, is something a writer can follow and a reviewer can check against the draft in front of them.
Then read the rule back in the next call and get the wording confirmed, so that what goes in the file is the client’s rule rather than an inference nobody checked.
Which rules can a script check?
The ones with a right answer. Characters, the casing of a name, banned strings, required elements, counts.
The gate on this journal hard-fails on the banned character, the rendered word count, the number of FAQ entries, a missing table and a missing internal link. Casing is not in it. That is a gap rather than a design decision.
Everything else needs a person. Whether the piece has a point, and whether the voice matches the byline it is going out under. A script cannot tell you a paragraph is empty.
Nine standing editorial rules and a QA script, across eleven issues, numbers 20 to 30.
What happens when the client changes their mind?
Change the file in the same meeting and say out loud which rule moved. Written rules make a reversal visible and dated. Preferences held in somebody’s head reverse quietly, then get enforced retrospectively against work that followed the old version.
It also settles who decides. The rules belong to the client and the enforcement belongs to us. A client who overrules their own rule is exercising ownership, and our job in that moment is to edit the file rather than defend the old version.
The rest of the system around a rule set is putting the standard in the brief and the gate that enforces the mechanical half.
Frequently asked questions
What does it mean to codify a client's brand voice?
Turning the edits a client repeats into written rules, stored where the team writes, and automating the ones a script can check. The test is whether a new writer could produce an approvable draft from the file alone, without having sat in any of the review calls.
How do you stop a client giving the same feedback every round?
Write the note down as a rule the second time it appears, phrased as a prohibition with a specific target, then confirm the wording with the client. Repeat feedback is the symptom of a preference nobody recorded, not of a careless writer.
Which editorial rules can be automated and which cannot?
Automate anything with a right answer: banned characters, the casing of a name, banned phrases, required sections, minimum counts. Leave judgment to a person, including whether the piece has a point at all and whether the voice matches the byline it is going out under.
How many rules should a client style guide have?
As many as the client has actually repeated, and no more. One newsletter programme we run holds nine standing rules plus a QA script, and eleven issues have gone out under that setup.
Who owns the style rules, the agency or the client?
The client owns the rules and the agency owns the enforcement. That split keeps the argument off the table. A client who overrules their own rule is exercising ownership, and the agency's job at that point is to edit the file rather than defend the old version.
What should happen when a client reverses a rule?
Edit the file in the same meeting and name the rule that changed. Written rules make a reversal visible and dated, which protects work produced under the previous version from being judged against the new one.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
