The Brand Messaging and Positioning Cookbook: One Page, One Workshop, Proof for Every Claim

A brand messaging framework is a single page that lets anyone in the company describe what it does, for whom and why it is worth choosing in the same terms. It is not a tagline, a logo guide or a set of adjectives. It is an agreement. The reason to keep it to one page is that people will only use what they can hold in their heads, and a document that needs a meeting to explain has already failed the test.

The frame in this cookbook starts from the five components of positioning that April Dunford lists in her positioning work: competitive alternatives, differentiated features or capabilities, value for customers, target customer segmentation and market category. We add three boxes because messaging, unlike positioning, has to survive contact with a buyer: the problem in the customer's own words, the proof for every claim, and a list of claims the company will not make. The sequence matters. Alternatives come first because a capability is only differentiating relative to something. Value comes from the capability, the segment from who cares most about that value, and the category from the context that makes the value obvious.

The most common failure in a messaging exercise is starting with the product. A team lists what it has built and then looks for a reason to care. The framework reverses this. It begins with the people and their situation, what they were doing before the company existed, and the problem expressed as they would say it to a colleague. The GOV.UK Service Manual makes the same point about services: write needs from a personal perspective, using words that users would recognize and use themselves. That advice translates directly to messaging, where borrowed jargon is the quickest way to sound like everyone else.

Resist adding boxes. Every extra box invites a second page, and the second page is where agreement stops. If a stakeholder wants something added, ask which existing box it belongs in or which box it replaces. The table below is the whole framework, with the question each box answers and a test to apply before the box is marked done.

A positioning workshop works when it argues about evidence and fails when it argues about taste. The cure is pre-work. Ask each participant to bring three things. The first is the last five deals they remember well, two won and three lost, with the reason in the buyer's words where they have it. The second is the three questions they are asked most often by prospects. The third is any written feedback from customers, such as review text, survey comments or support transcripts, which the company already holds and has the right to use internally. The facilitator collects these a few days ahead and sorts them into the framework boxes on a wall or a shared board.

Choose participants who hear buyers. That normally means sales, customer success or support, marketing and a person with authority over the product or the offer. Executives who have not spoken to a customer recently can attend but should not set the agenda. Name one decision-maker before the day starts, because a workshop that ends in "we will think about it" has produced a list of opinions and no framework. In a small company the decision-maker is usually the founder or the head of marketing. The role matters more than the title.

The agenda below runs about three and a half hours with one break. It follows the framework order and ends with the proof inventory, which is the step teams most often skip. Time is tight on purpose: a longer session gives the loudest voice more room, not the best idea. If a box is not settled in its slot, the facilitator records what is missing and who will bring it, and the group moves on. A box left open with an owner and a date is better than a box filled with a compromise nobody believes.

Record every decision on the wall in the words that were agreed, not in a summary written later. The worksheet in this cookbook has the agenda as rows with an outputs column, so the team can edit the timings and reuse it for the next market or product line.

A positioning statement is one or two sentences that compress the framework. We suggest a plain format, which is our own working template and not a standard: "For [segment] who [situation or problem], [name] is a [category] that [main value]. Unlike [alternative], we [difference], which we can show with [proof]." It is meant to sit at the top of the page as a summary, and every bracket should have an answer in a box below it. If a bracket has no answer, the statement is claiming something the framework has not established.

Writing it last protects the group from the commonest workshop failure, which is falling in love with an opening line. A sentence drafted on the first morning acts as a magnet, and every later box gets bent to fit it. Written at the end, the statement can only contain what survived the evidence. It will often be less exciting than the first draft, and it will be more accurate. When the two diverge, trust the evidence.

Test the statement four ways before sign-off. The swap test replaces your name with a competitor's: if the statement is still true, it is too generic to position anything. The sales test asks a salesperson to say it aloud to a colleague: if they stumble or paraphrase it into something else, the paraphrase is probably closer to what buyers respond to. The proof test checks that each claim has a row in the inventory. The scan test puts the statement at the top of a page and asks whether a visitor can find the offer and the audience in a few seconds. Nielsen Norman Group reported in 1997, from its research on how people read websites, that 79 percent of its test users always scanned any new page and only 16 percent read word by word. That is an old study with a small sample, and the habit may have moved, but it supports writing the opening so that a skim carries the point.

Keep the statement internal at first. It is a tool for alignment, and it will rarely read well as published copy. The public versions, such as the headline, the first paragraph of the home page, the ad line and the opening of the sales deck, are written from it and tested on their own. Treat the statement as the source and the public copy as the translation.

The proof inventory is a list of every claim the messaging makes, matched to the evidence that supports it. It is the part of the cookbook that keeps the framework honest after the workshop energy has gone. Each row has a claim, the proof type, the source on file, who owns it, when it was last checked, when it should be checked again and a status. The status has three values: on file, to collect, and cannot support.

