Was ein KI-Agent von Ihrem Designsystem braucht als Markdown

Das Portfolio als strukturierter Text zum Lesen, Teilen oder als Kontext für einen KI-Assistenten.

_ANGEWANDTE KI · VOICE OF CUSTOMER_

# Von 25.000 Kommentaren zum Backlog

Ein Pilot, der die öffentlichen Meinungen von Kunden in klassifizierte Probleme verwandelt, damit Product Owner ihre Roadmap mit echten Daten und nicht nach Bauchgefühl entscheiden.

**Rolle:** Alleiniger Autor: Product Owner, UX-Designer, Frontend und Backend, vom Konzept bis zur Produktion

**Status:** Pilot, vom Produktteam der App getestet, wegen einer internen Reorganisation pausiert

**Zeitraum:** September bis November 2026

**Stack:** Claude Code, Codex, n8n, Supabase, Hostinger, Notion und Figma

**Zweite Design-Iteration** mit Beispieldaten. Die Screenshots in diesem Fall stammen aus diesem Design.

## Einsatz und Ergebnisse

- **25.000+** Kommentare (Belege) der letzten zwei Jahre, zu 136 Issues gruppiert.
- **300 → 20–30** Issues, die sich, sobald ein einzelnes Issue sauber definiert war, als nur 20 bis 30 herausstellten.
- **1** Person, von Anfang bis Ende: Produkt, Design, Frontend und Backend, in etwa drei Monaten.

## Warum ich es begonnen habe

Zuvor wurde das Kundenfeedback gar nicht verwaltet: Es wurde in keiner Weise bearbeitet und erreichte die Produktteams nicht. Das war das Problem und der Ursprung von allem. Zuerst mussten die Product Owner jede Woche Informationen über Probleme, Beschwerden und Meinungen echter Nutzer erhalten, die sich in planbare Maßnahmen für die Teams von My Sunrise, der App, Rewards, Roaming oder dem eShop übersetzen lassen.

Ohne messbare Daten wurde das Produkt nach dem Bauchgefühl der Product Owner gebaut. Ich hatte zwei Hypothesen. Erstens: Ein Produktdesigner kann etwas Funktionsfähiges von Anfang bis Ende schaffen, und Teams können mit kleinem Budget ihre eigenen Spezialwerkzeuge bauen. Zweitens: Es sollte wirklich nützlich sein und es erlauben, Produkt-Backlogs auf der Wirklichkeit statt auf Intuition aufzubauen.

## Was ich gebaut habe

Voice of Customer ist das Werkzeug, das die aktiven Probleme der Nutzer zeigt, damit man Entscheidungen treffen und die Roadmap planen kann. Ich habe es allein gebaut, von Anfang bis Ende, und in Produktion gebracht, auf Hostinger mit Supabase. Die Daten sind öffentliche Meinungen, denn es ging darum, die Machbarkeit der Idee zu prüfen: die Sunrise-Community, Reddit, die App-Stores und X. Es erfasst keine Namen oder persönlichen Daten: nur die Issues.

### **Architektur der Lösung:** von den öffentlichen Quellen zum Dashboard und zu Jira, mit Agenten in jedem Schritt vor der Entscheidung.

**Quellen · Öffentliche Meinungen**
- Sunrise-Community
- Reddit
- App-Stores
- X
- Später: Anrufe, Umfragen, Tests und Interviews

**Extraktion · Agenten, jeden Montag**
- Per API oder MCP, wenn möglich
- Per Browser, wenn nicht

**Bereinigung und Klassifizierung · Trainierte Agenten**
- Nur Issues bleiben übrig
- Geschäftstaxonomie
- Facettenontologie
- Von Hand, wenn es nicht geht

**Repository · Gemeinsame Datenbank**
- Issues und Belege
- Sechs Facetten pro Issue
- Keine persönlichen Daten

**Plattform · Web-Dashboard**
- Product Owner, Business Analyst und UX
- Volumen, Dringlichkeit und Trend

**Jira:** Tickets werden im Werkzeug erstellt und verbunden verfolgt.

**Gebaut mit:** n8n (Abläufe) · Supabase (Daten) · Hostinger (Hosting) · Claude Code und Codex (Entwicklung)

## Der Prozess, jede Woche

