The two artifacts and why they are different
The system produces two things and confusing them is why most proof programmes stall. A quote is a client's own words about their experience, captured in a moment, ninety seconds of their time. A case study is a structured account of a situation, an intervention and an outcome, and it takes an hour of somebody's time and usually an approval cycle.
Quotes should be captured continuously and opportunistically. Case studies should be commissioned deliberately, a small number per year, from engagements chosen because they demonstrate something specific.
Businesses that fail at this treat both as the same task, and because case studies are expensive, the whole thing gets scheduled for a quieter month. Separating them means the cheap, high-volume artifact keeps flowing regardless of whether the expensive one is happening.
There is a third artifact worth naming because it is the cheapest of all and almost nobody captures it: the specific number or detail mentioned in passing. Somebody says this used to take us two days. That sentence, recorded at the moment, is what makes a case study credible eighteen months later when nobody can reconstruct it.
The architecture, part one: signals and the ask
Stage one is signal detection, and there are four recognizable versions worth instrumenting. An unprompted thank-you message after a milestone. A specific positive remark on a call, which requires whoever was on the call to flag it. A referral made casually. A client asking about expanding scope, which is the strongest signal of all and is almost never read as one.
Two of those four can be detected automatically and two require a human to flag, so the system needs both paths: a trigger on the automatic ones, and a one-click flag available to anyone on a call. The flag has to be genuinely one action, because a flagging process with three steps does not get used mid-conversation.
Stage two is the ask, triggered the same day. Not this week — the same day, because the window is measured in days and a deferred decision by a busy person is a cancelled one.
Stage three is the prompt itself, and its design is what determines the response rate. It asks two specific questions rather than requesting a testimonial: what was the situation before we started, and what has changed. Two sentences. Specific questions produce specific answers, and specificity is the only property that makes proof persuasive to a stranger.
Stage four is the draft-back. Their two sentences come back as a written quote for approval rather than as a blank page. Handing a busy person something to approve instead of something to write is the single largest lever in the system, and it is worth more than every other optimization combined.
The architecture, part two: capture, permission and publication
Stage five is storage, and the design rule is to capture always and publish selectively. Every approved quote goes into a proof library with the client, the engagement, the date, the situation it describes, and a permission state. Separating capture from publication removes the emotional cost of asking, which is what stops the habit forming.
Stage six is permission, requested at the point of publication rather than at capture. Three states are enough: usable with attribution, usable anonymised, internal only. Most clients say yes to more than founders assume, and asking later means the ask is about a specific use rather than a blanket right.
Stage seven is the case study path, which runs on a different clock. Commissioned deliberately from an engagement chosen for what it demonstrates, with a structured interview covering the situation, the constraint, what was done, and what changed. Owner: whoever ran the engagement, because the specifics that make it credible do not survive being relayed.
Stage eight is publication and placement, and the thing that matters here is that proof reaches the point of decision. A quote on a page nobody visits does nothing; the same quote next to the relevant service, in the proposal, and in the follow-up email is doing the job it was captured for.
Stage nine is the decay review. Proof older than about two years reads as historical, so a quarterly pass identifies gaps — services with no recent proof, client types unrepresented — and those gaps become the targets for the next commissioned case study.
The failure edges
The first: the ask is scheduled rather than triggered. Fires in the trough, converts badly, and the business concludes clients do not like giving testimonials. They do; they were asked at the wrong time.
The second: asking for a testimonial rather than for two answers. A blank-page request from a busy person converts at a fraction of a specific two-question one, and the answers come back generic when they come back at all.
The third: no draft-back. Expecting the client to write and polish their own quote adds a task to their week, and tasks in other people's weeks are where proof goes to die.
The fourth: capture and publication fused. If asking implies immediate public use, every ask carries a negotiation, and the friction stops the habit. Capture continuously, ask permission when you actually want to use it.
The fifth: nobody owns the flag. The two human-detected signals are the highest-quality ones, and if flagging is nobody's explicit job it will not happen, because it is not urgent in the moment it is available.
The placement question, and the backlog to run first
Captured proof that nobody encounters does nothing, so placement is a design stage rather than an afterthought. The three places that matter are the proposal, where a relevant quote sits next to the price; the service page that matches what the quote is about; and the follow-up email after a first conversation. Generic placement on a testimonials page is the least valuable location available.
That implies the library needs to be queryable by what the proof is about rather than by client. Tagging each quote with the service, the situation and the client type is what makes it possible for the proposal assembly step to pull the right three automatically — and that automation is what makes the placement actually happen rather than depending on somebody remembering.
Before building any of it, run the backlog once. Six months of client messages usually contains four or five sentences people already wrote you unprompted. Asking permission to use something somebody already said is a completely different request from asking them to write something, it converts far better, and it means the library is populated on the day the system goes live rather than in three months.
What done looks like, and what it takes to build
Done is a proof library that grows without anybody running a campaign, and a proposal that can carry three specific, recent quotes relevant to the work being proposed.
The checklist: four named signals with two automated and two flaggable in one action; a same-day ask; a two-question prompt; a draft-back step; a proof library with permission states; a separate commissioned case study path; placement at the point of decision; and a quarterly decay and gap review.
The build is one to two weeks. The genuinely hard part is the flag, because it depends on people noticing and acting in the moment, and the only way that works is if it is a single action available in the tool they are already in.
There is also a backlog worth running once before building anything: go through six months of client messages and find the sentences people already sent you unprompted. Asking permission to use something someone already said converts far better than a new ask, and it will populate the library on day one.
Trigger on the satisfaction signal and fire the same day; the window is about a week. Two questions, a draft they only approve, and capture separated from permission.