Customer discovery interview script: spend 30 minutes on one real event

A good customer discovery interview script gives a 30-minute call one job: rebuild one recent, relevant event well enough to inform a decision. Thirty minutes is too short to explore every workflow, test a prototype, discuss pricing and collect a company history with equal care. Pick the event and let the rest wait.

The script is our own, and its timing is a planning aid, not a research benchmark. The worked scenario is made up: a founder is learning how facilities teams coordinate non-emergency maintenance requests across office locations.

Before the call: choose the event and the one thing you need to learn

Write one sentence describing what you need to learn. For the example: "Understand where responsibility becomes unclear between receiving a maintenance request and confirming completion."

Choose a participant who has direct experience with that sequence. If you need to understand purchasing, recruit for that separately. A coordinator who knows the daily work doesn't automatically know the software budget.

Prepare a short guide and leave time afterward for notes. GOV.UK's guidance on planning a research round includes preparation, practice, and arrangements for note-taking or recording.

Keep three things visible during the call: the main uncertainty, the event you want to explore and the closing time. Everything else is optional.

Minutes 0 to 3: say what the call is for and get agreement

Open like this:

"Thanks for joining. I'm learning how facilities teams handle maintenance requests across locations. I'd like to discuss one recent, non-emergency example, from the original request through completion. I'm interested in what happened, including anything that worked well. Please avoid confidential details, and feel free to skip a question or stop."

Then explain who is present, whether you plan to record, how notes or recordings will be used, and any agreed compensation. Confirm they understand and agree before you begin. Ask separately before recording.

This opening doesn't replace the participant information you should send in advance. GOV.UK's consent guidance names purpose, recording, observation, data use and voluntary participation as information participants need. Adapt the process to your organization and the requirements that apply to you.

Minutes 3 to 6: get just enough context

Ask:

"What part of maintenance coordination do you personally handle?"

Then:

"Can you think of a recent non-emergency request you were involved in from the beginning, or from when it reached your team?"

Clarify the setting only as needed: how many people were involved in this event, which kind of location it concerned and what the participant was actually responsible for.

Skip the full organizational chart; ask about other people when they appear in the story.

If the participant didn't directly handle a suitable event, say so openly and explore what they actually did handle. If that is far from your question, end the interview politely. Don't coach them into the role the study expected.

Minutes 6 to 17: walk through one event, step by step

Start with:

"What first brought the request to your attention?"

Then follow the sequence. Use these prompts only where an answer needs detail:

• "What happened next?"
• "What did you need to know before you could act?"
• "Where did that information come from?"
• "Who took responsibility at that point?"
• "How did you know the next step had happened?"
• "What told you the work was complete?"

Draw a simple timeline in your notes and mark the trigger, handoffs, decisions and outcome. If the story jumps ahead, bring it back gently: "Before we get to completion, how was the contractor assigned?"

GOV.UK's in-depth interview guidance recommends designing the discussion around the research questions and exploring relevant experiences. The timeline is our own way of applying that to a workflow with a clear start and end.

Minutes 17 to 24: dig into the one exception that matters

Pick the part of the story most relevant to your uncertainty. Say the made-up participant mentions that two people contacted the same contractor. Do not pitch an assignment dashboard on the spot. (You will want to.)

Ask:

"How did you find out both people had contacted them?"

Then trace the consequence: "What happened because of that?" Maybe it caused duplicate work. Maybe it caused no trouble. Maybe the second contact was intentional. The answer should decide your next question.

Explore the response: "What did you do?" and "Is that how you would usually handle it?" If a tool comes up, ask what role it played instead of asking for a rating. This is also where you may learn that the supposed problem is a useful safeguard or an acceptable tradeoff.

Minutes 24 to 28: check how typical the example was

Ask:

"How similar was this request to other ones you handle?"

Follow with a counterexample:

"Can you think of a request where responsibility was clear throughout? What was different?"

Don't ask for a precise frequency if they don't track it. Record their description and what it is based on. "I remember two examples" means something different from a count taken from a system.

If your main question is still unanswered, use these minutes to fill in the missing step. Finishing the story you started beats starting a second one.

Minutes 28 to 30: play the sequence back and end on time

Offer a brief factual summary:

"Let me check the sequence: the office manager submitted the request, you assigned it, and completion was confirmed by a message from the location. Have I missed or misunderstood anything?"

Then ask what was important that you didn't cover, and explain any agreed next step. If you want another conversation, ask for it separately. One interview isn't permission for ongoing contact.

End at the agreed time unless the participant clearly wants to continue and it fits what you arranged.

When the plan breaks, use these branches

The answer becomes general: ask for the last instance they can remember, without suggesting what must have happened.

The person offers feature ideas: thank them, note the idea, and ask what experience prompted it.

A sensitive detail appears: pause and redirect to the process at a level they can discuss comfortably.

Time is running out: skip optional context and finish the main event plus the closing explanation.

The workflow works well: find out why. A reliable process tells you what conditions your product would have to beat.

Right after the call, write a debrief that keeps the limits

Write a short debrief: the event, what you observed or were told, your interpretation, any counterevidence and the questions still open. Label paraphrases as paraphrases. Mark uncertain dates and estimates.

Compare it with your other evidence before turning one half hour into a claim about a whole customer segment.