baguelus.
Back to the overview
APPLIED AI · VOICE OF CUSTOMER

From 25,000 comments to a backlog

A pilot that turns customers’ public opinions into classified problems, so Product Owners can decide their roadmap with real data and not by intuition.

Role
Sole author: Product Owner, UX designer, front-end and back-end, from concept to production
Status
Pilot tested by the app product team, paused because of an internal reorganisation
Period
September to November 2026
Stack
Claude Code, Codex, n8n, Supabase, Hostinger, Notion and Figma
Voice of Customer dashboard with 136 open issues, 25,654 pieces of evidence, trends and a list of issues with volume, signal and status
Second design iteration, with sample data. The screenshots in this case are from this design.

Use and results

  • 25,000+comments (evidence) from the last two years, grouped into 136 issues.
  • 300 → 20–30issues that, once a unique issue was defined properly, turned out to be only 20 to 30.
  • 1person, from start to finish: product, design, front-end and back-end, in about three months.

Why I started it

Before, customer feedback wasn’t managed at all: it wasn’t handled in any way and never reached the product teams. That was the problem and the origin of everything. The first thing was for Product Owners to receive, every week, information on problems, complaints and opinions from real users, that could be turned into actions the teams of My Sunrise, the app, Rewards, roaming or the eShop could plan.

Without measurable data, product was being built on the Product Owners’ intuition. I had two hypotheses. The first, that a product designer can create something functional from start to finish, and that teams can build their own specialised tools on a small budget. The second, that it would really be useful: that it would let teams build product backlogs on reality and not on intuition.

What I built

Voice of Customer is the tool that shows the active problems of users, so you can make decisions and plan your roadmap. I built it on my own, from start to finish, and put it into production on Hostinger with Supabase. The data is public opinion, because the aim was to test the viability of the idea: the Sunrise community, Reddit, the app stores and X. It collects no names or personal data: only the issues.

  1. SourcesPublic opinions
    • Sunrise community
    • Reddit
    • App stores
    • X
  2. ExtractionAgents, every Monday
    • By API or MCP when possible
    • By browser when not
  3. Cleaning and classificationTrained agents
    • Only issues remain
    • Business taxonomy
    • Faceted ontology
    • By hand when it can’t be done
  4. RepositoryShared database
    • Issues and evidence
    • Six facets per issue
    • No personal data
  5. PlatformWeb dashboard
    • Product Owner, Business Analyst and UX
    • Volume, urgency and trend
    JiraTickets are created from the tool and followed up in a connected way.
Built withn8n · workflowsSupabase · dataHostinger · hostingClaude Code and Codex · building
Solution architecture: from public sources to the dashboard and Jira, with agents at every step before the decision.

The process, every week

The key to the process is that it repeats by itself every Monday and every step has a clear owner: agents prepare, people decide.

  1. ExtractAgentEvery Monday, from every source. By API or MCP, or by browser when there is no other way.
  2. CleanAgentDrops loose opinions and keeps only the real problems.
  3. Define the issueAgentIs it an issue? How many does it describe? A roaming case can be about network, billing and support.
  4. MergeAgentJoins those that are the same problem: from 300 “issues” to 20–30 unique ones.
  5. ClassifyAgent and personSix facets with the business taxonomy. What can’t be classified is done by hand.
  6. DecidePersonThe dashboard sorts by volume and urgency. The Product Owner decides and can create the Jira ticket.

An issue with no signal for one or two months moves to “no signal”: it may no longer be active. Anything older than two years is discarded, because it is already resolved.

The weekly cycle. The first five steps are done by trained agents; the last one is always a person’s.

Who uses it and for what

Once cleaned and sorted, the issues are uploaded to the platform, where the Product Owner, the Business Analyst and the UX designer access the information for each one, organised by volume and quantity. The Product Owner doesn’t have to do anything except decide.

  1. AI agents
    • Extract the feedback every Monday
    • Clean the noise
    • Define and merge the issues
    • Classify them with the taxonomy
    • Don’t decide what gets solved
  2. Product Owner
    • Sees issues by volume and urgency
    • Decides what gets solved and when
    • Creates the Jira ticket from the tool
  3. Business Analyst
    • Accesses the detail and evidence of each issue
    • Decides how it gets solved
  4. UX Designer
    • Reads the users’ own words
    • Designs from first-hand information

