---
title: "How to run customer interviews with merchants who have no time"
description: "A 20-minute merchant interview method: recruit from tickets and health scores, ask for behaviour not opinions, and turn five calls into one ticket."
topic: "Design process and tickets"
date: 2026-10-13
updated: 2026-10-13
author: "Geetansh Saini"
url: https://www.geeetansh.com/guides/merchant-interviews
tags: ["customer interviews", "user research", "customer success"]
---
# How to run customer interviews with merchants who have no time

**In short:** Merchants will not give you an hour, so run twenty-minute interviews, recruited from this week's support tickets and from your health-score bands, with a script that asks what they did last time rather than what they think. Record the call with permission, pull every sentence about an action into a sheet, and after five interviews write one ticket with the problem in the merchant's words and the evidence behind it.

## Why do merchant interviews go wrong?

Most SaaS teams interview the wrong people, ask the wrong questions, and then do nothing with the answers. The wrong people are the happy merchants who reply to emails. The wrong questions are "would you use this?" and "what features do you want?". The nothing is a Notion page of quotes that no ticket ever links to.

There is a deeper problem, and Nielsen Norman Group's [article on user interviews](https://www.nngroup.com/articles/user-interviews/) names it: interviews are an attitudinal method, so they collect reported behaviour rather than observed behaviour, and human memory is flawed, so people do not recall events fully. If you want to know what merchants actually do, you observe them or collect data about their behaviour. An interview cannot replace PostHog. What it can do, if you ask about specific recent events rather than general habits, is tell you why the funnel looks the way it does.

I spent close to two years in customer success before I moved into design, so I came to interviews from the support queue. The constraint has not changed: a merchant has twenty minutes between a Klaviyo send and a supplier call, and the interview has to earn them.

## Who should you interview, and how do you recruit them?

Two sources, and you want both, because they fail in opposite directions.

### The ticket queue

The merchant who filed a ticket this week about the problem area is the best interviewee you will ever get. The problem is fresh, they have already described it once, and they have a reason to talk to you. Ask at the end of the resolved thread: "Would you give me twenty minutes on a call to show me how you handle payouts? I will tell you what we change because of it." The last sentence matters. Merchants give time to people who close the loop.

The failure mode is that tickets over-represent merchants who complain. Balance them with the second source.

### Health-score bands

If you have a [customer health score](/guides/customer-health-score), you already have the segments. Pull one or two merchants from each band, because each band answers a different question.

| Band | What they can tell you | How to ask |
| --- | --- | --- |
| Healthy, heavy use | What the product does well, and the workaround they built on top of it | A short email from their account manager |
| At risk | What stopped working, or what they never started | The account manager calls, no survey |
| Churned or uninstalled in the last 30 days | What the decision was, and what replaced you | Email with a gift card offered, no hard feelings |

