A support team answers the same question about one particular step several times a day. They have answered it for eleven months.
Everybody on the team knows the step is confusing. Nobody has told the product team in a form anybody could act on, because it arrives as individual tickets and there is no route that turns eleven months of tickets into a request.
The fix turns out to be a change to one label. It takes an afternoon once somebody knows, and it removes a question that was asked several thousand times.
Step 1: categorise tickets by cause rather than by topic
Confusing step, missing feature, genuine fault or user error, which is what makes a pattern visible.
Step 2: count them
Monthly, by category, so a recurring problem appears as a number rather than as a feeling among the people answering it.
Step 3: convert the top item into a specific request
Not this is confusing, but this label produces this question this many times a month, which is actionable.
Step 4: attach the customer's own words
Three verbatim quotes, which are considerably more persuasive internally than any summary.
Step 5: state the cost in support time
Volume multiplied by handling time, which turns a product request into a business case.
Step 6: establish a route to the product team
A named person and a regular slot, since informal routes depend on relationships and disappear when somebody leaves.
Step 7: report back to the support team
What happened to their feedback, since a team whose reports disappear stops making them within two months.
Step 8: separate the faults from the design problems
Both matter and they go to different places at different speeds, and combining them means neither is handled properly.
Step 9: track the effect after a change
Whether the ticket volume on that topic fell, which is the cleanest measurement available and closes the loop.
Step 10: collect the feature requests systematically
With counts, since the loudest customer is not the most common request and support knows the difference.
Step 11: use the unanswered questions as input too
Which is the record described in product question volume that never reaches you.
Step 12: address the pre sales questions separately
Since those indicate a marketing gap rather than a product one, as in how to answer product questions before they reach support.
Step 13: keep the reporting short
One page, monthly, three items. A longer report is not read and does not produce changes.
Step 14: let support propose the wording rather than the fix
They know exactly what customers misread, and a suggested label or message from the people who answer the resulting questions is frequently better than what a product team would write alone.
Keep the raw tickets available
A product manager who wants to read the underlying conversations should be able to, since an aggregate number persuades and the actual customer words are what produce the fix.
Step 15: let the record assemble itself
An assistant answering the repetitive questions produces a categorised record of exactly what customers ask and what could not be answered, which is the aggregated product feedback that support teams currently have to assemble by hand and usually do not. Set it up through install the widget and train your bot. The backlog effect is described in queue backlogs that never actually clear, and the cover question in weekend and holiday cover questions. The sector view sits under small business.