Finexa: vom Kundenfeedback zur Umsetzung mit KI

Die Ausgangslage

Beschwerden über Zahlungsstatus und Disputes steigen seit zwei Quartalen. Das Feedback kommt aus sechs getrennten Kanälen: Interviews, Support-Tickets, Notizen aus Vertrieb und Account-Management, Eskalationen aus dem Betrieb, Jira-Anfragen sowie Feedback von Compliance und Risk. Die Folgen:

• Das Produktteam liest und verdichtet Feedback von Hand, Eintrag für Eintrag.
• Backlog-Einträge lassen sich nicht auf echte Kundenbedürfnisse zurückführen.
• Priorisiert wird nach Anekdoten statt nach vorhandenen Belegen.
• Entwickler bekommen Tickets mit fehlendem Kontext und müssen nacharbeiten.

Die Leitung wollte einen kontrollierten Pilot: weg vom Bauchgefühl, hin zu belegter Planung, ohne die Entscheidungsrechte der Product Manager zu schmälern und ohne Sicherheit und Compliance zu gefährden.

Der Vorschlag

Ein 12-Wochen-Pilot im Bereich Zahlungen als Hybrid Agentic System. Die KI übernimmt nur kognitive Aufgaben. Alles, was Folgen hat, läuft deterministisch und unter menschlicher Kontrolle. BigQuery auf der bestehenden KI-Plattform ist die einzige Datenquelle, und eine Oberfläche in Appsmith ersetzt die Tabellen.

Der Kern: Dieselbe Beschwerde aus einem Interview, einem Support-Ticket und einer CRM-Notiz wird eine priorisierte Chance mit drei Belegen statt drei einzelner Backlog-Einträge.

So läuft es ab

1. Daten bereinigen: Der Google-Dienst Cloud DLP entfernt persönliche Daten und Finanzkennungen, bevor Text das Sprachmodell berührt. Das ist keine KI, sondern fester Code.
2. Zerlegen: Die KI teilt ein Interview oder Ticket in einzelne Probleme, jeweils mit Zusammenfassung, Schmerzpunkten, Ursache und Schlagwörtern wie Schweregrad und Produktbereich. Bei dünnem Material fragt sie nach, statt zu raten.
3. Abgleichen: Eine Vektorsuche findet ähnliche, schon bekannte Themen und schlägt vor, ob es dasselbe Problem oder ein neues ist.
4. Prüfpunkt 1: Ein Product Manager bestätigt Zerlegung, Schlagwörter und Zuordnung.
5. Bewerten: Eine transparente Formel mit einstellbaren Gewichten berechnet den Score aus fünf Größen: Kundenwert (Enterprise oder SMB), Dringlichkeit (schlimmster gemeldeter Schweregrad und Häufigkeit), strategische Passung, operatives Risiko und Compliance-Relevanz. Die KI erklärt den Wert nur, sie rechnet ihn nicht.
6. Prüfpunkt 2: Ein Product Manager entscheidet, welche Chancen jetzt einen Entwurf wert sind.
7. Entwerfen: Die KI schreibt Problembeschreibung, User Story, Akzeptanzkriterien und Begründung mit Belegen.
8. Prüfpunkt 3: Der Entwurf wird gegen die ursprünglichen Belege geprüft und der Aufwand eingeschätzt. Erst dann schickt ein Skript, das als einziges die Jira-Zugangsdaten besitzt, das Ticket an Jira.

Zusätzlich beantwortet ein Analyse-Agent über das Model Context Protocol Fragen in normaler Sprache an die gespeicherten Daten, ohne SQL und ohne CSV-Export, nur lesend. Er zeigt Produkt-, Prozess- und KI-Kennzahlen. Das System erkennt außerdem Rückfälle, also wenn zu einem bereits behobenen Thema nach dem Release weiter Feedback eintrifft.

Vier Entscheidungen bleiben beim Menschen

1. Prüfpunkt 1: Zerlegung und Zuordnung. Er ist der einzige Prüfpunkt, der später zur Stichprobe werden kann, weil es eine überprüfbar richtige Antwort gibt und eine dauerhaft hohe Übereinstimmung das belegen würde.
2. Prüfpunkt 2: Welche Chancen jetzt umgesetzt werden. Das hängt von Kapazität und Timing ab, deshalb gibt es keine Quote, gegen die er je konvergieren könnte. Er bleibt dauerhaft.
3. Prüfpunkt 3: Freigabe des Jira-Entwurfs. Er bleibt ebenfalls dauerhaft.
4. Entscheidung nach Woche 12: weitermachen, anpassen oder stoppen, auf Basis der Messung gegen den Ausgangswert.

Sicherheit durch Aufbau, nicht durch Anweisung