The Federal Trade Commission's policy statement on advertising substantiation says advertisers and agencies need a reasonable basis for advertising claims before they are disseminated, and that the requirement covers express and implied claims that make objective assertions about the product or service. The statement is about advertising, and your messaging will appear in advertising, on a website and in sales material, so the safe working practice is to treat the framework's claims the same way. This is not legal advice, and what counts as a reasonable basis depends on the claim. Where a claim is sensitive, such as a comparison, a performance figure or a claim about health, money or safety, have a qualified person review it.

Proof comes in kinds, and the kind should fit the claim. A claim about what the product does is supported by a demonstration, a specification or documentation. A claim about results is supported by data that the company holds, with the period, the method and the limits recorded, and if the data does not exist, the claim does not. A claim about customers is supported by named customers who have agreed in writing to be named, or described anonymously with their consent. A claim about the market is supported by a named, dated, primary source. A quotation is verbatim, attributed to a real person and used with their permission.

Three rules keep the inventory useful. First, never fill a gap with something plausible. If the framework needs a number, a customer name or a quote that the company does not have, mark it "to collect" and give it an owner and a date. Second, let proof expire. A result from two years ago, or a feature that changed, needs a re-check date, and the claim comes down if the check is not done. Third, keep the inventory next to the framework, in the same file, so no one edits one without seeing the other.

A claim marked cannot support leaves the framework. This is the step that costs the most in the room, because the claims people most want to keep are often the ones with the least proof. Write down the claim and the reason in the "claims we will not make" box. That record stops the same claim reappearing in a new campaign six months later.

Objections are the other half of the messaging. They show what the buyer was told by the page and did not believe, or was not told and needed to know. The objection handling table in this cookbook has ten columns in the CSV. The core ones are the objection in the buyer's words, where it was heard, what they are really asking, the honest answer, the proof, the person who answers it, where the answer appears on the website or in the deck, and the date it was last reviewed. Start the table from sales and support notes, not from a brainstorm. A brainstorm produces the objections the team wishes buyers would raise.

The "really asking" column is where the table earns its keep. "It is too expensive" can mean the price is above budget, the value is unclear, the buyer cannot judge what they are comparing it with or they need a number to defend to a manager. Each reading calls for a different answer. Write the underlying question first and the answer second, and when sales is unsure which reading applies, the answer should include a question that finds out.

The answer must be honest, which sometimes means a plain concession. If the product is not right for a certain kind of buyer, say who, and say what they should use instead. A messaging page that concedes a real limit is easier to believe on the points where it makes a claim. The concession belongs in the table so that sales has an approved way to say it.

Place each answer where the objection arises. A pricing objection belongs on the pricing page and in the proposal, not in a general FAQ. A "can you work with our systems" objection belongs near the integration description and in the early sales call script. Write answers in the buyer's own terms and keep them short enough to scan, since the earlier-cited reading research suggests visitors skim.

Review the table with sales and support every quarter. Add new objections, retire old ones and check whether the proof still holds. If an objection keeps recurring after the answer has been published, the answer may be wrong, or the objection may be pointing at something the offer needs to change. That second possibility is a decision for the owner of the offer, not the copywriter.

A framework that lives in a slide deck drifts within a quarter. Version it, date it and name an owner who approves changes. The owner is usually a marketing lead, but the right owner is whoever can say no to a new claim. Store the framework, the proof inventory and the objection table in one shared location with a change log, and link to it from the places where people write: the website content brief, the ad request form and the sales enablement folder.

Roll the framework out in the order that buyers meet the company. Start with the pages that receive the most entry visits, then the paid ad copy that sends traffic to them, then the opening of the sales deck and the first outbound email. Check each piece against the framework with the same four tests used on the positioning statement, and record the result next to the asset. Google asks, in its people-first content guidance, whether a site has a primary purpose or focus, and it is a useful test for the whole system: if two pages on your own site describe two different companies, the framework has not landed yet.

Set review dates by the volatility of the claims. Claims about features, pricing and customers should be rechecked on a short cycle, because they change with the product and the contract. Claims about the market and the category change more slowly. Put the next review date in each row of the proof inventory and in the calendar of the owner. When a date passes without a check, the claim comes down, which is a stricter rule than most teams like and the only one that makes dates mean anything.

Finally, test whether the messaging is working with the evidence you can collect. Ask new customers, in a short free-text question, why they chose you and what nearly stopped them, and compare the answers with the framework. Listen to a sample of sales calls where the company has consent to review them. Look at which objections recur. None of this proves a lift in revenue, and we do not claim it does, but it shows whether the words in the framework are the words buyers use, which is the thing the framework was built to achieve.