Customer interview templates for B2B tech case studies

Most customer interviews for B2B tech case studies produce 45 minutes of polite generalities and one usable quote. The marketing team comes away with a recording, a vague sense of the story and a draft that ends up reading like a testimonial wall. The fix is rarely the interviewer. It is the question set.

We have run hundreds of these interviews for managed service providers, SaaS vendors and ERP consultancies, including work for Littlefish, Codestone and Aspire Technology Solutions. The interviews that produce a usable case study tend to use the same scaffolding. The ones that fail share the same mistake: too many open-ended questions and not enough specifics.

Why most interview templates fail

A typical case study interview template asks questions like “what challenges were you facing?” and “how has the solution helped?” These are the questions a marketing team would write if they had never sat in front of a CIO. They invite generic answers because they are generic questions. The customer fills the silence with vendor-flavoured phrases they have heard in webinars and the marketing team is left trying to reverse-engineer a story from sentiment.

A good interview template does the opposite. It asks for specifics so narrow that the customer cannot fall back on platitudes. “Tell me about the Tuesday morning your old ticketing system fell over” produces a story. “How did our solution help?” produces nothing. The template below is built on that principle.

The four-part interview structure

We split every case study interview into four blocks. They run roughly 12 to 15 minutes each, totalling about an hour. Anything longer and the customer starts repeating themselves. Anything shorter and you miss the texture.

1. Before. What was the situation, what was breaking, what had been tried.
2. Decision. Why they chose you, who was involved, what nearly went wrong.
3. Work. What actually happened during the engagement, in plain language.
4. After. What changed, with numbers where possible, plus what is next.

The interview should be recorded and transcribed. We use Riverside or Descript for this because the transcription is good enough to quote from directly. Notion or Google Docs are fine for the working draft.

Block one: before

The “before” block is where the case study earns its right to be read. If the buyer cannot recognise their own situation in this section, they stop reading. The questions we ask:

• Walk me through what your team was doing before you brought us in. Not the abstract version. What did Monday morning look like.
• What had you already tried. What did not work, and why.
• Was there a specific incident or moment that made you decide something had to change.
• Who in the business was complaining loudest about the problem.
• If you had done nothing for another six months, what would have happened.

The last question is the one that pulls out stakes. Customers underplay urgency in the moment but become honest about it in retrospect. The answer to “what would have happened if you had done nothing” is often the most quotable line in the whole interview. Our piece on case studies that close walks through how that quote ends up in the published draft.

Block two: decision

The decision block is about credibility. Buyers want to know they are not the only person who would have made the same call. The questions:

• How did you find us. Who recommended us, what did you read, what made the shortlist.
• Who else did you consider, and what did the comparison come down to.
• Who in your business needed to sign off, and what were they worried about.
• Was there a moment in the early conversations where you nearly walked away.
• What did you ask us that you would not have thought to ask a year earlier.

That last question often produces the strongest material. It surfaces the buyer’s own learning curve, which is exactly what the next buyer wants to read. A piece of writing that reflects how technical buyers differ from business buyers tends to land harder when it is grounded in this kind of real reflection.

Block three: work

The work block is where most templates rush. The interviewer assumes the work itself is technical detail the buyer will not care about. They are wrong. The next buyer absolutely cares, because they want evidence the work was done properly. The questions:

• Talk me through the first 30 days. What was the kick-off like, who was involved, what surprised you.
• What was the hardest moment in the engagement, and how did we handle it.
• What did we do that another vendor probably would not have.
• Was there anything we got wrong, and how did we fix it.
• Where did the work overlap with your internal team. What did they pick up.

Asking what went wrong is non-negotiable. Customers respect vendors who can hear it. The published case study does not have to dwell on the mistake, but acknowledging it once makes the rest of the piece feel honest. Case studies that read as flawless read as fiction.

Block four: after

The after block is where the metrics live. The mistake here is asking for numbers in the abstract. The fix is to anchor every number to a specific change in working life.

• What is your team able to do now that they could not do before.
• What has changed in your reporting, your meetings, your inbox.
• Tell me one specific metric that has moved, and what the before and after are.
• What was the unexpected benefit. The thing you did not buy us for.
• What is next. What will the next 12 months look like.

The “unexpected benefit” question is where second-stage stories come from. The original engagement was a help desk transformation, but the customer mentions in passing that they are now planning a Microsoft 365 migration with the same team. That sentence becomes the foundation of the next case study, the next account expansion and the next sales conversation.

Approvals before, not after

The single biggest reason case studies die in production is legal review. We avoid that by getting approvals scoped at the start. Before the interview, we send a one-page approvals brief that covers what is on the record, who needs to sign off, what figures can be quoted and what the timeline looks like. If specific numbers are off limits, we agree on ranges or proxies in advance. By the time the draft is written, the path through legal is already mapped.

We also send the customer the question set 48 hours before the interview. This is counter-intuitive: most interviewers prefer to keep the questions a surprise so the answers are fresh. In B2B tech, that approach loses you the specifics. Customers need time to remember the right Tuesday morning, dig out the right number and check the right ticket. The interview is much richer when they have prepared.

What we hand to the writer

After the interview, the writer gets four things. The recording, the transcript, a one-page summary of the strongest moments and a list of usable quotes with timestamps. From there, the case study writes itself in a few hours, not the two days it takes when the writer is starting from a vague brief. Our content marketing service and editorial calendars for tech marketing teams post both lean on this same handoff workflow. If the case study sits inside a wider content programme that compounds, the interview becomes raw material for blog posts, sales decks and webinar segments too.

If you have a customer who has agreed to a case study and you are not sure how to get the most out of the interview, drop us a line and we will share the templates we use.