How to write a b2b case study when your client won't get on a call

Every guide on how to write a case study for b2b assumes the same starting point: you schedule a 30-minute call with the client, ask a list of prepared questions, record it, and write from the transcript. That process works fine in theory. In practice, half the clients you most want a case study from will not commit to that call, and the ones who do often give short, distracted answers because they are fitting you into a gap between their own meetings.

I have written case studies both ways, with the ideal interview and without it, and the version without a formal call is not a lesser substitute. Done right, it produces a more honest case study, because it pulls from things the client actually said and did during the project instead of what they remember to say when put on the spot in an interview.

Why the standard interview approach fails so often

The client who agreed to buy your service is not the same person who has time for a 30-minute unpaid interview about how it went. Busy operators, especially at smaller companies, treat "getting on a call to talk about the project" as a favor they will get to eventually, and eventually often means never. Chasing that call repeatedly costs you goodwill you would rather spend elsewhere.

Even when the call happens, it often underperforms. Put someone on the spot and ask "what results did you see," and most people give a vague, polite answer, because recalling specific numbers and specific moments from memory, live, on a call, is genuinely hard. The best details, the actual friction points and turning points, tend to surface later, almost by accident, in a follow-up email or a passing comment in an unrelated conversation.

Build the case study from material you already have

The fix is to stop treating the interview as the only source and start treating the entire project as the source. If you ran the engagement, you already have most of what a case study needs, scattered across email threads, project management tool comments, and status update calls that already happened for other reasons.

Pull the original scoping conversation, where the client described their problem in their own words before you reframed it in yours. That description is usually more specific and more emotionally honest than anything they will say in a polished interview later, because at that point they were not thinking about how it would sound in marketing copy. They were just describing what was actually going wrong.

Pull the status updates from partway through the project. This is where the friction lives: a note about a delayed asset, a comment about an approach that had to change, a moment where the client pushed back on a recommendation before eventually agreeing to it. These moments are exactly the kind of honest detail that a case study needs and that a live interview rarely produces, because nobody remembers to mention friction when asked to summarize a project after the fact.

Pull whatever final deliverable or result reporting already exists. If you sent a wrap-up email or a final report with real numbers, that email is more reliable than anyone's memory of the numbers months later.

Write a draft before you ever ask for a call

Once you have pulled the problem statement, the friction, and the result from material that already exists, write a full draft case study before contacting the client at all. This changes the entire dynamic of what you are asking them for.

Instead of asking a busy person to schedule 30 minutes to be interviewed, which requires them to generate content from memory on demand, you are asking them to review a short draft and confirm it is accurate, or correct anything you got wrong. Reviewing something specific and mostly finished takes five minutes. Generating content from an open-ended question takes real cognitive effort and a chunk of calendar time most clients will not give you.

Send the draft with a short, specific ask: "Here's a draft based on our project notes, can you confirm the numbers in the second paragraph and let me know if I've misrepresented anything." That is a request most clients will actually act on, often within a day, because you have done the hard part for them.

A worked example of the pull-not-ask approach

Here is how this plays out with a pattern I see often. A client runs a small commercial cleaning company and just finished a three-month engagement helping them rebuild their local SEO after a site migration tanked their rankings. Asking for a case study interview gets the predictable response: "sounds good, let's find time," followed by three weeks of no follow-up.

Instead, pull the original kickoff call notes, where the owner described the actual pain: "we lost half our phone calls the month after the new site launched, and nobody could tell us why." That is the problem statement, in the client's own words, more specific than anything a scheduled interview would likely produce.

Pull the mid-project status update where the client pushed back on redirecting an old high-traffic page, worried it would confuse existing customers, before ultimately agreeing after seeing the alternative traffic data. That is the friction, already documented, already honest.

Pull the final report showing call volume recovering over the following two months, with the specific baseline and recovery numbers already calculated for the client at the time. That is the result, already verified, with no memory involved.

Draft the case study from those three pieces, send it to the owner with one specific question, "can you confirm the call volume numbers in paragraph four are still accurate," and you have a finished, honest case study without ever asking for a call that was never going to happen anyway.

What to do when you genuinely have nothing documented

Sometimes the project ran informally enough that none of this material exists in a usable form. In that case, do not default back to the open-ended interview request. Ask one specific question by email instead of requesting a call: "What was the one thing about this project that would have made you nervous if it had gone differently." A specific, narrow question like that produces a usable, specific answer over email in a way that "how did the project go" never does, and it costs the client thirty seconds instead of thirty minutes.

This same principle, that specific narrow questions outperform open invitations, is worth applying anywhere you are trying to get real detail out of a client, not just for case studies.

Handling the client who will not let you use real numbers

A separate problem shows up once you have a usable draft: some clients are happy to confirm the story but will not let you publish the actual figures, especially around cost, revenue, or anything that reveals their internal operations to competitors. Do not treat this as a reason to invent a safer-sounding number instead. A fabricated number that gets caught, by a competitor who knows the client or by the client themselves noticing it later, does more damage to your credibility than a case study with no numbers at all.

Ask the client directly what they are comfortable with instead of guessing. Often the objection is narrower than it first sounds. A client who will not confirm exact revenue figures will frequently agree to a percentage change, a relative comparison, or a timeframe instead. "Cut close time by more than half" survives most confidentiality concerns that "reduced close time from eleven days to five" would not, and it still gives a reader something concrete to evaluate. When even a relative figure is off limits, lean harder on the process and friction details instead, since those rarely raise the same confidentiality concerns and still do real work convincing a skeptical reader you know what you are doing.

Getting the structure right once you have the material

Pulling the material solves the production bottleneck, but it does not automatically produce a case study that generates leads. The structure still matters: a specific named problem, the real decision process behind the solution, honest friction, and a result described with enough context to mean something. That structure is covered fully in the anatomy of a case study that actually generates leads, and it applies whether the raw material came from a formal interview or from pulled project notes.

Once the case study exists, you still have to decide how to use it, including when a shorter testimonial actually does more work than the full case study for a given reader. That decision is covered in testimonial vs case study: which one moves your buying committee.

Make this a habit, not a rescue mission

The real fix here is not a better interview technique. It is capturing the problem statement and the friction points while the project is happening, not months later when you decide you need a case study and go digging through old emails hoping something usable survived. Build a habit of saving the kickoff call notes and the mid-project pushback moments somewhere searchable, and every project becomes a case study candidate without extra work later.

This kind of system, treating your actual client work as an ongoing source of content rather than something you write about separately, is one of the bigger gaps I see across the content marketing work service businesses do. If your case studies keep stalling because clients will not commit to interviews, this pull-not-ask approach removes the dependency entirely. And if you want a system built around your actual client work instead of one-off requests for a call that never happens, that is what lead generation services is designed to handle.

You do not need your client's calendar to write a case study that works. You need the material that already exists from doing the work, and thirty seconds of their time to confirm you got it right.