How to use support ticket verbatims to generate user interview discussion guides

Support tickets are one of the richest sources of unfiltered customer language most teams never fully use. Every day, customers describe their frustrations, confusion, workarounds, and unmet needs in their own words—and those words sit in a help desk queue, waiting to be resolved and archived.

But those verbatims—the exact phrases and descriptions customers use—are more than operational data. They are a direct window into how people experience your product. And they can serve as the foundation for user interview discussion guides that are sharper, more grounded, and more likely to surface insights you can act on.

This article walks through a practical method for turning support ticket verbatims into discussion guides, step by step.

Why support tickets are an underused research input

Most research projects start with assumptions. A product manager has a hypothesis about why users churn, or a designer suspects a workflow is confusing. These assumptions shape the research questions, which shape the discussion guide, which shapes what you hear in interviews.

There is nothing wrong with hypothesis-driven research. But it has a blind spot: you tend to explore what you already suspect rather than what you have not yet considered.

Support tickets flip this dynamic. Customers write support tickets without any awareness of your research agenda. They describe problems in their own terms, using language that reflects their mental models rather than your internal terminology. They surface edge cases, emotional reactions, and workflow contexts that rarely appear in structured surveys or usability tests.

When you mine these verbatims before writing a discussion guide, you start from what customers actually care about—not what you think they care about. This leads to interview questions that are more specific, more relevant, and more likely to surprise you.

What counts as a "verbatim"

A verbatim is the customer's exact language, not a support agent's summary or a ticket category tag. For example:

• Verbatim: "I keep exporting the report but the dates are always wrong, so I have to fix them manually in a spreadsheet before sending to my manager."
• Not a verbatim: Ticket tagged as "export bug" and categorized under "reporting issues."

The difference matters. The verbatim tells you about the user's workflow (exporting, then editing, then sharing with a stakeholder), their emotional state (frustration with repetitive manual work), and their context (they have a manager who depends on these reports). The tag tells you almost nothing useful for interview planning.

Step 1: Define the scope of your research

Before diving into tickets, get clear on the general area you want to explore. You do not need a precise research question yet—that will emerge from the verbatims—but you need boundaries.

Ask yourself:

• What product area or experience are we trying to understand better? For example, onboarding, a specific feature, billing, or collaboration workflows.
• What decisions will this research inform? Knowing whether the output feeds a redesign, a prioritization exercise, or a new feature proposal helps you focus on the right tickets.
• What time frame is relevant? Recent tickets (last 3–6 months) are usually more useful than older ones, since the product may have changed.

This scoping step prevents you from drowning in thousands of tickets. It also ensures the discussion guide you eventually write is connected to a real decision your team needs to make.

Step 2: Pull and organize relevant tickets

Export tickets from your support platform that relate to your defined scope. Most help desk tools let you filter by topic, tag, product area, or keyword. Cast a slightly wider net than you think you need—you can always narrow later.

For each ticket, extract:

• The customer's verbatim language (their initial message and any follow-ups, not the agent's replies)
• Basic context, if available: customer segment, plan type, tenure, or role
• Resolution status: was the issue resolved, and how?

Organize these in a spreadsheet or research repository. If you use a tool like Dovetail, you can import support ticket data and tag it directly, which makes the pattern-finding step much faster.

How many tickets to review

Aim for 50–100 tickets on a given topic. You are not trying to build a statistically representative sample. You are looking for thematic saturation—the point where new tickets stop revealing new types of problems, language, or contexts. For narrowly scoped topics, 20–30 detailed tickets may be enough.

Step 3: Identify themes and recurring language

Read through the verbatims carefully. As you do, mark recurring patterns across three dimensions:

Problems and pain points

What specific issues do customers describe? Look beyond the surface complaint to the underlying problem. A customer who says "I can't find the export button" may actually be struggling with navigation in general, or they may be describing a very specific UI gap.

Group similar problems together. You will likely find 4–8 distinct problem themes in a set of 50–100 tickets.

Language and mental models

Pay attention to the words customers use. Do they call a feature something different from what your team calls it? Do they describe a workflow in a way that does not match how you designed it?

These linguistic clues reveal how customers think about your product—their mental models. Mental model mismatches are some of the most productive areas to explore in interviews because they often explain why people struggle even when the product is technically working correctly.

For example, if multiple customers refer to "folders" when your product uses "projects," that gap is worth exploring. It suggests customers are bringing expectations from other tools and those expectations are not being met.

Emotional intensity

