How Do You Write a B2B SaaS Case Study Without Hard Numbers?

Can a B2B SaaS case study work without hard numbers?

Yes. A case study without metrics can still persuade if it shows a believable before and after, names the specific workflow that changed, and lets the customer explain in their own words why they would buy again. Buyers trust specific detail more than round percentages, especially percentages they suspect were rounded up.

Most early-stage SaaS teams stall on case studies for the same reason. The customer is happy, but nobody measured the baseline. There is no clean "before" number, so there is no "40 percent faster" headline, so the case study never gets written. Meanwhile, sales keeps asking for proof.

My position is that a missing metric is not a reason to skip the case study. It is a reason to write a different kind of case study. Some of the most convincing proof I have seen on SaaS websites contains no percentage at all.

What makes a case study persuasive if not the numbers?

Specificity and recognition. A buyer reads a case study to answer one question: is this company like mine, and did the product solve a problem like mine? Concrete detail about the team, the old process, and the new process answers that question better than a metric the buyer cannot verify.

Think about how a buyer actually uses a case study. They are usually mid-evaluation, trying to picture the product inside their own company. A number helps them estimate value. But a detailed story helps them estimate fit, and fit is what kills most deals. If the story sounds like their week, they lean in.

There is also a credibility angle. Experienced buyers have read hundreds of case studies with suspiciously neat improvements. A case study that admits the team did not measure the baseline, then describes exactly what changed, often reads as more honest than one with a headline stat.

What should replace the missing metric?

Replace the metric with observable change. Describe what the team stopped doing, what they started doing, and what became possible that was not possible before. "The sales team no longer copies leads from a spreadsheet each morning" is concrete, verifiable by the customer, and easy for a reader to picture.

I use three kinds of observable change. The first is removed work: a manual step, a meeting, or a tool that disappeared. The second is new capability: something the team can now do, like route leads by territory or see pipeline by source. The third is changed behavior: who now uses the product, how often, and for what.

Each of these can be stated precisely without a number. And when the customer reads the draft, they can confirm each one is true. That makes approval easier, which I covered in how to get a customer to approve a SaaS case study. Customers are far more comfortable signing off on facts than on figures they never measured.

How do you structure a case study without metrics?

Use a simple arc: the situation, the trigger, the old way, the decision, the new way, and what the customer would tell a peer. Each section should be short and concrete. The trigger is the most important part, because it tells a buyer when they should start looking for a product like yours.

The situation sets context: company size, team, and the job they were trying to do. Keep it to a few sentences. The trigger is the moment the old way became unacceptable. A new hire, a missed deal, a board question, a tool reaching its limit. Buyers recognize triggers instantly because they have their own.

The old way describes the workaround in detail. Spreadsheets, copy and paste, a person who held the whole process in their head. The decision covers why they chose your product over alternatives, including doing nothing. The new way describes the workflow today. And the closing quote is the customer explaining, in their words, what they would say to someone in their old position.

This structure works on a page, in a sales deck, and as a source for AI answers. I wrote more on case study page structure that wins clients and AI citations, and the same logic applies here. Clear sections with plain facts are easy to read and easy to quote.

Which questions should you ask the customer?

Ask about moments and routines, not outcomes. "Walk me through a Monday before you switched" and "what did you stop doing after the first month" produce usable detail. "How much time did you save" usually produces a guess, and guesses either get rounded up or get cut by legal before publishing.

I like a short interview of about eight questions. What was happening at the company when you started looking? What were you using before, and what was annoying about it? What made you decide to change now rather than next quarter? What else did you consider? What surprised you during setup? What does your team do differently today? Who uses it most? What would you tell someone in your old job?

Record the call, with permission, and pull quotes directly from the transcript. Light edits for grammar are fine. Rewriting the customer's words into marketing language is not. The rough edges are what make a quote sound real.

If the customer does mention a number in passing, ask a follow-up: how do you know? If they have a real source, like a report in their CRM, you may have a metric after all. If they are estimating, use their words and make it clear it is their estimate.

How do you handle estimates and soft numbers honestly?

Attribute them to the customer and label them as estimates. "Their head of sales estimates the team spends about half as long preparing for pipeline reviews" is honest. "50 percent faster pipeline reviews" turns an estimate into a claim your company now owns. If someone later asks for the source, you want the first version.

This matters more than it used to. Buyers increasingly ask AI assistants to summarize vendors, and those assistants often repeat figures from case studies. A soft number that reads like a hard one can travel far beyond your website, stripped of its context. Writing it honestly from the start protects you.

A good rule: if you could not show the calculation to a skeptical procurement team, do not present it as a metric. Present it as the customer's view, or leave it out. The case study will still work.

What details make an anonymous or small customer believable?

Role, situation, and process detail. If you cannot name the company, name the role of the person quoted, the type of company, and the exact workflow that changed. A believable anonymous story is specific about everything except the logo. Vague anonymous stories read as invented, even when they are true.

Some customers will not allow their name or logo. That is common with larger companies and in regulated industries. You can still describe the company as a mid-sized logistics software firm with a four-person revenue operations team, as long as that is accurate. I covered the mechanics of writing a case study when you cannot name the client in more depth.

Small customers have their own advantage. A founder of a ten-person company can usually speak more freely than a director at a big enterprise. Their quotes tend to be more candid, and early-stage buyers often relate to them more than to a famous logo they will never resemble.

How do you use these case studies in sales and marketing?

Match each case study to a trigger and a buyer role, then put it where that buyer is deciding. A case study about replacing spreadsheets belongs in follow-up after a first call with a team still using spreadsheets. A case study about scaling a new sales team belongs on a page aimed at revenue leaders.

Tag each case study in your CRM or content library by trigger, industry, company size, and role. That lets a rep find the right story in seconds instead of sending the same one to everyone. It also shows you where proof is missing. If no case study covers your most common trigger, that is the next one to write.

On the website, put short excerpts near the decisions they support. A two-sentence quote about setup speed belongs near the onboarding section. A quote about replacing a competitor belongs on the comparison page. Proof works best when it answers the question the reader has at that moment.

I approach this the same way in my own practice. Some of my work, like the HubSpot automations I run through Zapier for Kismet Health, is easier to describe as a workflow than as a single number. Other work, like the Ajust automations built on Airtable and WhaleSync, has clear figures behind it, including more than 25,000 cases delivered. Both kinds of proof have a place.

What should you do next?

Pick one happy customer you have not written up because you lacked numbers. Book a short interview, ask about routines and triggers instead of outcomes, and draft a case study around observable change. Attribute any estimate to the customer, get their approval, and tag it by trigger and role so sales can use it.

Then look for patterns across three or four of these stories. The triggers that repeat are your best messaging. The old workarounds that repeat are your best outbound angles.

If you want help turning customer stories into case studies and pages that actually support deals, reach out. Let's chat about the proof you already have and how to put it where buyers will see it.