Customer Interview Script

Follow the Event, Not the Questionnaire

A customer interview becomes useful when the customer stops describing how work usually happens and begins reconstructing one time it actually happened. Dates, handoffs, improvised tools, delays, and consequences appear in that reconstruction. A list of polished questions can suppress them by forcing the customer to follow the founder’s categories.

Choose one assumption that could change the next product decision, then use this script to pursue a recent episode. The prompts are probes, not an order of ceremony. Ask the next question demanded by the story.

Do this before building, after outreach produces qualified conversations, or whenever praise for an idea has outrun evidence about the problem. If you need to understand budget, procurement, or approval in depth, take what this conversation reveals into a separate buyer interview. A user should not be made to guess how a decision they do not own would be made.

Prepare a Narrow Learning Question

Write down the person, the qualifying moment, and the decision the interview can change:

• Person: a role with firsthand knowledge of the workflow;
• Qualifying moment: a recent event they can reconstruct;
• Learning question: the uncertain fact you need to understand;
• Decision at stake: what you may build, fake, test, narrow, or stop.

“Learn about scheduling pain” is too broad. “Learn what an agency does between a same-day caregiver cancellation and a confirmed replacement” gives the conversation somewhere to go.

Bring a place to take notes and your current hypothesis about the workaround. Do not bring a feature tour. Avoid collecting names, customer records, or other sensitive details that the learning question does not require.

Make the Contract Clear

Thanks for making time. I am trying to understand how this work happens today,
not pitch a product. I will ask mostly about the last real example you remember
and may pause to make sure I have the sequence right. Near the end, if it is
useful, I can briefly explain what I am exploring.

Confirm that the person has an episode to discuss:

When did this last happen?
Where were you in the process when it began?
What set it in motion?

If no recent instance comes to mind, do not rescue the call with opinions about an imagined product. Ask whether someone else handles the event more directly, thank the person, and end early.

Reconstruct What Happened

Start with “Walk me through the last time.” Stay with the sequence until you can sketch it from trigger to outcome. Short prompts keep the customer doing the remembering:

What happened next?
Who knew at that point, and who was still waiting?
What did you open, send, check, or change?
Where did the information come from?
When did the normal process stop being enough?

When the account becomes general—“we normally,” “usually,” “the team tends to”—return without scolding: “Did that happen this time?” If the customer calls something slow, costly, or frustrating, ask for the visible consequence. What waited? What was redone? Who noticed? What other work lost time?

The workaround deserves the same care as the pain. Ask how the person recovered, what they have tried before, and why the current method survives. An awkward spreadsheet may carry trusted data, flexible exceptions, and years of local knowledge. Those are product constraints, not signs that replacement will be easy.

Modeled Conversation

This fictional continuation of the warm-introduction example shows Maya following an interruption rather than marching through topic labels.

Maya: When was the last same-day caregiver cancellation you handled?

Jordan: Tuesday, just before six in the morning. The first visit was at seven.

Maya: What happened after you saw the message?

Jordan: I opened the schedule, checked our availability sheet, and started
texting people who live near the client.

Maya: What could you learn from the schedule, and what did you still have to
find out by text?

Jordan: It showed who was technically free. It did not tell me who had already
agreed to extra hours, had transport that morning, or would take that client.

Maya: While you were finding that out, who was waiting on the result?

Jordan: The branch manager and the client's daughter. At about 6:25 I called
both because I still had no replacement.

Maya: What did you do then?

Jordan: I offered overtime to someone finishing a night shift. That solved the
visit, but the branch manager had to move her afternoon assignment.

Maya: Have you tried to make that recovery easier before?

Jordan: We made a volunteer float list. It goes stale because availability
changes and people stop answering if we use it too often.

The revealing constraint is not merely that finding a replacement takes time. The scheduling system holds formal availability; Jordan’s recovery depends on changing commitments, transport, client fit, and the social cost of repeated requests. A prototype that searches the same stale fields faster would miss the work.

Learn What Could Change

Only after the episode is clear, widen the lens:

How often does a case like this occur?
What have you or the team tried to change?
What did that require in tools, money, or staff time?
Who feels the consequence most directly?
Who would need to trust or approve a different approach?
What would make changing the current method too risky?
What event would make fixing it urgent?

Ask for what the person has observed. “Who approved the float-list experiment?” can produce a fact. “Would your director buy my product?” invites speculation. Record the named buyer, approver, or blocker as a lead for the next conversation, not as authority this participant has borrowed.

If the customer asks what you are building, answer briefly and honestly near the end. Then ask for resistance rather than praise:

I am exploring a narrow way to reduce [specific part of the workflow]. I did
not show it earlier because I wanted to understand what happens without it.
Based on the episode we discussed, what would make that approach fail here?

Close by asking permission for one concrete next step: a follow-up question, a workflow sketch review, an introduction to another actor, or a test of a deliberately narrow artifact.

Write Notes That Preserve the Evidence

Immediately after the call, record:

• the episode’s date or recency, trigger, sequence, actors, tools, and outcome;
• exact language for the consequential moments;
• the workaround, what it costs, and why it remains acceptable;
• attempts to improve it and what defeated them;
• observed urgency, authority, spend, and switching constraints;
• contradictions and missing perspectives;
• the assumption that changed, did not change, or still lacks evidence;
• the smallest next test.

Separate facts from interpretation. “Jordan sent six texts” is an observed fact. “Agencies need automated matching” is a product inference. “Would current availability data support matching?” is an unanswered question. Keeping those lines separate prevents an energetic conversation from becoming more evidence than it is.

The interview has done its job when the reconstruction changes a decision. Continue discovery when recent episodes share a consequential pattern but important constraints remain unclear. Narrow the segment or problem when the same label hides different work. Stop pursuing the thesis when qualified people cannot recall the event, its consequences are slight, or the durable workaround is better than the proposed change can plausibly be.