8 SaaS Case Studies Worth Stealing From, Annotated

Image URL

Do not index

AI summary

The page explains eight SaaS case‑study examples and extracts key mechanics for effective storytelling: use a customer‑owned headline with the outcome, include a byline, add a three‑line summary box with distinct numbers and labels, show the “before” number, describe the measurement method, admit honest setbacks, and provide both a detailed narrative and a concise one‑minute version, while emphasizing the importance of numbers tied to method, scope, units, itemised sums, control groups, and authentic attribution.

Title

8 SaaS Case Studies Worth Stealing From, Annotated

Date

Description

Eight live SaaS case studies from Linear, Fin, Ramp, Gong, PostHog, Supabase and Vercel, annotated: where the number sits, who's talking, and what the headline promises.

Status

Current Column

Person

Writer

You finally got a customer to say yes.

You wrote it up: challenge, solution, results. It reads fine.

Then a rep pastes it into a deal, and the buyer skims it in twenty seconds and remembers nothing.

The story wasn't the problem. The mechanics were: where the number sits, who's actually talking, and whether the headline promises anything. This post looks at eight live SaaS case studies and points at those parts, one by one. All eight were checked on 5 November 2026.

These are single case studies, the document itself. If you want the page that holds a whole library of them, that's a different teardown: annotated case study landing pages. If you haven't run the interview yet, start with our guide to customer case studies.

What to look at in any SaaS case study

Five things, in the order a buyer meets them:

The headline. Does it promise a result, and whose result is it, yours or the customer's?

Who's talking. A logo, or a named person with a job title the buyer can match to their own?

The number. Is there one, and does it come with a "before", a method, or a scope?

The honesty. Does the story admit anything: other factors, a feature nobody used, a slow start?

The skim. Could a rep get the point across in one minute, from this page alone?

None of the eight gets all five right. Each one does at least one of them better than most case studies you'll read this year.

1. Linear and Brex: the number comes with its method

Linear's Brex story has a headline that tells you the shape of the proof before you read a word of it: "Brex proved Linear's impact with a data-driven pilot."

Then it shows the pilot. Before switching, Brex "conducted a survey to establish baseline metrics on engagement, satisfaction, ease of use, and team understanding of their connection to the product roadmap," with answers ranked from 1 to 5. "They repeated the same survey after the pilot to see how Linear stacked up against the initial responses."

Only after that do the numbers arrive, six of them as large stat cards: "47% Increase in daily usage," "63% Increase in overall user satisfaction," and four more.

That order is the whole lesson. A buyer who reads "47%" cold wonders where it came from. A buyer who has just read how it was measured doesn't need to wonder. The method is three sentences long, and it does more for the number than any amount of bold type.

The sidebar helps too: "Founded San Francisco, 2017" and "Switched August 2024." A buyer can tell at a glance how long Brex has been on it.

What it costs: six stat cards is a lot to take in. Survey-based numbers also measure how people feel about a tool, not what it changed in the business, and a sceptical engineering lead will notice.

Copy: one or two sentences on how the number was measured, placed directly above the number. Skip: the fifth and sixth stat cards. Lead with the two that matter.

📷

ASSET NEEDED — annotated screenshot. What: linear.app/customers/brex, desktop — the "The pilot: Proving it works" section through the stat-card grid. Annotate: (a) the baseline-survey paragraph, (b) the "47% Increase in daily usage" card directly below it, (c) the "Founded / Switched" sidebar. Why here: the reader has just been told the method is the lesson. Naming: cs06-linear-brex-annotated.png. Credit Linear in the caption: "Screenshot: Linear, 5 Nov 2026."

2. Fin and Clay: the "before" sits next to the "after"

Fin's Clay story does two things in its first screen that most case studies never do.

First, it names the people. Under the headline, "Transparency and trust: Why Clay chose Fin," a byline reads "With Jess Bergson, Head of CX, and George Dilthey, Head of Support from Clay." A head of support reading this knows within a second that it's written for them.

Second, the hero numbers have a scope: "90% Fin involvement rate," "~7k Support tickets managed per month," "Up to 50% Fin resolution rate."

The better line is further down, in the results: "Having started out with a 20% resolution rate when they first rolled out Fin for in-app messaging, the team has now boosted that to between 45-50% across every support channel."

That sentence has a start point, an end point and a scope. It also admits the first number was modest. That admission is what makes "45-50%" believable. A case study that only shows the finish line reads like an advert.

