How to Run a Customer Interview That Actually Produces a Case Study Worth Publishing

Most case studies that fall flat were doomed before anyone started writing. The interview gave you one nice sentence of praise and a vague "it saved us time," and now you are trying to stretch that into a story. If you are a marketing lead who has been handed a happy customer and a call on the calendar, this guide walks you through a customer interview case study process in seven steps, so the raw material you come away with can actually be assembled into a narrative.

The scope here is the customer's own proof of outcome: what they were facing, what they chose, what they did, and what changed. It is not about interviewing outside experts for authority content, which is a different job with different questions.

Choose a customer story with something specific to prove

Start by picking the right person, because no set of questions can rescue an interview with someone who was never close to the work. Look for a customer who used the product in a real situation and can speak about it from direct involvement. Recent enough to be relevant is good, but they should also have used it long enough to judge it. If the story will name the company, check early that they are willing and that whoever has to approve public use knows it is coming.

Before you schedule anything, write down the angle you think the story has. It might be a particular use case, how they got started, or why they picked you over other options. Treat that angle as a guess to test on the call, because the customer may tell you the real story is something else, and that is usually worth following.

For a bigger project, it helps to talk to the internal project lead or a colleague separately. They can help you get the order of events straight and point out facts you should double check. They are supporting context, though, and they do not replace the customer's own account of the problem and the result.

How you know it is done. You have a willing contact with firsthand experience, a plausible outcome or lesson to explore, a path to publication, and a clear guess at the story's focus.

Common mistake. Choosing a customer only because their result sounds impressive inside your company. A great number does not help much if the person is hard to reach, cannot explain how it happened, or cannot share it publicly.

Decide what the reader needs and prepare the interview

Next, think about who will read the finished piece. Picture someone in a similar situation to your customer who is deciding whether your approach is worth trying. What would that person need to understand before they believed the story? Your questions should serve that reader, and not only invite praise for your company.

Spend a little time on homework. Learn the customer's business, the interviewee's role, the use case, and any project facts you already have. Customer time is the scarce thing here, so you do not want to spend it on basic company background you could have looked up. Confirm any important background detail on the call instead of assuming it is right.

Then build a short interview guide with a core sequence and a few optional follow-ups. The question bank later in this guide is a menu to pick from, and it is not meant to be read out line by line. Several large banks of case study interview questions exist online, and no source has shown that a particular number of questions is the right one, so choose the ones that fit your story. One company's published case study handbook, for example, treats a relaxed 30-minute call as enough for its own process, which is a useful reference point and not a standard.

Send the customer the purpose of the call, how you expect to use the material, and the core questions ahead of time. That lets them prepare and keeps the basic purpose of the call from being a surprise. While you are at it, find out who needs to approve use of the company name, logo, quotes, or numbers, especially if a contract has confidentiality terms. If you plan to record, ask permission first and follow the organization's policies.

How you know it is done. You can state the audience and intended story in one sentence, you have a compact question map, you know what you already know, and the customer knows what the conversation is for.

Open with context, then let the customer tell the story

Begin with easy questions that tell you who is speaking and what they were responsible for. Say plainly that you want to capture their experience, and that this is not a test or a script to read back. Open questions tend to get you more natural detail than a string of yes-or-no prompts, so let each answer finish before you move on.

Some good opening questions are these:

• "Could you describe your role and what you were responsible for in this project?"
• "What does your team do, and who does it serve?"
• "What were you trying to accomplish?"
• "When did you first start working with us?"

As they talk, listen for the customer's own words, priorities, and definitions. Those terms are worth keeping, because they are what make the finished piece sound like a person and not a brochure. You can keep the conversation collaborative without steering every answer toward a claim you chose in advance. If an answer wanders, a respectful question about the part most relevant to the story brings it back.

How you know it is done. A reader could understand the customer's role, business context, and goal without needing any unexplained company jargon.

Common mistake. Opening with "What do you like about our product?" That invites generic praise and skips over the circumstances that make a case study useful in the first place.

Reconstruct the problem, the trigger, and the decision

