The Case Study Interview Script: Questions That Get Numbers

The decision rule for the whole script fits in one line: ask for the quantity and the date before you ask for the reaction.

This ordering matters because people do not carry percentage improvements in their heads; they carry the count on a screen, the size of a backlog, the number of people on a team. Ask about the state and they can reconstruct it. Ask about the improvement and they will estimate, hedge or flatter you.

The journalist's version is to ask about pain points and frustrations, then how the person felt about solving them, because the numbers prove the return while the conflict produces the quotes a prospect can relate to (Gainsight). Note the sequence: facts first, feelings second. Reverse it and the customer starts rounding in your favor, which is the last thing a credible case study needs.

The first five minutes decide whether you get data. Frame the call as research, not a favor, and give the customer explicit permission to describe limitations. Guides built around proof recommend separating participation from praise and telling the customer where the material may appear and how approval will work (100tasks). That lowers the pressure to perform.

A tested opening, in order:

1. Purpose and scope. "I want to understand how the work actually happens on your side, including what was hard. Nothing goes public without your review."
2. Permission and logistics. Ask to record so you can focus on the dialogue, and confirm that material is used publicly only after approval (t2d3). A quiet forty-five minutes beats a rushed thirty; let silence work, because the valuable detail often arrives after the first polished answer (100tasks).
3. The first real question, deliberately uncontaminated. "Take me back to when this first became a problem. What was happening in the business that week?"

That third question asks for a scene, not a judgment. Compare it with "what problem were you trying to solve with us?", which has already named you as the solution and invites the customer to narrate backward from a happy ending. The scene-first version gets the trigger and the old workflow before the customer has any reason to shape the story for your benefit.

Then ask the follow-up most interviewers skip: "why did it become important then?" Timing reveals urgency better than a generic problem statement (100tasks). A budget deadline, a new hire or a lost customer converts a mild annoyance into a before state a reader recognizes in their own business.

The baseline is the hardest part and the most valuable. Most customers have never been asked to state it, and their memory of the old process compresses into "it was manual and slow." Unpack that into three types of measure:

• How many. Units processed, people involved, open items, tickets, clients served.
• How often. Times per week, batches per month, rework cycles per quarter.
• How long. Hours per instance, days end to end, wait time at a step.

Ask each about a specific occasion, not the general case. "Can you walk me through the last time you did it that way?" produces a real sequence, which is more useful than "it was inefficient" (100tasks). Record the date of that occasion: a baseline tied to "a Tuesday in March" is easier to defend than one tied to "before."

A worked example shows how the numbers land. Suppose a finance team says the old process "ate a lot of time." Push on the three measures and you might get three clerks, each spending about 10 hours a week matching invoices, roughly 40 hours a week across the team, plus an error-correction cycle every month. That is a defensible baseline at the specificity level a pilot proof framework asks for: who participated, how long, and what the old workflow was (Dowhatmatter). Later, the after state is compared on the same three measures.

One caution: customers remember the peak, not the typical. When someone says "some weeks it was 30 hours," ask "what was a normal week?" and note both. Publish the typical figure and use the peak as context.

Every before-and-after claim needs a hinge: the date the change happened. Without it, a reader cannot judge whether the after state has settled, and a skeptical buyer assumes the best week was cherry-picked.

Document the key dates in order: contract signed, first login, initial setup, first workflow completed, first measurable result, full rollout (CaseLeap). Those six dates become your timeline, and they reveal the gap between first use and first measurable result, which is the time-to-value figure software buyers care about most.

Ask three questions here:

1. "On what date did the new process become the normal way you do the work? Not the pilot, the normal way."
2. "What did the old measure read on the last day before that switch?" That closing reading is more precise than an average.
3. "What does the same measure read now, and as of which date?" Fix the as-of date, because a figure without one invites the reader to assume it is current.