• Kein Jira-Zugang für die KI: Kein Ergebnis kommt ungeprüft bei den Entwicklern an. Das ist eine bauliche Garantie, keine Regel.
• Kein Weg zu Rohdaten: Das Konto der KI kann die Rohdaten nicht lesen. Das Restrisiko sind Reste in Freitext, die DLP übersieht. Dagegen helfen Musterprüfung vor dem Import und laufende Stichproben.
• Nachvollziehbar: Jede Entscheidung ist eine gespeicherte Zeile, Zugriffe protokolliert BigQuery von Haus aus. Der Vorschlag der KI wird neben dem endgültigen Wert gespeichert, daraus lassen sich Abweichungen und Drift messen.
• Betriebsrat: Protokolliert wird die Rolle (zum Beispiel Payment_PM), nicht die Person, damit keine Leistungskontrolle entsteht (§ 87 BetrVG).
• Recht: Verarbeitung in der EU mit festgelegter Aufbewahrungsfrist, Einstufung nach EU AI Act als internes Hilfswerkzeug außerhalb der Hochrisikostufe.
• Einstellbar statt Blackbox: Weil die Gewichte Parameter sind, zeigt eine systematische Abweichung beim Prüfen, welches Gewicht falsch ist und wer es ändern kann.

Fünf Beteiligte, fünf Bedingungen

Die Stakeholder-Map ordnet alle nach Einfluss und Interesse, und das System ist so gebaut, dass jede Bedingung technisch erfüllt wird:

• Head of Product (Sponsor): will schnelle, belegbare Priorisierung für Roadmap-Reviews. Berichte entstehen per Dashboard oder Frage in normaler Sprache.
• Risk & Compliance: kann den Pilot stoppen und verlangt Datenschutz, Nachvollziehbarkeit und menschliche Prüfung.
• Engineering Lead: skeptisch, will unvollständige oder erfundene Tickets aus dem Backlog heraushalten. Dafür gibt es Prüfpunkt 3 und kein KI-Zugriff auf Jira.
• Senior Product Manager: früher Anwender, der die KI als Assistenz will und nicht als Ersatz.
• Support Operations: will sichergehen, dass Eskalationen nicht unter Feature-Wünschen untergehen. Das operative Risiko ist ein eigener Faktor der Formel.

Die RACI-Matrix legt fest, wer wofür verantwortlich ist, wer rechenschaftspflichtig, konsultiert und informiert wird.

Risiken und Gegenmaßnahmen

Das gesamte Risikoregister liegt als interaktiver Risk Hub vor. Die fünf größten Risiken:

1. Datenschutzleck (Schweregrad 20): unvollständiges Schwärzen. Gegenmittel: DLP-Regeln gegen echte Beispieldaten testen und von Compliance freigeben lassen, bevor Livedaten fließen.
2. Blindes Abnicken (16): Prüfende, die aus Ermüdung nur noch bestätigen. Gegenmittel: Pflichtbegründung bei Prüfpunkt 3 und eine zufällige Stichprobe von 20 % mit manueller Aufwandsprüfung.
3. Betriebsrat (15): Prüfprotokolle als Leistungskontrolle. Gegenmittel: Protokoll nur mit Rolle und Freigabe des Betriebsrats.
4. Verzögerte Freigaben (15): Prüfpunkte dauern länger als 48 Stunden. Gegenmittel: automatische Warnung und eine vereinbarte Eskalation.
5. Ausfall der KI-Schnittstelle (15): Gegenmittel: ein manueller Modus, der die KI umgeht.

Vor dem Start müssen vier Entscheidungen fallen: die DLP-Regeln, die Löschrichtlinie nach DSGVO, die Vereinbarung mit dem Betriebsrat und die 48-Stunden-Regel.

Zeitplan und Erfolg

• Woche 1–4 (Grundlage): Freigabe der DLP-Vorlage, Datenbankschema, Ausgangswerte, Befragung der Beteiligten, RACI-Abstimmung, Appsmith, Verarbeitung der vorhandenen Zahlungsdaten.
• Woche 5–10 (Pilot): Tägliches Zahlungsfeedback läuft durch alle Prüfpunkte.
• Woche 11–12 (Bewertung): Messung gegen den Ausgangswert, Vertrauensbefragung, Entscheidung weitermachen, anpassen oder stoppen.

Die Messung kommt zuerst: Der Ausgangswert wird vor dem ersten KI-Schritt erfasst. Gemessen werden fünf Ziele: weniger Zeit für manuelle Auswertung, einheitlichere Dokumentation, Rückverfolgbarkeit vom Kundenhinweis bis zum Jira-Ticket, ein schnellerer Weg vom Feedback zum Backlog und mehr Vertrauen in die Priorisierung. Als Zielwerte gelten mindestens 85 % Übereinstimmung bei den Schlagwörtern, über 80 % Treffer beim Abgleich ähnlicher Themen, über 85 % Annahme bei Prüfpunkt 3 und über 50 % weniger Zeit für den Umgang mit Feedback.

Das Projektportal

Zum Projekt gehört ein interaktiver Prototyp: der Ablauf, die drei Prüfpunkte, die Roadmap, die Stakeholder, der Risk Hub und das Monitoring-Portal mit den Analysen. Prototyp ansehen (auf Englisch)

Ergebnisse des Projekts

Projektbrief, Stakeholder-Map mit RACI-Matrix, Risikoanalyse, Monitoring-Plan, ein Datenmodell mit 11 Tabellen in BigQuery und der interaktive Prototyp. Das Konzept mit der Dokumentation war das Ergebnis. Wir haben es den Stakeholdern vorgestellt, damit sie auf dieser Grundlage entscheiden, ob sie den Pilot umsetzen. Gebaut wurde er nicht. Im THRIVE-Programm gehörte das Konzept zu 20 ausgezeichneten Arbeiten unter 150 Teilnehmenden.