Churn Interview Questions and Switching Script

Users do not switch tools because a feature matrix told them to. They switch because something changed: a workflow got painful, a workaround stopped scaling, a teammate needed proof, or a buyer could not explain the cost.

UserTold helps you capture that decision in the user's own words. The goal is to learn what progress they were trying to make, what they compared you against, and what would make them leave.

The pain this solves

Without source evidence, teams tend to argue from opinion:

  • "People want exports."
  • "Pricing is the blocker."
  • "The dashboard is too research-heavy."
  • "We need more integrations."

Those might be true, but they are not specific enough to ship against. UserTold records the moment behind the request: what triggered it, what the user did instead, what they feared, and what outcome would make the product useful.

When to use it

Use this guide when the product question is about choice:

  • why users try the product in the first place
  • why trial users fail to activate
  • why buyers hesitate before choosing a plan
  • why customers keep a spreadsheet, doc, or internal tool around
  • why a shipped feature does not replace the old workflow
  • what would make a team stop using the product

If you mostly need to watch whether a task works, start with Find Why Users Get Stuck Before They Leave.

Churn interview questions

Anchor the interview on a real recent moment. Avoid broad preference questions.

Use these questions to reconstruct the decision:

  1. When did you last use the product for real work?
  2. What were you trying to accomplish?
  3. What first made you consider another approach?
  4. What alternatives did you try or compare?
  5. What almost kept you with the old approach?
  6. What finally made you leave, stay, or switch?
  7. What do you use now, and what tradeoff did you accept?

Copy the complete switching interview script

This example investigates a team that replaced or considered replacing its shared inbox. The participant may have stayed; the script must not assume a switch happened.

{
  "version": 2,
  "goals": [
    {
      "id": "switch",
      "description": "Understand what led a team to replace or keep its shared inbox."
    }
  ],
  "segments": [
    {
      "id": "decision",
      "mode": "talk",
      "title": "The switching decision",
      "talk": {
        "research_mode": "jtbd_switch",
        "goals": ["switch"],
        "system_prompt": "Reconstruct the last decision to replace the shared inbox. Ask what first made them look, what they tried, what almost stopped the change, and what finally made them choose. If they stayed with the old tool, ask what kept it acceptable. Ask for events in order, one question at a time; do not assume they switched."
      }
    }
  ]
}

Ask your agent to adapt it

Adapt the churn and switching interview at https://usertold.ai/guides/learn-why-users-switch to my product.

Ask what decision we need to understand, which customers recently left or considered leaving, and what they use now. Preserve the chronological decision structure and do not assume the participant switched. Show the complete Study JSON and wait for approval before saving or activating anything.

Better questions

Ask for the story, not the wishlist.

Instead ofAsk
"What features do you want?""What were you trying to get done the last time this came up?"
"Would you use an export?""What did you do with the information after you found it?"
"Is pricing clear?""Where did you hesitate before choosing a plan?"
"What integrations matter?""What tool did you need this to connect to before it became useful?"
"Do you like the dashboard?""Who else needed to understand the result?"

These questions produce evidence about the work the user was doing, not just another feature request.

Why the method works

People use a product to make progress in a real situation. UserTold turns that into usable evidence by preserving decision moments as quotes and source links.

The fuller basis is in Methodology; in practice, capture the trigger, the workaround, the hesitation, and the outcome the user needed.

What good evidence looks like

A team lead needs to share research with engineers.

Vague Finding:

Users want export.

Finding to verify against the sources:

A team lead copied evidence into a spreadsheet because engineers did not use the dashboard. They said, "I need something I can drop into our planning doc."

Check whether the source moments support the same problem: the handoff format does not fit the team’s workflow.

Review the Finding before choosing a solution

In this example, inspect the original quote and workflow, compare other relevant interviews, and check whether an existing integration meets the need. A shareable view is one possible solution to investigate.

Keep the Finding focused on the problem. Mark it reviewed after checking the sources, then decide whether to send it to Linear or GitHub, run another Study, or defer it.

Next step

Use this guide before changing positioning, onboarding, pricing, handoff, or retention flows. Browse the other User Interview Script Templates, or use From Interviews to Linear and GitHub Issues after reviewing the evidence.

Try this with your own users

Copy the prompt and paste it into your AI assistant.

View prompt
Help me apply this research approach to my product and set up a suitable interview in UserTold.

Read this guide first: https://usertold.ai/guides/learn-why-users-switch

Use my existing UserTold connection. If it is not connected, help me connect through https://mcp.usertold.ai/mcp and complete browser authorization. Ask for missing project details, use the available UserTold tools, and walk me through any steps that need the dashboard.