Customer Proof and Advocacy Playbook

Customer proof starts as customer feedback. Put everything customers say into one log, code it the same way every time, act on what most accounts need and tell them what changed. Then ask every customer for an honest review and the right few for a reference or a case study, get each use approved in writing, and write the case study a sceptic would believe: a specific problem, a before and after measured the same way, what else changed, and a named quote.

Founders usually ask me for case studies when a big deal stalls and the buyer wants to hear from someone like them. By then it is late: nobody wrote down the before number, nobody asked permission at kickoff, and the happiest customer has just answered a survey nobody replied to. In my view, proof is the last step of a system that starts with listening.

The rules have also tightened. In the US, a customer’s words in your marketing are an endorsement under the FTC’s Endorsement Guides^[1], and the FTC’s rule on consumer reviews and testimonials has been in force since October 21, 2024^[2]. Both shape how you ask, what you may publish and how long you may keep it up.

This playbook is the system: the log, the codes, the decision and the reply, then reviews, references, consent, the write-up and where proof goes. For NPS and the review rules in depth, read Customer Advocacy, Reviews and NPS and Review Sites for Startups.

Customers tell you what they think all the time, just rarely in the survey. It arrives in support tickets, onboarding calls, renewal conversations, lost-deal notes, interviews, review sites and cancellation forms, each in a different tool owned by a different person. Until it sits in one place, the loudest channel sets the roadmap.

Keep one log with the same seven fields for every item (Figure 1). A spreadsheet is enough at seed. Copy the customer’s exact words, not your summary, because those words become quotes and site copy later.

Then add the channels you control. A short quarterly survey reaches the accounts that never open a ticket, and the Survey Playbook shows how to write one that settles a decision. Notes from won and lost deals belong in the log too, from the Win-Loss Analysis Playbook.

A theme code turns a pile of comments into a short list of decisions. Write a codebook of 8 to 12 themes, each a problem in the customer’s words with a one-line definition, and code every item the week it arrives. When the same new problem turns up twice in a month, add a theme rather than stretching an old one.

Then count accounts, not mentions. One frustrated power user can file twenty tickets about one thing, and twenty tickets from one account are one data point. Running and Synthesizing Customer Interviews covers counting by person and weighting by severity, and the Customer Interview Kit has a coding workbook you can reuse for the log.

Tag each item with the person’s role and segment as well. A problem raised by the person who signs the renewal outranks one raised by a single user, and a theme that belongs to one segment is a segment decision, not a product-wide one.

A log nobody acts on teaches customers to stop talking. Hold one meeting a month with product, customer success and a founder, and give each top theme one of three outcomes: fix now, schedule with a date, or not planned, with the reason. My rule of thumb, not a benchmark: 45 minutes, the top five themes, and no theme leaves the room without an outcome.

Then close the loop with every account that raised the theme, by name, from a person (Figure 3). Say what they told you, what you decided, what changed and when, and what isn’t changing yet. An honest “not this quarter” earns more trust than silence.

Record each reply in the log’s action field. The share of themed items that have had a reply is the one number I track for the loop itself.

Advocacy is a set of asks of different sizes. A review takes a customer ten minutes, a reference call takes half an hour and a little of their reputation, and a case study needs approval from someone senior. Match the ask to what the customer has and what they would say (Figure 4).

The review request goes to every customer, whatever their score, because G2 removes reviews it finds were solicited only from happy customers (Step 5). References and case studies are different: you choose whom to ask. Two things decide it: whether they would recommend you, from the survey, and whether you hold a result measured against a baseline.

Without a baseline, what you have is a testimonial, not a case study. A testimonial is a useful asset with its own job, but it can’t carry a number. The Case Study Kit has a kickoff clause and a baseline record that write the before number down while it is still true.

Pick the one site your buyers check, ask every eligible customer once at a moment of value, and leave the rating to them. Review Sites for Startups covers choosing the site and timing the ask; here are the rules that shape the request.

The FTC’s rule bans giving “compensation or other incentives in exchange for, or conditioned expressly or by implication on,” reviews “expressing a particular sentiment, whether positive or negative”^[3]. It also restricts reviews written or solicited from a company’s own staff, and bans suppressing reviews with “an unfounded or groundless legal threat, a physical threat, intimidation, or a public false accusation”.

