The draft sounds fine. It doesn't sound like you.

The draft says, “Effortlessly elevate your team's collaboration.” Your product lets someone assign a comment to a colleague.

You ask the AI to sound more human. It replies, “Teamwork just got a whole lot easier.” The sentence is friendlier. The useful detail is still missing.

Before changing the tone, put the actual action back into the sentence: “Assign the comment to the person who needs to answer it.” Now you have something to edit.

A usable brand voice reference tells a writer what to notice, what to name and how to speak about it. It also includes examples of decisions you have already made. “Confident, friendly, authentic” leaves too much of that work to interpretation.

Make a voice sheet someone can use in five minutes.

Here is a complete starter sheet for a fictional product called Threadwell. In this example, it is a workspace where a user can attach a file, leave a comment, manually assign that comment and mark it resolved. No automatic routing or delivery-time improvement is established.

The sheet doesn't need a personality quiz or twenty adjectives. It needs enough context to help two people make similar editing decisions.

Start with sentences you would actually approve.

Collect a few pieces of your own writing: a useful product explanation, a clear answer to a customer question, a caption you still like after a week. Use material you have permission to share. Remove private details before putting it into an AI tool.

For each example, annotate the choice that makes it work. “This sounds like us” is a reaction. “It names the customer's task before mentioning the feature” is an instruction another writer can follow.

You may discover that your best examples behave differently. The product tutorial is direct; the founder's note is more reflective; the response to a broken export is brief and serious. Preserve those differences. A joke that fits a recording-session post can be irritating when someone is reporting a failure.

If the company is new, write the initial examples yourself and mark them as proposed. Ask the person responsible for the brand to approve or revise them. Don't describe a set of generated samples as an established company voice just because they are consistent with one another.

Outside writing can help you identify qualities you like: a clear opening, a patient explanation, a surprising but earned example. Convert those observations into your own editorial rules. Copying somebody else's biography, signature phrases or personal authority won't give your product a voice.

Edit the same message three different ways.

Take this deliberately weak draft:

Unlock next-level productivity with Threadwell's revolutionary AI-powered platform. Seamlessly automate your feedback workflow so your team never misses a beat.

The problem isn't just the adjectives. The sentence adds AI and automation to a product description that established neither. Removing “revolutionary” leaves the false implication in place.

For a demonstration: “Open a comment, choose an assignee, then mark it resolved when the answer is in.” The recording needs to show those actions. This version belongs with a step-by-step screen capture.

For a post about the problem: “The client left a comment. Who answers it?” Follow with a clearly labeled sample file and the manual assignment. The opening gives the demonstration a reason to exist.

For a caption under that recording: “One person owns the next reply. In this example, Maya is assigned the comment about the cover image.” Maya is a fictional participant in sample data, not a quoted customer.

All three versions are compatible with the voice sheet. They have different jobs, so they shouldn't be interchangeable. Pick the job before asking for five versions of the line.

There is room for personality too. A dry line such as “The file named final-final is back” can work if the footage explains the actual version problem. If the joke is the only specific thing in the post, finish the explanation before polishing the punchline.

Give the model a bounded assignment.

A long prompt can still be vague. What helps is separating facts, evidence and editorial choices so the model doesn't have to infer all three from a homepage.

Here is a reusable assignment for the fictional demo:

Write one opening line, a short spoken explanation and a caption for a screen recording. The audience is a small design team reviewing a client file. The recording shows a user opening a comment, manually assigning Maya, then marking the comment resolved. Maya and the file are sample data. Use the attached approved voice sheet. State only the supplied actions; don't add AI, automation, time savings or customer outcomes. The post should explain who owns the next reply. End by asking which part of the review process is unclear. If a necessary fact is missing, list the question separately instead of inventing an answer.

Attach the approved examples and the actual content brief. Treat the output as a proposed draft. A prompt that asks the model to avoid inventions doesn't establish that it succeeded.

Check the nouns and verbs first. Did “assign” become “automatically routes”? Did “sample file” become “a customer project”? Those small changes can alter the meaning more than an entire paragraph of generic language.

Then check the voice. Would a colleague say this while explaining the recording? Does every sentence add information, an example or a useful transition? Read it aloud at the speed the video needs. A phrase can look elegant on a page and take too long to say over the action.

Keep the facts separate from the way you express them.

Your voice reference may stay useful for months. A feature limit can change tomorrow. Maintain a current product-facts note alongside the writing examples, with an owner and a checked date.

For Threadwell, “manual assignment” belongs in the facts note. “Use the same name as the interface” belongs in the voice sheet. If the team later ships automatic assignment, it can update the first without rewriting its whole personality.

Hexwave's intended website-to-content workflow starts from product context. During early access, treat that as the direction we're building toward. Whatever tool you use, reviewing the underlying context is part of reviewing the copy.

Turn repeated edits into examples.

Suppose a reviewer keeps replacing “boost productivity” with the exact thing the user does. Save one before-and-after pair with the reason: “The original asks readers to infer the benefit. The revision shows the action they can inspect.”

That is more useful than adding “productivity” to an ever-growing banned-word list. There may be a later article where the word is appropriate. The recurring mistake is making an unsupported, unspecified promise.

Keep a compact set of strong examples. Remove a reference when it depends on an old feature or no longer represents a choice you endorse. Otherwise, the writing tool can faithfully reproduce yesterday's mistake.

To test the sheet, give the same brief to another writer. Ask them to explain one choice they made using the reference. If they can only point to “friendly,” the sheet needs a clearer example. If they can explain why they kept the interface label or removed a result claim, it is doing useful work.

Finish with a review of the actual export. The words may be right while the image shows a capability the product doesn't have. A consistent voice should make the real product easier to understand, including its boundaries.