Start with permission and a clear evidence trail
A case study has two jobs: help a buyer recognize a relevant situation and give them reason to trust the outcome. Neither job is served by a dramatic percentage with no baseline. Before writing, confirm which customer details may be published, who can approve quotations, and which data has a reliable definition. If the customer wants anonymity, describe the industry and problem without adding identifying details by accident.
Build a source packet: interview notes, implementation timeline, metric definitions, baseline and follow-up periods, and written approvals. Distinguish observed outcomes from estimates and customer opinions. If the team changed several things at once, say so. A useful case study can still report an improvement without claiming one product caused all of it.
| Claim level | Example form | Required support |
|---|---|---|
| Situation | “The team reviewed reports manually” | Customer interview or process record |
| Intervention | “They introduced an approval workflow” | Rollout timeline and product configuration |
| Outcome | “Review time fell over the next quarter” | Comparable before-and-after data |
| Interpretation | “The workflow likely reduced handoffs” | Customer explanation and stated caveats |
Publish the story where it can be read
An HTML page can make the core story easier to discover and navigate than a download-only PDF. Use a descriptive title, a brief context block, clear section headings, an outcome table with units, and links to related product details. Keep the downloadable version if buyers need it, but do not hide the useful evidence behind a form unless there is a strong reason.
Write quotations for the specific point they support. A quote about ease of use should not be used to support a numerical ROI claim. A chart should show the timeframe, denominator, and source. If exact figures cannot be shared, use approved qualitative evidence rather than inventing precision. Keep the page current when the product changes; otherwise a case study can become proof for a workflow that no longer exists.
Use proof in the buyer journey
Map each case study to a buyer objection: implementation effort, operational control, adoption, or cost. Link the relevant section from comparison pages and sales follow-ups. Watch whether qualified visitors reach the proof and whether sales teams find it useful. The best case study is not simply the one with the biggest number; it is the one that answers a real decision with honest, inspectable context.
Interview for the sequence of change
Ask the customer to reconstruct the decision and rollout in order. What problem made the old process insufficient? Which alternatives were considered? What did the team implement first, and what changed later? This sequence helps readers judge whether the situation resembles their own. It also prevents a case study from implying that a product alone caused an outcome when staffing, process, or market conditions changed at the same time.
Request raw measures before drafting the headline. Check that the baseline and outcome use the same definition, unit, cohort, and period. If they do not, use qualitative language with an explicit explanation. A graph with an unlabeled axis or a percentage without a denominator can make a story less credible, even when the underlying work was valuable.
Build the page for different buyer questions
An executive may scan for the business problem and outcome. An implementation owner may need the steps, dependencies, and time to value. A skeptical buyer may seek caveats and the customer's own words. Use a concise summary, a visible proof table, a narrative of the change, and links to related product documentation. Make the PDF optional rather than the only place the evidence exists.
Before publication, send the complete page to the customer approver, including headlines, charts, quotation context, and any social snippets planned for promotion. Record approval and a review date. If the relationship or product changes, revisit the public story. The strongest proof ladder is one that can withstand a buyer asking, “How do you know, and would this apply to us?”
Questions to settle before a result becomes a headline
Can we use a customer estimate?
Yes, if it is clearly presented as an estimate, the customer approves the wording, and the method is explained. Do not convert a recollection into a precise before-and-after statistic. If exact data is unavailable, describe the workflow and the customer's qualitative assessment. Readers can still learn whether the situation and intervention resemble their own.
How much implementation detail should be public?
Enough to make the outcome intelligible without disclosing confidential processes. Name the team, starting problem, major steps, and constraints at an approved level of specificity. A statement such as “we automated reporting” is thin; a sequence showing source collection, review, and sign-off is more useful. Let the customer review operational details before publication.
Copy this claim ledger
For each proposed sentence, record claim type, source, measurement period, unit, customer approver, and limitation. Label it observation, quotation, estimate, or interpretation. A chart requires its own denominator and data owner. Link the final public sentence back to the ledger and set a review date. If the source cannot support the wording, revise the wording before asking design to make the claim visually prominent.