The Support Loop
The support queue is the cheapest user research you have: real people, describing real problems, unprompted, every day. Build the loop from ticket to change and back to the person who wrote it.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
How does a complaint in the support inbox become a change in the product — and how does the customer find out it did?
The support lead, in the weekly sync: "We get the same where-is-my-order question thirty times a week. Can engineering look at it?"
Support files bugs in the tracker; engineering triages them with everything else. Anything that is not a bug is a feature request and goes to the PM's backlog.
"Where is my order" is not a bug. The order page shows the status correctly; it just says "Processing" for three days, which customers read as "stuck". It goes to the backlog, where it sits under features with a louder sponsor.
- "Where is my order" is not a bug. The order page shows the status correctly; it just says "Processing" for three days, which customers read as "stuck". It goes to the backlog, where it sits under features with a louder sponsor.
- Support stops filing things that are not clearly bugs, because nothing happens to them. The team now has less information than before, and believes the product is healthier than it is.
- The one ticket that does get fixed is fixed without anyone telling support. Agents keep sending the old workaround for months, and the customers who complained never learn it changed.
- Engineering reads tickets only when a bug is escalated, so their picture of users is the angriest one percent — the edge cases — not the steady, boring confusion that costs most support time.
What is really going on
- Support tickets are unprompted user research. Nobody recruited these people or wrote leading questions. They hit a problem hard enough to write about it, in their own words, and they are telling you what they expected to happen (Qualitative Signals).
- The value is in the repetition, not the individual ticket. One confused customer is noise; thirty a week with the same confusion is a product defect that happens to be free of stack traces. You only see the repetition if tickets are tagged consistently and someone counts them.
- A loop has four arcs: ticket to pattern (tagging and counting), pattern to decision (someone with authority looks at it on a schedule), decision to change (it gets built, or it gets an explicit "no"), and change back to people (support and the customer hear about it). Most teams have the first arc and nothing else.
- Closing the loop is what keeps the input flowing. Support files what they believe will be read. A support team that has seen three of its reports turn into changes files the fourth one carefully; one that has seen none stops filing.
- The loop needs a rate, not a count. Thirty "where is my order" tickets during a sale week may be better than twenty in a quiet one. Normalise by orders, sessions or active customers, or you will celebrate a slow month (Picking a Metric That Moves When the Product Gets Better).
Four arcs, and most teams have one
A ticket becoming a change needs four things to happen, each owned by someone. Support tags it. Someone counts tags and brings the top ones to a decision. The decision becomes a change or an explicit no. And the change comes back to support and to the customer who asked.
Most teams have the first arc — there is a helpdesk, it has tags — and none of the others. The tickets are recorded and never read as a set. That is not a loop; it is an archive.
Count it as a rate
The number that makes the support loop legible to everyone else is tickets per thousand orders, by tag, by week. It survives sales spikes, it can sit on the same dashboard as conversion, and it makes a fix visible as a drop that the whole team can see.
1SELECT date_trunc('week', t.created_at) AS week,2 t.tag,3 count(*) AS tickets,4 round(1000.0 * count(*) / nullif(w.orders, 0), 2) AS per_1k_orders5FROM support_tickets t6JOIN (SELECT date_trunc('week', created_at) AS week, count(*) AS orders7 FROM orders GROUP BY 1) w8 ON w.week = date_trunc('week', t.created_at)9WHERE t.area IN ('checkout', 'cart', 'order-page')10GROUP BY 1, 2, w.orders11ORDER BY week DESC, per_1k_orders DESC;The denominator is the point. Without it, the busiest sales week always looks like the worst product week.
Read the words, not the summary
Tags tell you where; the ticket text tells you what the customer thought was happening. "Where is my order" is a tag. "It has said Processing since Monday, is it stuck?" is a mental model — the customer believes Processing means something is wrong. That sentence tells you the fix is a label and a date, not a faster warehouse.
This is why the rotation reads raw tickets. A summary written by someone else has already decided what mattered, and it usually decided the customer's phrasing did not.
You did the ticket rotation. "Where is my order" is the top tag again. You have five minutes in the team meeting.
"Support gets a lot of where-is-my-order tickets. Maybe we should look at the order page at some point?"
"Where-is-my-order is our top tag, 4 per thousand orders, flat for two months. In the twenty I read, twelve said some version of 'is it stuck'. The page says Processing for up to three days. I would like to show the step and an expected dispatch date — about a day. If the tag halves in a month, we keep going; if not, the confusion is somewhere else."
Closing the last arc
When the change ships, three messages go out. Support gets what changed, the new answer to give, and the old workaround to stop giving. The customers who reported it get a reply — support sends it, but engineering gives them the list from the ticket tags. And the team gets the rate a month later, whichever way it went.
The last message is the one that makes the loop self-sustaining. A support team that sees "your thirty tickets a week turned into this change, and the rate halved" files the next pattern better than any process document could make them (Feedback in Both Directions).
v4.12: Improved order status display on order page.
The order page now shows the step (Packing, Handed to courier) and an expected dispatch date instead of "Processing". You can stop sending the "Processing is normal" macro. Could you reply to this month's where-is-my-order tickets letting them know? We will share the tag rate on the 20th.
The release note tells support something changed. The second tells them what to do differently today, what to stop doing, who to reply to, and when they will see whether it worked.
How to do it
Most important first.
- Agree a short tag list with support — ten to twenty tags, owned by product area, not by symptom wording. The tags are the interface between the two teams; change them together.
- Put tickets per thousand orders for your area on the team's own dashboard, next to conversion. Review the top three tags every week, in the same meeting as everything else, for fifteen minutes.
- Have an engineer read raw tickets on a rotation — twenty tickets, once a week, not summaries. The words customers use are the thing summaries lose.
- For each top pattern, record a decision within two weeks: change it, or explicitly do not, with a reason support can pass on (Saying No Well).
- When a change ships, tell support what changed, what to say now, and ask them to reply to the customers who reported it. Then watch the tag rate for a month.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with the rate and the words: "Where-is-my-order tickets are 4 per thousand orders, our largest tag. Customers write 'is it stuck?' — the order page says Processing for up to three days."
- Then what it costs: "That is roughly thirty tickets a week, each a few minutes of an agent and a worried customer. It is also people who might not order again."
- Then the smallest change: "Replace Processing with the actual step and an expected dispatch date. A day of work, no new data, and it answers the question they are asking."
- Then how you will know, and the loop back: "If the tag rate halves in a month, it worked. Support will reply to this month's reporters when it ships."
- "We do not have time to read tickets." You have time to build features whose success you cannot measure. Twenty tickets take half an hour; the last pattern found that way removed thirty tickets a week.
- "Support should just write better bug reports." They write what they see. Asking them to diagnose is asking them to do engineering; asking them to tag consistently is asking them to do their own job slightly differently. Ask for the second.
What can go wrong
- Tag drift: support invents new tags for the same problem, so the pattern splits across four labels and never reaches the top three.
- The rotation becomes reading summaries a PM wrote, and the specific words — "is it stuck?" — are lost.
- Optimising the ticket rate directly: hiding the contact form, adding a chatbot that deflects without answering. The rate drops; the confusion does not (Guardrail Metrics).
- Treating every ticket as a feature request and overloading the backlog. The loop is for patterns; a single loud customer is still one customer.
- The loop works for engineering's area and nobody else's, so the top tag is "payments provider emails" and no team owns it.
- "Support tickets are biased towards angry customers, so they are not representative." They are biased towards people who cared enough to write. That is a feature for finding confusion, and a bug only if you treat them as a satisfaction survey.
- "Fewer tickets means a better product." Fewer tickets per order, with the contact path unchanged, might. Fewer tickets because the form is harder to find means you stopped listening.
- "This is the PM's job." The PM decides priority. The engineer is the one who can see from the ticket wording which state machine confused them, and knows the change is a day, not a sprint.
Knowing whether it worked
- The top ticket tag for your area changes over a quarter because you fixed the old one, not because it was renamed.
- Support files non-bug patterns without being asked, and says so in the sync: "We are seeing a new one on gift cards."
- Tickets per thousand orders for your area trends down while orders trend up.
- A customer who reported something gets a reply that says it changed — and support can point to where that happened this month.
- At a few hundred orders a week, the founder or the engineer reads every ticket and the loop is a conversation. It does not need tags; it needs someone to read.
- At 10x volume, reading everything stops being possible. Tags, rates and a sampling rotation replace it, and the risk shifts from missing tickets to over-trusting the tags.
- With a large support organisation, there is often a dedicated person who aggregates patterns for product. That person is your most valuable colleague outside the team; give them the fifteen minutes every week.
- It takes engineering time every week that produces no code directly: the rotation, the review, the replies. It is easy to cut in a busy sprint, and the loop decays silently when it is.
- It gives the loudest problems a voice and misses the silent ones: customers who hit a wall and leave never write a ticket. The support loop needs funnel data next to it.
- Committing to a decision within two weeks means saying "no" to support in writing, which is harder than leaving it in the backlog.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALAnywhere users can contact someone when confused, the queue carries product signal. It flips for products with no support channel at all, where app-store reviews or sales-call notes play the same role.
- PRODUCT-SPECIFICB2C: volume is high, individual tickets are short, patterns come from counts. B2B: volume is low, each ticket may represent a whole account, and one ticket from a large customer can outweigh a hundred — there the loop runs through account managers, not tags.
- STAGE-SPECIFICEarly on, the engineer reading every ticket is the loop and tags are overhead. Past the point where one person can read the queue in an hour a week, the tag list and the rate become necessary, and the rotation keeps them honest.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.