Voice calibration from samples

Purpose

Generic drafts are easy to spot, and readers who know the person notice when a reply does not sound like them or gets a product detail wrong. Two things fix this: the person's own phrasing, learned from samples they wrote, and a tight set of verified facts for drafts to draw on. This skill sets up both.

When to use

• Drafts for a named person feel off-brand or generic.
• Drafts describe a product incorrectly, or describe last quarter's version.
• A new person or persona is being set up to speak for the company.

Route elsewhere when:

• The question is whether a thread is worth replying to. Use community-channel-research.
• The question is whether a finished piece reads as machine-written. Use content-authenticity-review.
• The question is whether a comment is safe to post. Use community-comment-safety.

Inputs

• Five real posts or comments the person has written, or about five source threads they would answer, from varied contexts.
• The person's own disclosure habits, such as how and how often they say who they work for.
• The product's current overview, differentiators, feature specifics, pricing, and common questions.
• The most recent release notes, so the knowledge base is current.

Procedure

Part one teaches the voice by rewriting. Part two grounds the facts. Do part one before part two.

Part one: teach the voice by rewriting

1. Draft from the source, not from the sample. For each of about five source items, the machine drafts a reply first. The person then rewrites it the way they would actually say it. If the person already approves a draft, record the approval.
2. Rewrite on first thought. The first phrasing the person reaches for is the signal. Polished phrasing hides it.
3. Vary the contexts. Pick samples from different topics or channels so the guidelines do not overfit one setting.
4. Extract the differences into written guidelines. Cover:
   • vocabulary, such as which verbs or nouns the person uses in place of the marketing ones;
   • sentence rhythm and length;
   • hedging style, such as qualifying an experience rather than stating a fact flatly;
   • how often and how directly the person discloses their affiliation;
   • comment structure, such as opening with empathy, a question, or a statement.
5. Review the extraction by hand. Extraction misses things. Edit the guidelines, and add what the person says they would never write.

Part two: ground the facts

1. Build one knowledge base per product. Keep it to the material a reader's question needs: overview, differentiators, specific features, real use cases, current pricing, and common questions. A tight set of about five pages on one product works better than a large dump.
2. Leave out what does not carry text. Images and image-only slides are not read, so the text around them is what counts. Leave out raw code and internal operating documents.
3. Keep one knowledge base per product, so the material retrieved for a question stays on that product.
4. Refresh after every major release. Out-of-date material produces confidently wrong drafts.

Output

• The voice guidelines, with each rule tied to the rewrites that produced it.
• The knowledge base, with its scope and its last refresh date.
• A short list of what the person must check by hand before the first live use.

Quality bar

Guidelines are reviewed by hand, not accepted as extracted. The knowledge base is one product and is refreshed after each major release. Samples come from varied contexts. Watch for voice tuned once and never revisited, a knowledge base padded with material nobody asks about, and drafts that describe a previous release.