Case Studies That Get Quoted: Numbers, Names, and Structure

Case studies are expensive to produce. Making them quotable is cheap by comparison.

Why most case studies are invisible

Three habits make a case study unreadable to an engine.

The result is at the bottom. The page opens with "the challenge," spends four paragraphs on the customer's background, and reveals "a 34% reduction in onboarding time" in the final section. Engines tend to weight the top of the page. By the time the number appears, the engine has already decided what the page is about.

The customer is vague. "A leading logistics provider" cannot be matched to anything. An engine answering "who uses X in logistics" needs a name it can resolve as an entity. If legal will not allow the name, the case study will still help humans, but it will not be cited for company-specific prompts.

The number is inside a quote. "We saw huge improvements, maybe 30 or 40 percent," says the VP. A quote is an opinion. The same figure stated plainly in your own prose, with the measurement period, is a fact.

The structure that works

Put a summary block at the very top of the page, above the narrative, in plain text:

• Customer: Northwind Logistics, 1,200 employees, Chicago
• Industry: Freight brokerage
• Problem: Manual load matching took dispatchers 40 minutes per load
• Result: Load matching time fell to 6 minutes, measured over 90 days
• Timeframe: Deployed March 2026, measured through June 2026

That block is quotable line by line. An engine answering "how much time does [product] save dispatchers" can lift one line and be accurate.

Then write the narrative beneath it for the humans who want the story. The two audiences are not in conflict; they just need different parts of the page.

Numbers that engines trust

A result needs four things to be quotable: the metric, the baseline, the outcome, and the period. "Reduced churn" has none. "Monthly churn fell from 4.1% to 2.6% over the six months after rollout" has all four.

State the measurement method in a sentence. "Measured in the customer's own billing system" or "based on support ticket volume in Zendesk" is enough. It makes the number defensible, and defensible numbers are the ones that spread to the roundups and comparison pages engines also read.

Avoid rounding to the dramatic. "Nearly tripled" is less useful than "rose from 210 to 590." Avoid ranges unless the range is the honest answer.

Names that engines can resolve

Use the customer's real name and link it to their website. Mark the page up with Organization schema for the customer and Article schema for the study. Add a Review block only if the customer actually provided one.

If the customer cannot be named, name everything else: the industry precisely, the company size as a range, the region, the role of the person quoted. "A 300-person freight brokerage in the Midwest" is far more resolvable than "a leading logistics provider."

Titles and URLs

Title the page with the customer name and the result: "Northwind Logistics cuts load matching time 85% with Acme." Not "Customer Story: Northwind." The URL should contain the customer name. These are the fields an engine reads first.

What we check

At AEO GEO Labs a case study review in an audit asks five questions: is the result in the first 100 words, is the customer named, is the metric stated with baseline and period, does the title contain the result, and can a text-only fetch read all of it. Most case studies fail at least three.

Take your most important case study and rewrite only the top of the page using the summary block above. Leave the narrative alone. Then run the prompt "who uses [your product] in [customer's industry]" in Perplexity and see whether the page appears. If you want the full set of pages checked for the same five questions, AEO GEO Labs includes it in every visibility audit.