What an agent needs from your design system in Markdown

A structured text version of the portfolio to read, share or use as context in an AI assistant.

_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

**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–30** issues that, once a unique issue was defined properly, turned out to be only 20 to 30.
- **1** person, 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.

### **Solution architecture:** from public sources to the dashboard and Jira, with agents at every step before the decision.

**Sources · Public opinions**
- Sunrise community
- Reddit
- App stores
- X
- Later: calls, surveys, tests and interviews

**Extraction · Agents, every Monday**
- By API or MCP when possible
- By browser when not

**Cleaning and classification · Trained agents**
- Only issues remain
- Business taxonomy
- Faceted ontology
- By hand when it can’t be done

**Repository · Shared database**
- Issues and evidence
- Six facets per issue
- No personal data

**Platform · Web dashboard**
- Product Owner, Business Analyst and UX
- Volume, urgency and trend

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

**Built with:** n8n (workflows) · Supabase (data) · Hostinger (hosting) · Claude Code and Codex (building)

## 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.

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

1. **Extract** (Agent): Every Monday, from every source. By API or MCP, or by browser when there is no other way.
2. **Clean** (Agent): Drops loose opinions and keeps only the real problems.
3. **Define the issue** (Agent): Is it an issue? How many does it describe? A roaming case can be about network, billing and support.
4. **Merge** (Agent): Joins those that are the same problem: from 300 “issues” to 20–30 unique ones.
5. **Classify** (Agent and person): Six facets with the business taxonomy. What can’t be classified is done by hand.
6. **Decide** (Person): The 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.

## 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.

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

**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

**Product Owner**
- Sees issues by volume and urgency
- Decides what gets solved and when
- Creates the Jira ticket from the tool

**Business Analyst**
- Accesses the detail and evidence of each issue
- Decides how it gets solved

**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.

## 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:** 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.

**The six facets** used to classify each issue.
1. **What happens:** The symptom: for example, blocked, can’t continue.
2. **About what:** The product or hardware: for example, a phone model.
3. **Doing what:** The stage of the journey: for example, activation.
4. **Where they tried to solve it:** My Sunrise, the hotline, the chatbot or a shop.
5. **Why it happens:** The root cause, whether it was avoidable and who it is attributed to.
6. **Who fixes it:** Derived by rule, from the topic and the hardware. Never by hand.

### 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:** 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:** in the design, the results of tests, interviews and surveys are matched to each issue.