For in-product recruiting, PostHog [surveys](https://posthog.com/docs/surveys) can target by events, properties, cohorts and feature flags, so a one-question survey asking for twenty minutes can be shown only to the cohort you want, such as merchants who opened the payouts page three times this week and never completed one.

How many? NN/g's [article on interview sample size](https://www.nngroup.com/articles/interview-sample-size/) says there is no golden number, suggests starting with a small representative sample of five or six and analysing as you go, and says to stop when little new insight is being discovered with each new interview. For a single feature area in an e-commerce app, five across the bands above is where I would start, and I would look at what you have before planning more than eight.

## What does a 20-minute script look like?

The script is a time budget, not a list to read aloud. I keep it on one side of a page.

| Minutes | Block | What I say |
| --- | --- | --- |
| 0 to 2 | Setup | "Thanks. I am not selling anything and there are no wrong answers. Is it alright if I record this so I do not have to type?" |
| 2 to 7 | The last time | "Walk me through the last time you paid your affiliates. Start from what you were doing right before you opened the app." |
| 7 to 13 | The problem area | "Can you share your screen and show me? Tell me about the last time that went wrong. What did you do next?" |
| 13 to 17 | Workarounds and alternatives | "What do you do when the app cannot do that? Is there a spreadsheet? What else do you use alongside it?" |
| 17 to 20 | Close | "What should I have asked that I did not? Can I message you when we ship something from this?" |

Three habits make the script work. Ask them to share their screen whenever the subject is a task, because what they show you is closer to observed behaviour than what they say. When they finish an answer, count to five before you speak, because the second half of the answer is the useful half. And when they ask what you are building, say "I will show you after, so I do not steer you" and move on.

## Which questions get behaviour instead of opinions?

Opinions are easy to give and cheap to be wrong about. Behaviour is what they did, when, and what happened next. NN/g's [guide to open-ended questions](https://www.nngroup.com/articles/open-ended-questions/) shows the shape: "Did you find that task difficult?" becomes "How did you find that task?", and "Do you normally..." becomes "How do you normally...". Its story prompt is the one I use most, "Tell me about the last time you...", followed by closed questions only afterwards to fill in details such as when it happened. The user interviews article adds that if the interviewer asks many leading questions, the validity of the data will be compromised, so a question that contains its own answer is worse than no question.

| Instead of | Ask |
| --- | --- |
| Would you use a bulk payout feature? | How did you pay affiliates last month? Walk me through it. |
| Is the dashboard useful? | What did you look at the last time you opened the app, and what did you do after? |
| What features do you want? | What did you do last week that took longer than it should have? |
| Do you check the app on your phone? | When was the last time you opened it on your phone, and why? |
| Would you pay more for creator discovery? | How did you find the last three creators you worked with? |

Hypotheticals are the ones to cut. "Would you", "if we built", "how likely" all produce polite guesses. Merchants are kind, and kind people say yes.

## What should you record?

Record the audio with permission and get a transcript, but the transcript is not the output. During the call, or within fifteen minutes after it, fill in a sheet with one row per thing you learned and these columns:

- Merchant, plan, and band.
- The quote, verbatim. Their words, not your summary of their words.
- The action it describes. "Exports the payouts table, sorts in Sheets, pays through PayPal by hand."
- The workaround, if any. Spreadsheets and other apps are the richest finds.
- The surprise. Anything you did not expect, which is the real reason you ran the call.
- Severity for them. Did it cost them money, time, or just mild annoyance?

Do not record feature requests as feature requests. "I want a bulk payout button" goes in the sheet as the action it hides: "pays 40 affiliates one at a time through PayPal each Friday." The request is one solution. The action is the problem, and the problem is what you build from.

Compliments are nice and go nowhere. Thank them and move on.

## How do you turn five interviews into one ticket?

After five calls you have perhaps forty rows. Tag each row by the problem it describes, the same way I tag feature requests in [feature requests to roadmap](/guides/feature-requests-to-roadmap), then count merchants per problem, not rows per problem. One merchant who mentions a thing six times is one merchant.

Pick the problem that appears across bands. A problem the heavy users work around, the at-risk merchants complain about, and the churned merchants name as a reason is the one worth a ticket. A problem only the churned merchants have might already be the thing that made them a poor fit.

Then write one ticket, not five. It follows the template in [writing product tickets](/guides/writing-product-tickets), and the interviews feed two sections directly. The problem statement is one of the quotes, lightly trimmed. The evidence section lists three quotes with merchant and band, the count of merchants who hit it, the support tickets tagged with it, and the PostHog funnel if there is one. The rest of the rows go into the request log with their tags, where they wait for the next round.

Close the loop on the day the ticket ships. Message each of the five merchants with one line and a screenshot. It takes ten minutes, and it is why the next five say yes.

## Where to start

1. Pick one feature area where tickets cluster. Only one.
2. Recruit five merchants this week: two from tickets about that area, one healthy, one at risk, one churned.
3. Write the twenty-minute script on one page, with the behaviour questions from the table above adapted to the area.
4. Run the calls with screen sharing, record with permission, and fill in the sheet within fifteen minutes of each one.
5. Tag the rows, count merchants per problem, and write one ticket with three quotes in the evidence section.

## Frequently asked questions

### How many customer interviews are enough?

Five to eight for one feature area, drawn from different health-score bands, and stop when a call adds nothing new. NN/g's advice is to begin with five or six and analyse as you go rather than fix a number in advance. More than ten on one topic usually means the topic is too broad.

### Should you pay merchants for interviews?

For churned merchants, yes, a gift card is fair because they get nothing else from the call. For active merchants, the better payment is telling them what you changed because of what they said. Offering money to a merchant who filed a ticket can make the call feel like a transaction and flatten the answers.

### Who should run the interview, the designer or customer success?

The person who will write the ticket should be on the call, which in a small e-commerce SaaS team is the designer or PM. Customer success should recruit, because they have the relationship, and sit in when they can. A CS-only interview tends to turn into support, and a design-only interview tends to miss the account's history.

### What if the merchant just lists feature requests?

Let them finish, then ask about the last time they needed each one. "You mentioned bulk payouts. Tell me about the last payout run you did." Most requests dissolve into a story about a workaround, and the story is what you wanted.