Some tickets are calm and descriptive. Others are frustrated, confused, or urgent. Note the emotional tone alongside the content. Issues that generate strong emotional reactions are often higher-impact than issues that are reported matter-of-factly—even if the factual tickets are more numerous.

Emotional intensity is also a useful signal for interview planning. Questions about emotionally charged topics tend to produce richer, more detailed responses.

Step 4: Translate themes into research questions

Now take your grouped themes and turn each one into an open-ended research question. These are not interview questions yet—they are the questions your research needs to answer.

For example:

Theme from tickets	Research question
Customers repeatedly describe manual workarounds for reporting	How do users currently assemble and share reports, and where does the product fall short of their workflow?
Customers use different terminology than the product UI	What mental models do users bring to this feature area, and where do those models conflict with the product's structure?
Several customers express confusion after a recent update	How did users experience the transition, and what expectations were broken?

Aim for 3–5 research questions. More than that usually means you need to narrow your scope or split the project into multiple studies.

Step 5: Write the discussion guide

A discussion guide is not a script. It is a structured outline that ensures you cover the topics you need to cover while leaving room for the participant to lead you somewhere unexpected.

Structure overview

A solid discussion guide typically follows this structure:

1. Introduction and warm-up (3–5 minutes) — Build rapport. Ask about the participant's role, how they use the product, and general context.
2. Broad exploration (10–15 minutes) — Start with open questions about the relevant workflow or experience area. Do not lead with the specific problems you found in tickets.
3. Focused probes (15–20 minutes) — Dig into the specific themes from your ticket analysis. This is where the verbatims directly shape your questions.
4. Wrap-up (5 minutes) — Ask if there is anything you missed, and thank the participant.

Using verbatims to write focused probes

This is where the ticket analysis pays off. For each research question, write 2–3 interview questions that are informed by the verbatims but do not presuppose the answer.

Bad question (leading): "We've heard from other users that the export feature is frustrating. Do you find it frustrating too?"

Good question (informed but open): "Can you walk me through what happens after you generate a report? What do you do with it next?"

The second question is shaped by the ticket theme (people have trouble with exports and post-generation workflows) but leaves space for the participant to describe their own experience. If exports really are a pain point, the participant will bring it up. If they don't, you have learned something equally valuable.

You can also use specific verbatim language as prompts during the interview—not by reading them aloud, but by listening for similar phrases and following up when they appear.

Example follow-up: "You mentioned you 'clean up' the data before sharing it. Can you tell me more about what that involves?"

Pilot the guide

Before using the discussion guide in real interviews, run through it once with a colleague or a friendly internal stakeholder. This reveals questions that are confusing, sections that run too long, and transitions that feel abrupt. Adjust accordingly.

Keeping the loop alive after interviews

The value of this method does not end when you finish your interviews. The connection between support data and research data works best when it is ongoing.

After your interviews, revisit the support ticket themes. Which ones were confirmed? Which ones turned out to be symptoms of a deeper issue you had not identified? Which ones did participants never mention, suggesting they may affect only a small subset of users?

Feed these findings back to your support and product teams. When support agents understand the deeper context behind common tickets, they can provide better responses and flag emerging issues more effectively.

If you store both your support data and your research data in a platform like Dovetail, this feedback loop becomes easier to maintain. You can tag and connect insights across data sources, making it simpler to spot when a new wave of support tickets maps to a pattern you have already explored in research.

Common mistakes to avoid

Treating ticket volume as a proxy for importance. A problem that generates 200 tickets may matter less than one that generates 10 tickets from your highest-value customers. Consider who is reporting the issue, not just how many people are reporting it.

Copying ticket language directly into interview questions. Verbatims should inform your questions, not become your questions. If you ask "Do you also have trouble when the dates are wrong on exports?" you have turned an interview into a confirmation exercise.

Skipping the theming step. Going straight from raw tickets to a discussion guide usually produces a guide that is a scattered list of complaints rather than a coherent exploration of an experience area. Take the time to group and synthesize.

Using only support tickets. Tickets capture what went wrong. They rarely capture what went right, what users chose not to do, or what users do not know they are missing. Support data is a powerful starting input, but it should complement—not replace—other research methods.

A practical starting point

If this process feels like a lot, start small. Pick one product area your team is actively making decisions about. Pull 30 recent support tickets. Spend an hour reading the verbatims and grouping them into themes. Then write five interview questions based on what you found.

You will almost certainly end up with a more grounded, more specific discussion guide than if you had started from a blank page. And the interviews that follow will produce insights that connect directly to real customer problems—because they started with real customer words.