A case study needs a real "before." This is the part many interviews skip, and it is why so many stories read like a thin quote with nothing around it. Ask what the customer was trying to fix, what their process looked like, how long the issue had been there, and why they acted when they did. The trigger matters a lot, so ask what happened that made this the moment. Ask about the cost of leaving it alone, and about any workarounds they had already tried.

After that, ask how they weighed their options. Include doing nothing as one of the options, along with competing products and internal approaches. You want to know which criteria mattered, what almost stopped the decision, and why the chosen approach won.

These prompts work well here:

• "What problem were you trying to solve?"
• "Why did it become important to solve it then?"
• "How long had this been an issue?"
• "What would have happened if you had not addressed it?"
• "What did you do before? What worked and what did not?"
• "Did you consider other solutions, providers, or doing nothing?"
• "What criteria mattered most in your decision?"
• "What ultimately convinced you to move forward?"

How you know it is done. You can describe the customer's earlier state, why change became necessary, and the logic behind the decision, without filling in any gaps with your own assumptions.

Common mistake. Treating the customer's choice as proof that your product is objectively better. Report their stated criteria and their experience, and attribute opinions to them, because "they picked us" is a fact about their decision and not a ranking of the market.

Walk through implementation and ask for the detail behind the result

Now move from the decision into what actually happened. A reader who is thinking about trying the same thing wants to know how the customer got from the old way to the new one, and this is where that comes out. Ask how they got started, who was involved, how the work was organized, what got in the way, and what surprised them. Find out whether they used the solution as planned or changed course along the way.

These are useful implementation prompts:

• "What was the implementation or onboarding process like?"
• "Who was involved, and what did each person or team do?"
• "What happened first, and what happened next?"
• "Did you hit any obstacles? How were they handled?"
• "Was anything different from what you expected?"
• "How did the solution become part of the team's regular work?"

This is also where follow-up questions earn their keep. A general answer such as "it really helped the team" is not something you can write from, so ask for the example behind it:

• "Could you walk me through a specific example?"
• "What did that look like in practice?"
• "What happened next?"
• "Who noticed the change first?"
• "Could you explain what you mean by that?"

Try not to let the call feel like an interrogation. If an answer is incomplete, a second question phrased differently will often get you there. If an anecdote runs long, a gentle redirect is enough. You are trying to keep the rapport while still collecting enough to write an accurate sequence of events.

How you know it is done. You can explain how the customer actually used the solution and what actions or conditions connect it to the result they report.

Common mistake. Jumping from "we bought it" straight to "we saw results." That skips the adoption story, and without it a reader cannot tell whether the result would apply to them.

Establish what changed and what evidence supports it

Outcomes are the part everyone wants, so slow down here. Ask about measurable effects and about qualitative changes. Depending on the use case, that could be time, cost, productivity, process efficiency, revenue or growth, customer service, visibility, accountability, decision-making, or how the team feels about the work. Not every story has a clean financial return, and a case study does not have to pretend otherwise.

Good outcome questions include these:

• "What results have you seen since implementation?"
• "How has the process or your work changed?"
• "How are you measuring success?"
• "Have you measured changes in time, cost, productivity, revenue, or another core metric?"
• "Can you quantify that result?"
• "What period does that result cover, and what are you comparing it with?"
• "What did the result mean for the team or the business?"
• "Were you expecting this outcome?"

When the customer gives you a number, write down its exact value, its unit, the time period, and how they explain the calculation. Ask whether it could be checked against a report, a dashboard, or another record, if one exists and they are allowed to share or confirm it. Keep an observed number separate from an estimate, a goal, or the customer's own interpretation. A story about your product does not turn correlation into causation, so do not let it.

Qualitative outcomes still count. Record them in the customer's words, with a concrete example when you can. If someone says the tool improved decision-making, ask which decision changed and what information made the difference. If they cannot put a number on a benefit, leave the percentage out and do not imply anything was measured.

There is a useful example of this in a customer service ROI study that Dimensional Research ran for Zendesk, based on nine telephone interviews. Participants described real value such as better visibility and decision-making, but could not quantify business growth as a direct result of improved service. That is a good model for how to write it up: a qualitative observation stays qualitative unless there is evidence for a number or a cause. It is also a small sample, so treat it as an illustration and not a benchmark.

