Writing Down What 'Finished' Means for Client Work
8 min read"Make it professional." "Keep it consistent." "Match my voice." "The usual length."
Every consultant has preferences like these, and they're real. But a subcontractor handed "make it professional" can only guess what you mean and hope. Claude does the same, faster and more confidently.
A preference becomes something you can hand over when someone other than you can tell whether the work meets it. There are three simple tests for that, and they're worth running on whatever you send clients most often.
Why preferences don't travel
A preference lives in your head, and it works fine while you're the one doing the work. It goes wrong when you hand the work to someone else, and it doesn't matter much whether that's a person or Claude.
Ask a subcontractor to "keep it tight" and you might get 800 words, because that was tight to them. Ask Claude the same and you'll get 800 words or 200, depending on what else was in the request. Neither is wrong, because you never said. Either way it lands on you at review, which is the most expensive point to fix it.
The usual fix is to add more adjectives: polished, client-ready, sharp. It doesn't work, because those words describe how you'd feel about the finished piece, not anything in it. You can only apply them once the work exists, and only if you already know what you wanted.
A standard describes the piece of work itself. That's the change.
If it helps to have an example open, the free Friday Update Brief is one written description of a finished client update, with the notes it starts from and the update it produces. Whatever you think of its particular rules, it shows what a preference looks like once it's written down. It costs an email address.
Test one: could someone else apply it?
Give the standard, the notes and the finished draft to someone who wasn't involved, and ask whether the draft passes.
If they can answer, you have a standard. If the honest answer is "it depends what you were going for," you have taste. Taste matters, and clients often hire you for it, but you can't hand it over. Anything you can't hand over can't be done by anyone else, including Claude, and including you in six weeks, when you've forgotten what you were thinking this month.
You don't need an actual stranger for this. Read the standard and notice which parts would need you there to explain what you meant. Those are the parts that aren't doing anything.
You'll often see three useful, checkable requirements followed by "and it should feel like us." That last line is where every disagreement about a draft ends up, and it tells the reader nothing.
Test two: does it describe the work, or a feeling about it?
Some things are properties of the document itself: a required section, a word count, how dates are written, what comes first, what must be included or left out. Other things are reactions: concise, punchy, warm but not chatty, confident.
Here's the check. Could two reasonable people disagree about whether the finished piece has this quality? If so, it's a feeling. Nobody can disagree about whether a document has a section called Next steps. People can argue forever about whether it's punchy.
That doesn't mean how the work reads doesn't matter. It means putting that care into things you can check. "Warm but not chatty" can't be followed as a rule. The same intention written as properties can be: contractions are fine, no exclamation marks, no sentence over twenty-five words, start with the outcome rather than a greeting. Each of those can be checked, and together they get you most of what "warm but not chatty" was after.
Getting there takes an evening of noticing what you actually do. That's the real cost of a standard, and it's why most never get written.
Test three: is there a clear answer to whether it passed?
Each requirement should have a yes-or-no answer, not "more or less."
This is where most standards quietly fail, in a recognizable way. Write a limit as something to aim for and people approximate it. Write it as a line not to cross and they count.
"Keep it short" is something to aim for. Anything the writer felt was short will do: 300 words, 600, whatever the day allowed.
"Under 300 words, counted on the finished draft" is a line. It has an answer. 301 words fails, just as 400 does, and that's what makes it useful. Nobody argues with it at 5 p.m. on a Friday, and Claude can check it.
The same change works almost everywhere:
- "Include a date" becomes "a date written
YYYY-MM-DD," which can't be misread and sorts properly. - "Mention next steps" becomes "a section titled Next steps, with at least one action and the person who owns it."
- "Don't make things up" becomes "any figure that isn't in the notes is written as a visible marker, not a number."
Each of those costs you one decision: which date format, what number, which marker. You make it once, before the work, instead of in every review afterward.
⚠️ The trap here runs the opposite way to what you'd expect. When a requirement keeps failing, it's tempting to soften it: "roughly a page," "a clear next step." Then everything passes and nothing improves.
When Claude is the one checking
The three tests are the same whether a person or Claude checks the draft, but Claude makes them cheaper to apply and harder to fudge.
A person reviewing against "under 200 words" will usually let 214 through. It's close, the week was bad, and sending it back means a conversation. Claude, asked the same question, counts and tells you. That's occasionally annoying, and it's mostly the point: the limit stops being negotiable when everyone is tired.
It also changes which requirements are worth writing down. Anything Claude can check on the finished draft is now almost free to enforce: sections present, length, format, whether a figure appears that wasn't in the notes. Anything that needs judgment about the client relationship (whether this is the right recommendation for this client, whether the tone suits a relationship that's three years old) isn't, and won't be. That second kind is where your review time should go, and it only gets your attention once the first kind stops eating it.
That's the practical reason to write the standard down. Claude doesn't follow rules better than a person does. But once the mechanical half can be checked for you, you get your time back for the half only you can judge.
One real client, written down
Sam Rivera, from our worked example, sends Acme Widgets a weekly update. The contact is Priya Shah, and Sam knows three things about her: she reads on her phone, she forwards updates to her CEO without editing them, and she wants the number first.
As a preference, that's "keep Priya's updates short and lead with the result." Perfectly clear to Sam, and no use to anyone else.
Written as a standard, the same three facts become:
- Under 200 words, counted on the finished draft.
- The first sentence gives the headline metric and which way it moved.
- No attachments. Anything referred to is summarized in the email, because she's reading on her phone and forwarding it unopened.
Now every line has a reason, and someone who's never met Priya can check every one. The word limit isn't a matter of style; it's there because of the phone. Putting the metric first isn't a whim; the update gets forwarded upward without a note, so the first line is the one the CEO is sure to read.
That's what separates a standard from a style guide. A style guide says what you like. A standard says what the piece must contain, and usually why.
Why this is the part worth paying attention to
The prompts aren't the valuable part, and nor are the tools. Both are cheap now: the formats are documented, examples are everywhere, and Claude will write you a prompt for anything if you ask.
What Claude can't produce for you is the decision about what finished means for your work, your client, and how much length and risk you'll tolerate. That takes knowing why last quarter's version was too long, what the client's boss actually reads, and which section gets skipped every time. It's specific to your practice, and writing it down takes an evening that produces nothing you can send that night.
So it usually doesn't get done. The blank page is what stops people, not the idea, and "I'll write it properly next month" is how a practice ends up making the same three decisions every week for a year.
Where to start
Take whatever you send most often. Read the last three side by side and note only what's inconsistent: a section that's in one and missing from the others, three different lengths, two different date formats, an opening that changes shape each time.
Each inconsistency is a decision nobody has made yet. Make it, write it as something you can check rather than a feeling, and make sure it has a clear yes-or-no answer. Three or four of those make a working standard for one kind of document, and it takes an evening rather than a project.
If a starting point would help more than a blank page, that's what the Claude Workspace Kit is for: written standards for four common kinds of consulting work, six briefs that list the inputs they need, and context files for your practice, all filled in for a fictional practice so you can see the shape before you adapt it. And where what you need is a procedure you run on a schedule rather than a description of a document, The Solo Operator's SOP Bundle covers the recurring operational work.
Neither saves you the evening. Someone still has to decide what finished means for a particular client whose boss reads on a particular phone. What a starting point saves you is the blank page, which is usually what stops this from happening at all.