Der Schlüssel des Prozesses: Er wiederholt sich jeden Montag von selbst, und jeder Schritt hat einen klaren Verantwortlichen. Die Agenten bereiten vor, die Menschen entscheiden.

### **Der Wochenzyklus.** Die ersten fünf Schritte erledigen trainierte Agenten; der letzte gehört immer einer Person.

1. **Extrahieren** (Agent): Jeden Montag, aus jeder Quelle. Per API oder MCP, oder per Browser, wenn es keinen anderen Weg gibt.
2. **Bereinigen** (Agent): Verwirft lose Meinungen und behält nur die echten Probleme.
3. **Issue definieren** (Agent): Ist es ein Issue? Wie viele beschreibt es? Ein Roaming-Fall kann Netz, Abrechnung und Support betreffen.
4. **Zusammenführen** (Agent): Verbindet das, was dasselbe Problem ist: von 300 „Issues“ zu 20–30 einzigartigen.
5. **Klassifizieren** (Agent und Person): Sechs Facetten mit der Geschäftstaxonomie. Was sich nicht klassifizieren lässt, geschieht von Hand.
6. **Entscheiden** (Person): Das Dashboard sortiert nach Volumen und Dringlichkeit. Der Product Owner entscheidet und kann das Jira-Ticket erstellen.

Ein Issue ohne Signal über ein bis zwei Monate wechselt zu „kein Signal“: Vielleicht ist es nicht mehr aktiv. Was älter als zwei Jahre ist, wird verworfen, weil es bereits gelöst ist.

## Wer es nutzt und wofür

Sobald die Issues bereinigt und sortiert sind, werden sie auf die Plattform hochgeladen. Dort greifen Product Owner, Business Analyst und UX-Designer auf die Informationen zu jedem einzelnen zu, geordnet nach Volumen und Anzahl. Der Product Owner muss nichts weiter tun als entscheiden.

### **Rollen und Aufgaben.** Der Agent bereitet die Informationen vor; jede Rolle entscheidet über einen anderen Teil der Arbeit.

**KI-Agenten**
- Extrahieren das Feedback jeden Montag
- Bereinigen das Rauschen
- Definieren und führen Issues zusammen
- Klassifizieren sie mit der Taxonomie
- Entscheiden nicht, was gelöst wird

**Product Owner**
- Sieht Issues nach Volumen und Dringlichkeit
- Entscheidet, was wann gelöst wird
- Erstellt das Jira-Ticket im Werkzeug

**Business Analyst**
- Greift auf Detail und Belege jedes Issues zu
- Entscheidet, wie es gelöst wird

**UX Designer**
- Liest die Worte der Nutzer
- Gestaltet mit Informationen aus erster Hand

**Jira.** Tickets werden im Werkzeug selbst erstellt und verbunden verfolgt.

## Zentrale Entscheidungen

### Entscheidung 01 · Zuerst definieren, was ein Issue ist

- **Ausgangslage:** Kommentare mischen lose Meinungen mit echten Problemen, und eine Nachricht kann mehrere beschreiben. Im ersten Test zählte das System als verschieden, was dasselbe war: Aus 300 offenen Issues wurden 20 oder 30 einzigartige.
- **Alternativen:** Jeden Kommentar so klassifizieren, wie er ist, oder das Modell allein entscheiden lassen, was ein Problem ist.
- **Entscheidung und Begründung:** Definieren, was ein Issue ist, und die Agenten von Hand und mit mehr als 300 Fällen trainieren, damit sie entscheiden, ob eine Nachricht eines ist, wie viele sie beschreibt und wann zwei dasselbe sind.
- **Wirkung:** Von 300 Issues zu 20–30 einzigartigen, und Meinungen ohne echtes Problem fallen heraus.

**Issue-Detail:** die Beschreibung, die Belege dahinter und verwandte Issues.

### Entscheidung 02 · Eine Geschäftstaxonomie und eine Facettenontologie