Jira. Tickets are created from the tool itself and followed up in a connected way.

Roles and tasks. The agent prepares the information; each role decides on a different part of the work.

Key decisions

Decision 01

Define what an issue is first

Situation
Comments mix loose opinions with real problems, and one message can describe several. In the first test the system counted as different those that were the same: 300 open issues became 20 or 30 unique ones.
Alternatives
Classify each comment as it is, or let the model decide on its own what a problem is.
Decision and why
Define what an issue is and train the agents, by hand and with more than 300 cases, to decide whether a message is one, how many it describes and when two are the same.
Effect
From 300 issues to 20–30 unique ones, and opinions without a real problem are out.
Issue detail in Voice of Customer: title, description, six classification cards, evidence and related issues
Issue detail: the description, the evidence behind it and related issues.
Decision 02

A business taxonomy and a faceted ontology

Situation
An issue can be seen from many points of view: where it is generated, why, who must fix it, when. A flat list of tags doesn’t serve teams as different as My Sunrise, the app, Rewards, roaming or the eShop.
Alternatives
Free tags, or a single category tree.
Decision and why
Map the business taxonomy and classify each issue with a six-facet ontology. The last one, who fixes it, is derived by rule and never classified by hand.
Effect
Each team sees its own, and changing who owns a topic doesn’t mean relabelling anything. What the agent can’t classify is corrected by hand.
  1. 01What happensThe symptom: for example, blocked, can’t continue.
  2. 02About whatThe product or hardware: for example, a phone model.
  3. 03Doing whatThe stage of the journey: for example, activation.
  4. 04Where they tried to solve itMy Sunrise, the hotline, the chatbot or a shop.
  5. 05Why it happensThe root cause, whether it was avoidable and who it is attributed to.
  6. 06Who fixes itDerived by rule, from the topic and the hardware. Never by hand.
The six facets used to classify each issue.
Decision 03

The agent cleans and classifies; the person decides

Situation
Product Owners decided by intuition, without real and measurable data, and the feedback never reached them. With AI the temptation is to let it decide too.
Alternatives
Let the agent also prioritise and decide what to do.
Decision and why
The agent only cleans and classifies; everything is reviewed by trained agents, with business context and a specific taxonomy. The Product Owner decides and plans. What the AI drafts appears marked as unreviewed until someone accepts, edits or discards it.
Effect
The Product Owner decides with real information, plans by volume and urgency and creates the ticket without leaving the tool.
Recommendations tab of an issue: one recommendation based on a study and another drafted by AI, marked as unreviewed
Recommendations: the proposal drafted by AI is marked as unreviewed, with the options accept, edit or discard.

How I tested it

The app product team tested it, with very positive feedback, above all because it is built from real needs and not from business decisions that sometimes can’t be demonstrated. The first test went badly: classification failed 95% of the time. The taxonomy had to be worked on and the agents trained, by hand and with more than 300 issues, so that they understood what an issue really is and classified it properly, and so that they knew what a unique issue is. After that work, everything is reviewed with trained agents.

What worked and what did not

  • Worked: the classification, once the agents were trained and the taxonomy refined. The hardest part was polishing the classification model and the prioritisation.
  • Worked: the hypothesis. A product designer can create something functional from start to finish, on a small budget, and the result is useful for building backlogs with real data.
  • Still unresolved: the project is paused because of an internal reorganisation, so it hasn’t moved beyond a pilot.

What comes next

The idea was to bring in data from calls, which generate the most volume. That would mean moving from a pilot to a real project and transcribing the calls to analyse them. I also wanted to add feedback from research: questionnaires, user tests and interviews, which are another source of feedback.

Studies tab of an issue, with a related usability test, interviews and a survey
Studies: in the design, the results of tests, interviews and surveys are matched to each issue.