How you know it is done. Every result you plan to use has a clear source and description, and you can tell which ones are measured and which are the customer's impressions.

Common mistake. Collecting a large headline number with no baseline, period, or meaning attached. A precise figure nobody can interpret or check can weaken the story instead of strengthening it.

Close the call, follow up, and draft from verified material

Before you hang up, ask what else the customer wants readers to know, what they would tell someone considering the same solution, and what comes next for them. This is also the moment to ask for permission to use any quote or identifying details in the piece you have in mind. Capture their wording accurately. A paraphrase should never be turned into a quotation, and a quote should never be polished into a claim the customer did not make.

Soon after the call, go through your notes or the transcript while the details are fresh. Mark the usable quotes, the specific examples, the claims that need confirming, and the questions you did not get answered. Then send targeted follow-up questions instead of guessing. A quick test is whether you can tell the material in order: the customer and their goal, the problem and trigger, the previous approach, the decision, the implementation, the outcome, the evidence, and what the customer learned or would advise others.

When it is time to turn customer story into case study copy, draft from the verified material only. Keep the customer at the center of the narrative. The company is not automatically the hero, and your product should not crowd out the customer's challenge, decisions, work, and results. Include specific numbers where you have them and can support them, and keep the customer's voice along with whatever qualitative context they gave you. If you have a place where your brand voice, product details, and audience are stored as context, this is where it pays off, because the draft then sounds like your company without you re-explaining it each time. DeepSmith's Deep IQ does this job, and the Writer in Content Studio uses that context when it produces an article, so you can hold the interview material to the facts you verified and let the context handle tone and positioning. It does not check customer outcomes for you, and it does not replace your own evidence review or the customer's approval.

Then send the draft to the customer and to any internal, legal, or communications approvers. Be clear about what you are asking for. You want them to check accuracy, sensitive information, names, figures, and quotations, and you are not inviting an open-ended rewrite of the marketing copy. Protect proprietary material such as private dashboard screenshots unless the customer has clearly cleared it for publication.

How you know it is done. The story has a clear arc from start to result, the customer has checked the facts and approved public use, and every claim is supported, attributed, qualified, or removed.

Common mistake. Treating a customer's willingness to speak as permission to publish every detail. Taking part in an interview and approving the published piece are two separate checks, and confidentiality still needs attention after the call is over.

A question bank to pick from

Keep a short core sequence for each call and treat the rest as optional probes. Not every question belongs in every interview, and the table below is a menu for your case study interview questions, not a form to fill out.

A few general probes are handy anywhere in the conversation: "Can you say more about that?", "Could you give me a specific example?", "What happened next?", "How did you know?", and "Can you quantify that?" Use them as the conversation calls for them. Firing all of them at the customer makes the interview feel like a questionnaire.

Check that the raw material is publishable

Before you start drafting, run a quick gate over what you collected. Your interview should have given you these things:

• A named or appropriately anonymized customer, with a clear description of their role and context.
• A specific goal or problem, why it mattered, and a reason the customer acted when they did.
• A credible account of the previous state and any alternatives they considered.
• The customer's reasons for choosing the solution, in their own terms.
• Enough implementation detail to explain how the result came about.
• At least one specific result, or a clearly described qualitative change, with appropriate attribution.
• Quotations that are accurate, useful, and approved for the intended use.
• Permission to identify the customer and publish the agreed facts, quotations, and assets.
• No unsupported causal claim, unverified metric, confidential detail, or invented narrative bridge.

If something is missing, a short, focused follow-up is better than a workaround. Where the evidence is not there, leave the claim out. Do not fill the gap with company assumptions, product marketing copy, or a number nobody gave you.

What to do next

Pick one customer you already have a good relationship with and run this customer interview case study process on them from step one, even if it feels slow the first time. Write the story focus and the five or six core questions on one page before you send the invitation, and compare your notes against the publishable checklist the same day as the call. After one round you will have a much better feel for which questions your customers answer well and where you tend to need a follow-up.

When you have a verified interview and you are ready to turn it into an article that sounds like your brand, you can start a DeepSmith free trial and see how the Writer handles it with your brand context loaded.