What it costs: the hero says "Up to 50%" while the body says "between 45-50%". It's the same claim, but a careful buyer will read "up to" as a ceiling, not a typical result. The page is also long, which is a lot to ask of someone mid-deal.

Copy: the starting number, said out loud, in the results section. Name the people in a byline under the headline. Skip: "up to" in a hero stat, if the body has a firmer range.

📷

ASSET NEEDED — annotated screenshot. What: fin.ai/customers/clay, desktop — headline, the "With Jess Bergson, Head of CX…" byline and the three hero stats (90% / ~7k / Up to 50%). Dismiss the cookie banner first. Annotate: (a) the byline naming two roles, (b) the "~7k Support tickets managed per month" scope. Naming: cs06-fin-clay-annotated.png. Credit Fin: "Screenshot: Fin, 5 Nov 2026."

3. Ramp and Notion: three numbers, each with its own unit

Ramp's Notion story puts its proof in the hero, over the photo, before any story at all.

Three stat cards, each a number, a unit and a short line telling you what it counts:

"94% of transactions" / "are compliant and in-policy"

"$1M+ annual savings" / "through prevented out-of-policy transactions"

"75+ hours" / "saved by finance teams every month"

Look at the units. A percentage, a dollar figure, a count of hours. Each one speaks to a different person in the buying group. The controller reads the first, the CFO reads the second, and the finance team reads the third. Three numbers in the same unit would have said the same thing three times.

Further down, the results list does the "before" trick: "95% of transactions now include receipts (up from 80% pre-Ramp)." The quote comes from Brandon Zell, named in the body as Notion's Chief Accounting Officer, the person whose name a CFO would recognise as a peer.

What it costs: with this much proof in the hero, the story underneath has little left to reveal. Two of the three hero numbers also come with no "before". Notion's "75+ hours" is a lot, but compared to what?

Copy: three hero stats in three different units, each with a one-line label. Skip: stats in the hero you can't back up with a "before" further down.

📷

ASSET NEEDED — annotated screenshot. What: ramp.com/customers/notion, desktop — the hero with the three stat cards. Annotate: (a) the three different units (%, $, hours), (b) the one-line label under each. Naming: cs06-ramp-notion-annotated.png. Credit Ramp: "Screenshot: Ramp, 5 Nov 2026."

4. Ramp and Perplexity: the big number, itemised

Ramp shows up twice on purpose. Its Perplexity story solves the problem the Notion story leaves open.

The hero says "163+ hours/month" / "automated across close, coding, and admin." On its own, that's another big round number.

Then the results section adds it up in front of you. The monthly close is compressed "by roughly 115 hours per month." GL coding saves "approximately 28 hours." The vendor card program "eliminates roughly 16 hours of monthly card administration." Bill pay saves "another 4+ hours." And then: "Add it up: the team automates an average of 163 hours of finance work every month."

115 + 28 + 16 + 4 = 163. You can check the sum yourself, so you don't have to take the number on trust.

The same section frames the coding rate with volume: "roughly 7,000–9,000 card transactions per month, coded automatically at 97%." A percentage of nine transactions and a percentage of nine thousand are different claims, and this page says which one it's making.

It also gives the customer's controller, Lauren Feeney, a reason to trust the tool, not just praise for it: "It draws my attention to anything worth an extra pair of eyes and tells me why."

What it costs: the itemised sum is buried in the last third of the page. The hero says "163+" and the body says "an average of 163". A small mismatch, but it's the number the whole page rests on.

Copy: break your biggest number into its parts and show the sum. Skip: a hero number the body rounds differently.

📷

ASSET NEEDED — annotated screenshot. What: ramp.com/customers/perplexity, desktop — the hero with ">97% of transactions" and "163+ hours/month". If possible, a second crop of the "Add it up" paragraph. Annotate: the hero 163+ and the four parts (115 / 28 / 16 / 4+). Naming: cs06-ramp-perplexity-annotated.png. Credit Ramp: "Screenshot: Ramp, 5 Nov 2026."

5. Gong and Anthropic: the number in the headline, with honest attribution

Gong's Anthropic story puts the result in the headline: "Anthropic's 64% productivity gain: Combining revenue AI with a customer-centric GTM strategy."

The headline belongs to the customer. It's Anthropic's gain, not Gong's feature. A buyer scanning a list of links sees an outcome they'd want, attached to a name they know.

