A customer switch interview reconstructs one real decision to leave an old way of working and adopt a different one. Start with the change the person actually made, then work backward through the problem, the search, the alternatives and the moment of commitment. The output is a timeline of causes and trade-offs, not a wish list of features.
This approach is useful when a team can see signups but does not understand why people finally acted. It builds on the listening and follow-up techniques in a well-structured user interview, with a narrower focus: the sequence behind a recent switch.
Ask about progress, not just the competing tool
A customer may say they chose an invoice app because it was easy to use. That description leaves important questions unanswered. Easy compared with what? What had become difficult? Why did they switch that week rather than three months earlier?
The Christensen Institute's Jobs to Be Done theory focuses on the progress people seek in particular circumstances, including functional, social and emotional dimensions. A switch interview applies that perspective to a concrete event. It does not assume the named competitor is the whole problem or that every person sharing a job title wants the same outcome.
Someone may switch from a spreadsheet, a colleague's help, a paper notebook or doing nothing. Include those alternatives. A person who buys a new tool but continues doing the important work elsewhere has not necessarily completed the change you want to understand.
Recruit around an actual change
Choose participants who can describe a specific switch relevant to your question. For an invoicing study, that might be independent professionals who recently sent their first client invoice using a different system. Define the period to fit the buying cycle and the likelihood of remembering events; “recent” is not one universal number of days.
Useful screening questions ask what they used before, what they use now, roughly when they changed and whether they personally helped choose or set up the replacement. Avoid screening with “Were you frustrated by late payment?” That reveals the story you hope to hear.
Use a research screener based on relevant behavior to distinguish the decision-maker, the person paying and the daily user. Their accounts can all be useful, but they answer different questions. Do not treat an administrator's purchase explanation as evidence of how every employee experiences the tool.
Include people who considered your product and chose another option when that is practical. Interviewing only enthusiastic new customers can conceal the anxieties or practical barriers that prevented other people from moving.
Reconstruct the timeline in six passes
Introduce the session as a conversation about a decision, explain recording and data handling, and obtain the participant's agreement. Ask them to avoid sharing confidential client information. Your job is to understand their sequence, not to defend a product or steer the conversation toward a demo.
1. Establish the new arrangement
“What are you using now, and what have you actually done with it?” Establish the end of the timeline first. Someone may have purchased an annual plan but not migrated their information. Another may have adopted the free version months before paying. Note these as separate events.
2. Find the first concrete struggle
“Take me back to the first time you thought the old approach might need to change. What was happening?” Follow vague answers with an episode: the task, who was involved, what they expected and what happened instead. Avoid supplying the explanation for them.
3. Find the shift from noticing to searching
“What made you look for another option at that point?” Separate casual awareness from active evaluation. A colleague's recommendation might introduce a tool; a missed deadline might make the person willing to try it. They are different parts of the decision.
4. Revisit the actual alternatives
“Which options did you seriously consider? What did you do to compare them?” Ask about trials, messages to colleagues, pricing checks or a decision to keep the old process. When someone names a feature, ask what it would have let them accomplish.
5. Locate commitment and hesitation
“What happened immediately before you decided to proceed? Was there anything that almost stopped you?” An easy import, a reassuring answer or a deadline may matter more than a long feature list. Record the participant's explanation without turning it into a universal buying rule.
6. Compare the promise with first use
“Tell me about the first real task you completed. What was different from what you expected?” Ask what they still do in the old tool. A partial switch may reveal a missing capability, a collaboration dependency or a habit that the new interface has not replaced.
Example: an invoice switch that was not mainly about templates
Consider this fictional interview scenario. A freelance illustrator used a spreadsheet and emailed PDF invoices. After a client paid late, the illustrator began looking for a replacement. They initially described their goal as “more professional invoices.”
A follow-up about that particular invoice revealed a more specific concern: the illustrator could not easily tell which version had been sent, what due date the client had seen or whether a reminder had already gone out. More attractive templates would not resolve those uncertainties.
| Moment | Illustrative account | What to investigate |
|---|---|---|
| First struggle | Several invoice files had similar names. | How the sender identifies the current version. |
| Trigger | A payment became overdue during a busy week. | How outstanding work is noticed and followed up. |
| Evaluation | The person tried sending one invoice before importing clients. | The smallest task that makes a replacement credible. |
| Hesitation | They worried a client would receive duplicate reminders. | Visibility and control over reminder history. |
| First use | They checked the sent invoice and due date before closing the task. | Whether the final state feels sufficiently clear. |
These entries show how to organize an interview, not research findings. In a real study, retain links to the underlying notes and mark your interpretation separately. If the participant remembers the trigger but not its date, record that uncertainty instead of filling the gap with a tidy story.
Use follow-ups that recover detail
“Why did you choose it?” often produces a polished summary. Questions about a scene make it easier to retrieve specifics: “Where were you when you looked at the pricing?” “Who else needed to agree?” “What did you try before giving up on the old process?”
Ask about sequences without implying there was only one reason. “What happened next?” is often better than “Was that when you realized you needed automation?” If an answer contradicts an earlier detail, invite clarification: “Earlier you mentioned trying the new tool before that deadline. How did those events fit together?”
With permission, participants can consult their own calendar or a redacted receipt to help establish timing. Do not request account credentials, insist on opening private messages or copy sensitive material simply to make the timeline more precise.
Turn the explanation into something people can evaluate
After several interviews, compare the situations and repeated tensions rather than counting every mention of a feature. One person asking for reminders and another asking for a status dashboard may be seeking the same practical assurance: knowing whether they need to act.
Use Mockitt to prototype the invoice review flow around that uncertainty. Show a clear due date, a visible sent state and a reminder history, then connect an edit action back to the review screen. These are elements of the example application being designed, not claims that Mockitt itself sends invoices or reminders.
Keep interviews and prototype evaluation separate. In the next session, give a task such as: “A client asks whether the latest invoice is due next Friday. Find the information you would use to reply.” Observe the route they take and what they believe the status means. Do not ask only whether the proposed screen looks useful.
The resulting design hypothesis should name the situation and expected behavior: “When several invoices are in progress, showing the sent version and due date together will help the sender identify the correct invoice before replying.” That is more actionable than “Customers want a better dashboard,” and it can be tested without claiming the interview proved a business outcome.
Keep the story intact when sharing the results
For each participant, retain the previous approach, first struggle, trigger, alternatives, hesitation and first-use experience on one timeline. Then summarize similarities and meaningful differences across participants. A small qualitative sample helps explain decisions; it does not tell you the percentage of the market that will switch.
Connect the resulting insights to your research synthesis with evidence references. Separate what the participant said, what you infer and what you intend to test. Teams can then improve the onboarding, comparison information or actual workflow responsible for the friction, rather than copying a competitor's feature list.