- **Ausgangslage:** Ein Issue lässt sich aus vielen Blickwinkeln betrachten: wo es entsteht, warum, wer es lösen muss, wann. Eine flache Liste von Tags dient so unterschiedlichen Teams wie My Sunrise, App, Rewards, Roaming oder eShop nicht.
- **Alternativen:** Freie Tags oder ein einziger Kategorienbaum.
- **Entscheidung und Begründung:** Die Geschäftstaxonomie abbilden und jedes Issue mit einer Ontologie aus sechs Facetten klassifizieren. Die letzte, wer es behebt, wird per Regel abgeleitet und nie von Hand klassifiziert.
- **Wirkung:** Jedes Team sieht das Seine, und einen Verantwortlichen für ein Thema zu wechseln, erfordert kein Umetikettieren. Was der Agent nicht klassifizieren kann, wird von Hand korrigiert.

**Die sechs Facetten,** mit denen jedes Issue klassifiziert wird.
1. **Was passiert:** Das Symptom: zum Beispiel blockiert, kann nicht fortfahren.
2. **Worum es geht:** Das Produkt oder die Hardware: zum Beispiel ein Handymodell.
3. **Bei welcher Tätigkeit:** Die Phase der Reise: zum Beispiel die Aktivierung.
4. **Wo man es zu lösen versuchte:** My Sunrise, Hotline, Chatbot oder Shop.
5. **Warum es passiert:** Die Grundursache, ob vermeidbar und wem sie zugeordnet wird.
6. **Wer es behebt:** Per Regel aus Thema und Hardware abgeleitet. Nie von Hand.

### Entscheidung 03 · Der Agent bereinigt und klassifiziert; der Mensch entscheidet

- **Ausgangslage:** Product Owner entschieden nach Bauchgefühl, ohne echte und messbare Daten, und das Feedback erreichte sie nicht. Mit KI ist die Versuchung, sie auch entscheiden zu lassen.
- **Alternativen:** Den Agenten auch priorisieren und entscheiden lassen, was getan wird.
- **Entscheidung und Begründung:** Der Agent bereinigt und klassifiziert nur; alles prüfen trainierte Agenten mit Geschäftskontext und einer eigenen Taxonomie. Der Product Owner entscheidet und plant. Was die KI formuliert, erscheint als ungeprüft markiert, bis jemand es annimmt, bearbeitet oder verwirft.
- **Wirkung:** Der Product Owner entscheidet mit echten Informationen, plant nach Volumen und Dringlichkeit und erstellt das Ticket, ohne das Werkzeug zu verlassen.

**Empfehlungen:** Der von der KI formulierte Vorschlag ist als ungeprüft markiert, mit den Optionen annehmen, bearbeiten oder verwerfen.

## Wie ich es getestet habe

Das Produktteam der App hat es getestet, mit sehr positivem Feedback, vor allem weil es aus echten Bedürfnissen entsteht und nicht aus Geschäftsentscheidungen, die sich manchmal nicht belegen lassen. Der erste Test verlief schlecht: Die Klassifizierung scheiterte in 95 % der Fälle. Die Taxonomie musste überarbeitet und die Agenten trainiert werden, von Hand und mit mehr als 300 Issues, damit sie verstanden, was ein Issue wirklich ist, und es richtig klassifizierten, und damit sie wussten, was ein einzigartiges Issue ist. Nach dieser Arbeit wird alles mit trainierten Agenten geprüft.

## Was funktioniert hat und was nicht

- **Hat funktioniert:** die Klassifizierung, nachdem die Agenten trainiert und die Taxonomie verfeinert waren. Am schwierigsten war es, das Klassifizierungsmodell und die Priorisierung zu schärfen.
- **Hat funktioniert:** die Hypothese. Ein Produktdesigner kann mit kleinem Budget etwas Funktionsfähiges von Anfang bis Ende schaffen, und das Ergebnis ist nützlich, um Backlogs mit echten Daten aufzubauen.
- **Noch offen:** Das Projekt ist wegen einer internen Reorganisation pausiert und über den Pilot nicht hinausgekommen.

## Wie es weitergeht

Die Idee war, Daten aus Anrufen einzubinden, die das größte Volumen erzeugen. Dafür müsste man vom Pilot zu einem echten Projekt wechseln und die Anrufe transkribieren, um sie zu analysieren. Außerdem wollte ich Feedback aus der Forschung hinzufügen: Fragebögen, Nutzertests und Interviews, die eine weitere Feedbackquelle sind.

**Studien:** Im Design werden die Ergebnisse von Tests, Interviews und Umfragen mit jedem Issue verknüpft.