What I like more is the attribution. The summary says "By implementing strategic efficiencies, including the Gong Revenue AI OS, Anthropic achieved a 64% increase in seller productivity." Later: "Using Gong and other efficiencies, Anthropic has seen remarkable results, including 46% faster ramp times."

"Including" and "other efficiencies" are small words. They tell a sceptical buyer the vendor isn't claiming every point of the gain. I'd expect a customer's legal team to sign off on wording like this faster, too.

The page also has an adoption number that needs no method at all: "Seller use of the Gong Revenue AI OS has grown from 91 to 243 seats." Seats are counted, not estimated, and they show the customer chose to expand.

What it costs: the page never says how "seller productivity" was measured. A buyer who asks "64% of what?" won't find the answer here. The quotes from Kevin Jordan, GTM Enablement Lead, are warm but general. None of them contains a detail only Anthropic could have said.

Copy: a customer-owned headline number, honest attribution ("including"), and a seat or usage count as adoption proof. Skip: a headline metric you can't define in one line.

📷

ASSET NEEDED — annotated screenshot. What: gong.io Anthropic customer story, desktop — headline plus the Challenge / Results summary block. Annotate: (a) "64%" in the headline, (b) "including the Gong Revenue AI OS" in the summary. Naming: cs06-gong-anthropic-annotated.png. Credit Gong: "Screenshot: Gong, 5 Nov 2026."

6. PostHog and Y Combinator: a control group, and a feature nobody used

PostHog's Y Combinator story leads with "How Y Combinator used PostHog experiments to boost engagement by 40%," then backs the 40% with the design of the test, in the customer's own words.

Cat Li, Product and Engineering Lead for Y Combinator Startup School, explains the experiment: it "hides profiles that have been stale for 3, 6, 9 or 12 weeks. We found that users in the 6-week group sent 40% more messages than the control group." Then a second result: "this experiment group had 35% more of their requests accepted."

"Than the control group" is the most persuasive phrase in the piece. It tells a technical buyer the number came from a comparison, not from a before-and-after where anything else might have changed.

Then the page does something rare. It tells you about a failure: "A lot of people asked us to build a feature that let co-founders collaborate on a trial project... when we ran that experiment and looked at the results, we found nobody actually used it at all."

That paragraph sells experiments better than the 40% does. It shows the tool saving the customer from a mistake. Buyers know every project has misses, so a story that includes one reads as true.

What it costs: the page is dated October 2022, and nothing on it says whether the results still hold. A buyer who notices the date will discount it. The headline's "engagement" is also broader than what was measured, which was messages sent.

Copy: the comparison in the customer's words ("than the control group") and one honest miss. Skip: a headline word broader than the metric underneath it.

📷

ASSET NEEDED — annotated screenshot. What: posthog.com/customers/ycombinator, desktop — the headline and the "How Y Combinator boosted Co-founder Matching engagement by 40%" section with Cat Li's quote. Annotate: (a) "than the control group", (b) the "nobody actually used it at all" paragraph. Naming: cs06-posthog-ycombinator-annotated.png. Credit PostHog: "Screenshot: PostHog, 5 Nov 2026."

7. Supabase and Chatbase: the customer's story, with the vendor in the background

Supabase's Chatbase story has a headline that doesn't mention a single feature: "Chatbase goes upmarket on Supabase." The subhead is about the customer's business: "The consolidation play that took a single founder from zero to 10 million in ARR, and the bet that takes him to 100."

The numbers are Chatbase's, not Supabase's. The page describes "an 18 person company with eleven engineers, more than 8,000 paying customers, and an ARR that has climbed past 10 million dollars without a single dollar of venture funding." Supabase never claims credit for those numbers. It's the platform underneath: "the backend underneath the product has stayed the same."

That restraint is what makes it work for founders, the buyer here. A founder reads a founder's story and asks "would this hold for me?", not "is this vendor exaggerating?"

The quotes are specific enough to be one person's. Yasser Elsaid, Founder and CEO, on a migration most vendors would rather not mention: "We were using Pinecone for vector embeddings because that was the default a few years ago." Pinecone is named as the sensible default it was, not run down, and that keeps the story credible.

The sidebar does the matching work: "Use case: AI customer support agents" and a list of the products used.

