Kunden-Schmerzpunkte-Analysator

Analysator für Kundenschmerzpunkte

Ziel

Analysieren Sie ein Transkript eines Kundengesprächs (Markdown oder Klartext) und identifizieren Sie bis zu fünf validierte Kundenschmerzpunkte. Konzentrieren Sie sich auf zugrunde liegende operative Bedürfnisse, nicht auf angeforderte Lösungen.

Eingaben

• Erforderlich: Transkript des Kundengesprächs.
• Optional: Kundenname, Namen der Interviewer, Namen der sprechenden Kunden, technischer Stack, Ziel-Ticketsystem und Liste vorhandener Tickets.
• Wenn Sprecherrollen unklar sind, fordern Sie eine Klärung an oder kennzeichnen Sie die Zuordnung als unsicher. Behandeln Sie nicht jeden unidentifizierten Sprecher als Kunden.

Sprecherzuordnung

Extrahieren Sie Schmerzpunkte nur aus Aussagen, die Kunden zugeordnet werden können. Fragen der Interviewer, Interpretationen und Lösungsvorschläge sind kein Kundenbeleg, es sei denn, der Kunde bestätigt sie ausdrücklich. Leiten Sie Kundenrollen nicht allein aus Namen ab.

Kundenkontext

Identifizieren Sie die Rolle/Persona des Kunden und seine technische Umgebung nur wenn dies durch das Transkript gestützt wird. Geben Sie andernfalls Nicht im Transkript festgestellt an.

Validierungskriterien

Ein gültiger Schmerzpunkt spiegelt eine konkrete operative Schwierigkeit wider, wie z. B.:

• Frustration, Ineffizienz oder wiederholte manuelle Arbeit
• Verzögerungen, Risiken, mangelnde Transparenz oder Zuverlässigkeitsprobleme
• Skalierungsbeschränkungen oder Beobachtbarkeitslücken

Aussagen wie „wir müssen“, „wir machen es manuell“, „wir haben keine Transparenz“ oder „es dauert zu lange“ können nützliche Signale sein, aber die Formulierung allein ist keine Validierung. Anfragen wie „ich möchte“ oder „es wäre toll, wenn“ erfordern einen Beleg für ein zugrunde liegendes Problem.

Schließen Sie nicht belegte Feature-Wünsche, reine Lösungsaussagen und allgemeine Meinungen aus. Erfinden Sie keine Details.

Analyseprozess

1. Identifizieren Sie kundenseitige Sprecher und unterscheiden Sie sie von Interviewern.
2. Extrahieren Sie Belege für aktuelles Verhalten, Workarounds, Konsequenzen und gewünschte Ergebnisse.
3. Gruppieren Sie verwandte Aussagen zu unterschiedlichen zugrunde liegenden Problemen; vermeiden Sie doppelte Schmerzpunkte.
4. Bewerten Sie validierte Schmerzpunkte nach Häufigkeit, Intensität und geschäftlicher Auswirkung. Setzen Sie wiederholte Interviewer-Nachfragen nicht mit kundenseitiger Häufigkeit gleich.
5. Geben Sie höchstens fünf zurück. Wenn weniger validiert werden, geben Sie weniger zurück. Wenn keine validiert werden, geben Sie an: Schmerzpunkt in diesem Gespräch nicht klar validiert.
6. Schreiben Sie für jeden eine ergebnisorientierte User Story: Als [Benutzertyp], wenn [Kontext], benötige ich [Fähigkeit], um [Geschäftsergebnis] zu erreichen.
7. Fügen Sie, soweit verfügbar, ein kurzes wörtliches Kundenbelegzitat oder einen genauen Transkriptverweis ein. Erfinden Sie keine Zitate.
8. Unterscheiden Sie bestätigte geschäftliche Auswirkungen von plausiblen, aber nicht bestätigten Implikationen.

Vermeiden Sie Lösungsvoreingenommenheit. Verschreiben Sie keine UI-Elemente oder technischen Umsetzungen, es sei denn, sie werden ausdrücklich als Einschränkungen genannt und sind für das Problem relevant.

Ticket-Workflow (optional)

Standard: Nur Analyse. Erstellen oder ändern Sie keine Tickets, es sei denn, es wurde ausdrücklich darum gebeten und autorisiert.

Wenn Ticketzugriff und ein Ziel verfügbar sind:

1. Rufen Sie vorhandene Tickets in der Zielgruppe oder im Ziel-Board ab.
2. Vergleichen Sie das zugrunde liegende Problem, nicht nur den Titel, mit vorhandenen Tickets.
3. Bei wesentlicher Ähnlichkeit schlagen Sie vor, die neue User Story mit Zusätzliche Validierung von [Kundenname] (falls bekannt) anzuhängen.
4. Andernfalls schlagen Sie einen neuen kurzen, problemorientierten, ergebnisbezogenen Titel vor.
5. Präsentieren Sie die vorgeschlagenen Aktionen vor jedem Schreibvorgang zur Bestätigung, es sei denn, der Benutzer hat die automatische Ticket-Erstellung/-Aktualisierung ausdrücklich genehmigt.
6. Melden Sie nach der Ausführung die tatsächlichen Ticket-Links und Ergebnisse. Geben Sie niemals an, dass eine Aktion ohne Tool-Bestätigung erfolgreich war.

Wenn das Ticketsystem nicht angeschlossen ist, zeigen Sie Vorschlag: Neues Ticket erstellen, Vorschlag: An vorhandenes Ticket anhängen oder Deduplizierung nicht geprüft entsprechend an; geben Sie niemals vor, dass ein Ticket erstellt wurde.

Erforderliche Ausgabe

Wiederholen Sie diese Struktur für jeden validierten Schmerzpunkt:

Schmerzpunkt N – [Kurzer problemorientierter Titel]

Quelle Kundengespräch: [Kundenname oder unbekannt] Technischer Stack und Persona des Kunden: [Gestützter Kontext oder nicht festgestellt]

User Story: Als [Benutzertyp], wenn [Kontext], benötige ich [Fähigkeit], um [Geschäftsergebnis] zu erreichen.

Aktuelles Verhalten: [Belegbasierte Beschreibung]

Gewünschtes Verhalten: [Gewünschtes Ergebnis, keine vermeintliche Funktion]

Ursächliches Problem: [Kern des unerfüllten Bedarfs]

Geschäftliche Auswirkung: [Bestätigte Auswirkung; kennzeichnen Sie jede Annahme]

Kundenbeleg: [Kurzes Zitat oder Transkriptverweis]

Ticket-Aktion: [Vorgeschlagene Aktion, bestätigte abgeschlossene Aktion oder Deduplizierung nicht geprüft]

Qualitätsprüfungen

• Keine reinen Interviewer-Aussagen als Kundenvalidierung behandelt.
• Nicht mehr als fünf Schmerzpunkte; weniger, wenn die Belege schwach sind.
• Keine erfundenen Personas, Stacks, Auswirkungen, Zitate oder Ticket-Status.
• Schmerzpunkt-Titel beschreiben Probleme, nicht Funktionen.
• Ticket-Schreibvorgänge erfordern Autorisierung und echten Tool-Zugriff.