The sites go further. G2 bans “collecting reviews by any method that segments out potentially negative reviews”, bars reviews from the vendor’s employees and labels incentivized reviews^[4]. Capterra labels them too, expects any incentive to reach everyone who submits an honest review “regardless of the rating they ultimately give the product”, and counts discouraging negative feedback as fraud^[5].

Reply to every review within a week, the critical ones first, and paste each into the feedback log, because a review is feedback with an audience. To quote a G2 review on your own site, G2 requires that “the customer must opt in” and a link back to the review, on its Professional plan or above^[4]. This is orientation, not legal advice.

Whether a case study convinces and whether you may publish it are separate questions with separate owners. Settle permission early, because a page that has to come down costs more than one never written. Ask for each use separately: the company name, the logo, the numbers, a quote with a name and title, and reference calls (Figure 6).

A customer happy to be quoted may not want its numbers public, and that is a normal answer. Get approval from someone who can give it, usually the executive who owns the relationship, record what was approved, by whom and when, and file it with the contract. Send the final draft with a fixed review window.

You may tidy a customer’s words, but the Guides say an endorsement may not be “presented out of context or reworded so as to distort in any way the endorser’s opinion or experience with the product”^[1]. And a discount, free months or any other connection a reader wouldn’t expect “must be disclosed clearly and conspicuously” beside the story^[1]. This is orientation, not legal advice.

If permission stops short of the name, publish the anonymised version with the real numbers and a specific descriptor. “A 180-person food distributor in Ohio” carries most of the weight of a name and needs far less to approve.

In my view, a sceptical buyer checks the same eight things (Figure 7). Name the customer or describe it specifically, state the problem in their terms, give the before and after with one definition and a timeframe, say what else changed in the same months, and quote a named person. The checks and their weights are the ones in AAJ’s Case Study & Proof skill^[7], which scores a draft for you; the weights are my view, not research.

Keep the definition fixed between the two numbers, and don’t round up. In my view, 44% reads as more believable than “nearly half”, and it is the number you can defend. If the before number was never measured, write “not measured” and call the piece a testimonial.

One customer’s result reads as typical unless you say otherwise. The Guides say such an endorsement “will likely be interpreted as representing that the endorser’s experience is representative”, and if you can’t back that up, you should “clearly and conspicuously disclose the generally expected performance in the depicted circumstances”^[1]. Add one line with the typical result across customers measured the same way.

Run the draft through the Claims & Proof Checker before it goes to the customer. It flags every sentence that makes a claim a buyer or a regulator could ask you to back up.

In my view, proof works where a buyer has a specific doubt, not as a logo wall on every page. Write down the doubt at each buying stage and place one piece of proof against it (Figure 8). The Website & Conversion Optimization Playbook covers where proof sits on a page.

Match references to the prospect by size, system and role, and protect them. My rule of thumb, not a benchmark: no more than one call per reference a month, with a thank-you and a note on how the deal went.

Keep proof current. When an ad says the endorser uses the product, the Guides allow it only while the advertiser “has good reason to believe that the endorser remains a bona fide user of the product”^[1]. My rule of thumb, not a benchmark: recheck every named story and quote every six months, and take it down when the customer leaves or the quoted person moves on.

Then count it. Record the proof used on each deal, as the advocacy article suggests, and read win rates with and without it in each quarter’s win-loss review, remembering that small numbers swing a lot.

What changes by stage?

What mistakes should I avoid?

• Reading only the survey. Most feedback arrives somewhere else (Step 1).
• Ranking themes by mentions. One loud account can top the list (Step 2).
• Collecting feedback and never replying. Customers stop telling you things (Step 3).
• Calling a testimonial a case study. Without a baseline there is no before (Step 4).
• Asking only happy customers for reviews. G2 removes reviews collected that way (Step 5).
• Publishing on a verbal yes. Permission is written, use by use, from someone who can give it (Step 6).
• Hiding what else changed. A sceptic assumes you weren’t the only variable (Step 7).
• Leaving a story up after the customer leaves. Recheck every named story twice a year (Step 8).