The support queue is the best research you are not reading
Every product team I work with wants more research and has less budget for it than they would like. Almost all of them are sitting on a corpus of unprompted, timestamped, real-stakes user feedback that they treat as an operational cost rather than a research asset.
It is the support queue. Nobody in a support ticket is being polite to a researcher, performing for a moderator, or speculating about what they might do in a hypothetical situation. They hit a wall, in the middle of real work, and cared enough to write it down.
Reading twelve hundred of them changed a product I worked on more than any round of interviews I have run.
The objection I hear first is that support tickets are unrepresentative. Only frustrated people write in, so the sample is skewed toward the angry and the extreme. That is true, and it matters far less than it sounds.
You are not using the queue to estimate how many users feel a given way. You are using it to discover which walls exist and what shape they are. For that question, the frustrated user is the ideal informant, because they have done something no research participant will ever do for you: they hit the problem while it actually mattered to them, and then they described it in their own unprompted words.
Tag by underlying question, not stated request
This is the whole technique, and it is where most attempts go wrong. Support teams categorise tickets by resolution, because that is what makes their queue tractable. Those categories are close to useless for design. A tag like account settings tells you where somebody was standing, not what they were trying to do.
So retag from scratch. For each ticket, write down the question the person was actually trying to answer, in the form they would have asked a colleague. Not requesting export feature but how many of my parcels were late last week. Do a hundred and the clusters appear on their own.
On a logistics analytics product I did exactly this across twelve hundred conversations. Five questions accounted for 78% of them. The product had forty-one charts and answered none of those five directly. Every one required combining two or three views and doing arithmetic in your head. That finding was worth more than a quarter of interviews, and it was already sitting in Zendesk.
Read the ones that were resolved happily
The tickets that end in thanks, that worked are the most instructive and the least read. They are cases where a human being explained something in one sentence that the interface had failed to explain across an entire screen.
When a support agent unblocks somebody by saying you need to pick a delivery window before it will let you pay, that sentence is a specification. It is the thing the interface should have said, phrased in words a real customer already understood. I have lifted support agent phrasing directly into production copy more than once, and it consistently outperforms what I would have written.
Bring the support lead into the room
The person who reads that queue every day has a better working model of your product's failure modes than anyone in the design team. They usually have no route to influence the roadmap, and they have often stopped trying.
Invite them to the readout. Ask them which of your findings feel wrong. On the analytics project, the support lead corrected two of my five clusters in about ninety seconds, because she recognised the ones that were really the same question asked by two different customer sizes.
A support queue is a year of unmoderated research that somebody already paid for. The only cost left is the reading.
What it does not replace
Ticket analysis tells you where the walls are. It cannot tell you what people were trying to accomplish before they arrived, what they did next, or what they would have preferred instead. It is silent on everyone who hit a wall and quietly left, which on most products is the larger group.
So it is not a substitute for talking to people. It is the thing you do first, so that when you do talk to people you are asking sharp questions instead of open ones. I now start almost every engagement in the support queue, before the kickoff meeting if I can get access, and I have never once regretted the two days it costs.
- Export six to twelve months of tickets and strip them to timestamp, plan or account size, and body text
- Retag a random hundred by underlying question, in the customer's own words
- Let the clusters emerge, then tag the rest against them and note anything that does not fit
- Sort clusters by volume and by how badly the product currently answers them
- Take the top five into your next round of interviews as sharpened questions