Separating pilot from rollout is not pedantry. A case study that blends a three-week pilot with company-wide adoption produces a number nobody can replicate, and sophisticated buyers distrust outcome promises without the mechanism (Dowhatmatter).

Sooner or later the customer says "much faster," "way fewer errors," and pauses, satisfied. This is the moment the interview succeeds or fails. Do not accept the adjective and do not argue with it. Run a loop: name the unit, get the before, get the after, get the source.

For "much faster": "Faster in what unit, minutes per ticket or days per batch?" Then, "what did it average before?" For "fewer errors": "Fewer of what, and who counts them?" Errors are countable if a system logs them: reconciliation breaks, tickets tagged to a defect, credits issued, rework hours.

Well-crafted questions prompt customers to share specific examples rather than general impressions (FreeOnlineSurveys), and the loop above is the mechanical version of that. Concrete numbers are what let a case study differentiate instead of repeating that the product "made things much easier" (Weber Associates).

Ask feeling questions after the numbers and keep them narrow. "When you saw the Tuesday report read 300 instead of 700, what did people say in the channel?" produces a usable quote. "How did it feel to transform your operations?" produces a sentence no editor can keep.

Some interviewees will not give you a number however you ask. They are not being difficult: they may not own the metric, lack system access, or fear committing to a figure that gets audited later. Diagnose which and route around it.

Ask who owns the number. "Who on your team would know that figure?" Then request it in writing after the call. A follow-up email with three specific asks ("the weekly invoice count in the month before, the same count last month, and the report it comes from") beats twenty more minutes of live coaxing.

Offer a bounded estimate. "Would it be closer to 10 hours a week or 30?" gives an anchor pair, and people pick between two options far better than they generate a figure from nothing. Record that it was an estimate and label it as one in the draft.

Ask about artifacts rather than memories. "What does your Monday report show?" moves the conversation from recall to a document the customer can open. Writers who treat the interview like journalism, asking for the specific example rather than the summary, end up with quotes and figures they can use (Elliott Pearce).

Fall back on behavioral proof. Early customers may have no ROI figure, and that is fine. Repeated use, a workflow change, a signed letter of intent or an expansion request all rank above compliments on a proof strength ladder (Dowhatmatter). "Four SDRs used it for 14 days, logged in daily and agreed to a paid extension" is specific and checkable.

The last ten minutes are for verification, not new stories. Read back every figure you intend to use, attached to a source and a date, out loud, so the customer hears the claim as a reader will.

• Figure and date read back. "So 4,200 invoices a month before go-live, and 3,100 last month, correct?"
• Source named. "And both come from the accounts payable summary in your finance system?"
• Scope confirmed. "That is the whole department, not the pilot group?"
• Attribution confirmed. "This appears as a quote from you, with your title?" Any quote, logo or result needs permission before publication (100tasks).
• Direction of travel checked. "Is the figure still moving, and which way?" A metric improving month over month is a different story from one that plateaued.
• Next step agreed. "I will send the draft with every number highlighted and its source noted, and we publish only after you sign off."

That last point is not a formality. Adobe notes that customer involvement and approval is one reason marketers avoid case studies in the first place (Adobe), so build approval into the interview while the source systems are open in another tab.

Before you leave, ask "what did we not ask that would help someone in your position decide?" The answer often surfaces the objection that nearly stopped the purchase, which belongs next to your pricing page. Questions that uncover hesitation and what convinced the buyer to proceed are among the most valuable in a testimonial interview (FreeOnlineSurveys).

A finished case study should include specific outcomes, because that is the section buyers read first (Articulate Marketing). An interview run this way produces that section in a form that survives legal review, sales reuse and a skeptical prospect's arithmetic.

Turning the transcript into a draft is mostly editorial: pulling quotes, building the problem, solution and outcome arc, keeping each figure attached to its source. That mechanical pass is a reasonable place to use help, and the writing stays the differentiator. If you want a second reader or a finished draft built from your transcript and the checklist above, a Quanta expert can hand one back with every number flagged to its source.