Support Tickets Are the Cheapest Persona Research You Already Own
Interviews recruit the customers willing to talk. Support tickets include everyone, including the furious, the confused, and the silent majority whose pattern only shows up at volume.
Support tickets are research somebody already paid for. They show the problems customers hit, in the words customers use, attached to real orders and real deadlines. The method is to code a few hundred tickets by the job behind the contact, count how often each theme appears, and build personas from the themes that survive. A few hundred coded tickets usually reveal the major themes for a mid-size store, and new batches stop producing new themes once you have reached saturation. Strip personal details before you start, and re-run the coding quarterly, because ticket themes drift with seasons, products, and shipping partners.
Why tickets beat interviews for raw material
Interviews recruit the customers willing to talk, and the willing are rarely typical. They are the engaged, the articulate, and the ones with time, which means the personas built from them skew toward the best customers and miss the ones who never answer a survey. Tickets include everyone. The furious customer, the confused customer, the customer who writes at 11 pm because an order is late for a birthday, and the silent majority whose pattern only appears when you read a hundred tickets together. Each ticket is attached to an order, a deadline, or a problem that mattered enough to write in about, which gives it stakes an interview answer does not have.
Tickets also carry the language. A persona written in the words customers actually use will sound right in copy, because it was built from copy customers wrote. The phrases repeat across tickets: the same complaint about sizing, the same confusion about delivery dates, the same request phrased three different ways. Those phrases should appear verbatim in the persona and in the copy written from it. Interviews give you the story of the last purchase, told in sequence, which is valuable. Tickets give you the vocabulary and the volume, which is what makes a persona usable.
Related reading on this site: PersonaRail and Persona Interviews With Lost Deals: What the Buyer Who Said No Tells You cover the neighbouring problems in more depth.
Code by the job, not by the story
The work is coding, and the unit is the job behind the contact. A ticket is not a story about a late delivery. It is a job: tracking a gift, changing an address, sizing a replacement, expediting for an event. Code each ticket by that job, count the frequency of each theme by customer type and season, and note the phrasing customers repeat. A few hundred coded tickets usually reveal the major themes for a mid-size store, and the rule for stopping is saturation: code in batches, and stop when new batches stop producing new themes. That is the point where the inbox has told you what it knows.
Leave personal details out completely. Names, addresses, and order specifics never belong in persona documents, so work from aggregated, anonymized summaries, and set access rules before the project starts, not after someone pastes a raw ticket into a deck. The bias to watch is negativity: nobody files a ticket to say things went fine, so use tickets for pain points and vocabulary, not for estimating how happy the average customer is. A persona built only from tickets will be a persona of problems, which is why tickets are one source among several, not the whole research program.
What the themes turn into
Ticket data tends to produce sharper personas than interview projects, because the themes are tied to behavior, not to self-description. The deadline buyer, whose whole journey is organized around a date. The replenisher, who wants zero novelty and punishes any friction in reordering. The gift buyer in a panic, whose first contact with the store is a problem, not a purchase. Each one earns its place by changing a decision: the deadline buyer changes how delivery dates are shown, the replenisher changes how reordering works, and the gift buyer changes what the checkout asks for.
The work does not end when the personas are written. Tag new tickets with the persona themes you built, and the tag rates become a live dashboard: a rising share of sizing-confusion tickets is a product page problem announcing itself weeks before returns data confirms it. Re-run the coding quarterly on a fresh sample and compare theme shares, and retire personas that no longer match the inbox, with the date they were last validated printed on the document. A persona with no validation date is a guess with a nice layout, and the inbox will prove it wrong within a quarter.
Frequently asked questions
Can support tickets really replace customer interviews?
No, and they should not. Tickets are best for friction and vocabulary, because they show problems in the customer's own words at volume. Interviews are best for motivation and the story of the last purchase. Use both, and let each do what it is good at.
How many tickets do I need to code for personas?
A few hundred coded tickets usually reveal the major themes for a mid-size store. Code in batches and stop when new batches stop producing new themes, which researchers call saturation.
What should I extract from tickets, and what should I leave alone?
Extract themes, not stories: code by the job behind the contact, count theme frequency by customer type and season, and note repeated phrasing. Leave personal details out completely, and work from aggregated, anonymized summaries.
How often should I refresh personas built from tickets?
Re-run the coding quarterly on a fresh sample and compare theme shares. Ticket themes drift with seasons, product changes, and shipping partners, and personas that no longer match the inbox should be retired with the date they were last validated printed on the document.