What it costs: the page is long and essay-like. A rep can't skim it on a call. With no vendor-owned outcome number, a buyer looking for "what did the product change?" has to work it out from the story.

Copy: a headline about the customer's goal, and the customer's own business numbers as context. Skip: the essay length, unless founders are your buyer and they read.

📷

ASSET NEEDED — annotated screenshot. What: supabase.com/customers/chatbase, desktop — headline, subhead and the About sidebar (Use case / Solutions). Annotate: (a) the customer-goal headline, (b) "zero to 10 million in ARR" in the subhead, (c) the sidebar. Naming: cs06-supabase-chatbase-annotated.png. Credit Supabase: "Screenshot: Supabase, 5 Nov 2026."

8. Vercel and Ramp: the one-minute version

Vercel's Ramp story is labelled "1 min read," and it means it.

Headline: "How Ramp kept 100% uptime through 100x traffic surges on Vercel." Then a box headed "Ramp on Vercel" with three lines: "Full site migration to Next.js on Vercel," "100% uptime and 0% error rates through 100x surges," and "AI SDK implemented to build semantic search across scattered internal assets." Then two short paragraphs, and it's over.

This is the version a rep actually uses. It fits in an email, in a Slack reply to a prospect, or on one slide. Every case study you write should have a version like this, even if a long one exists too.

The second paragraph also gives the number its occasion: the site held "100% uptime through traffic surges of 100x during stunt-marketing events." "During stunt-marketing events" is three words, and they turn a vague surge into something a marketing lead can picture.

What it costs: there's no quote and no named person. It's Vercel's voice throughout, and a buyer can't tell whether anyone at Ramp would say it. One minute is enough to get the point across, but not enough to convince anyone on its own.

Copy: a three-line summary box at the top of every case study. Skip: shipping only the short version. Pair it with a long one a buyer can check.

📷

ASSET NEEDED — annotated screenshot. What: Vercel's Ramp customer story, desktop — headline, "1 min read" label and the "Ramp on Vercel" three-line box. Annotate: (a) "1 min read", (b) the three-line summary. Naming: cs06-vercel-ramp-annotated.png. Credit Vercel: "Screenshot: Vercel, 5 Nov 2026."

What the eight have in common

Go back through them and the pattern is about the number, not the writing.

The strong ones never leave a number on its own. Brex's comes with its survey, Clay's with its 20% start, Perplexity's with its sum, and Y Combinator's with its control group. Notion's comes with its unit and label, and Anthropic's with "including." The weak spots across all eight are the same too: a hero number the body rounds differently, a headline word broader than the metric, a stat with no "before".

If I had to pick one mechanic to copy first, it's Clay's: say the starting number out loud. It costs you nothing, the customer already knows it, and it makes the final number believable.

Here's a structure that combines what works:

Headline: the customer's outcome, with the customer's name. "[Customer] [did what] in [time]."

Byline: the person's name and job title, under the headline.

Summary box: three lines, one number each, each with a label saying what it counts.

The "before": the starting number, said plainly.

The method: one or two sentences on how the number was measured.

The honest bit: other factors, or one thing that didn't work.

The long story: for the buyer who wants to check.

For how that structure works in a real sales cycle (skimmed on a phone, pasted into email, one number quoted on a call), see case study formats.

Doing this with Testimonial

All eight of these depend on something you can't write your way around: the customer telling you the starting number, the end number and their job title. That's the interview step, and it's where most case studies stall.

Case Study sends your customer a question set they answer on their own time, typing or by voice, with no call to schedule. Answers arrive in your inbox already attributed to the person you invited, so the byline is done. Put "What was the number before you started?" and "How did you measure it?" in the question set, and you'll have the "before" and the method from the start. Our case study questions has thirty more, each with the answer it gets you.

One limitation: Case Study collects what the customer tells you. It won't measure anything for you. If your customer doesn't track the metric, no question set will produce it, and the honest move is to write the story without a number.

Case Study is on the Ultimate + plan, priced per space. Details are on pricing.

Before you publish anything a customer said, get their permission, and their company's sign-off on the numbers.

Wrapping up

That's eight SaaS case studies, and the mechanics to steal from them: a method above the number, a "before" next to the "after", units that speak to different buyers, a big number itemised, honest attribution, a control group, the customer's own story, and a one-minute version.

Got a case study draft with a number you're not sure how to frame? Reply and send it over. I'll tell you which mechanic I'd add first.