Untersuchungen im Support sind im Kern Rechercheaufgaben. Deshalb war der langsamste Teil bei der Bearbeitung von Kundenproblemen schon immer das Zusammentragen des richtigen Kontexts. Indem wir Code, Logs, Teamwissen und frühere Unterhaltungen in einer einzigen Cursor-Sitzung bündeln, haben wir diesen Engpass für den Großteil unserer Arbeit beseitigt.

Heute laufen über 75 % der Support-Interaktionen bei Cursor über Cursor selbst, wodurch sich der Durchsatz unserer Support-Ingenieure um das 5- bis 10-Fache erhöht. Das hat die Möglichkeiten von Support-Ingenieuren im Vergleich zu vor nur einem Jahr grundlegend verändert.

#Ausgehend von der Codebase

Wenn wir etwas untersuchen, beginnen wir in der Regel im Ask Mode. Wir geben dort das Symptom an und lassen Cursor den relevanten Produktkontext rückwärts nachverfolgen. Da unsere gesamte Codebase lokal verfügbar ist, kann Cursor in derselben Sitzung Produktcode, Dokumentation und interne Tools indexieren und per semantischer Suche nutzen.

Hier spielen Multi-Root-Workspaces ihre Stärken aus. Produktkontext erstreckt sich fast immer über mehrere Repositories. Um die Benutzerfrage „Warum ist dieser Button deaktiviert?“ zu beantworten, müssen oft Frontend-Logik, Backend-Policy-Prüfungen und die Dokumentation zum erwarteten Verhalten zusammen betrachtet werden. Wir halten zusammengehörige Repositories in einem Workspace gebündelt, damit solche Fragen in einem einzigen Thread beantwortet werden können.

#Einbindung von Support-Quellen mit MCP

Wir nutzen MCP-Server, um Kontextinformationen abzurufen und in unsere Untersuchungen einzubringen. Unsere Support-Ingenieure müssen nicht länger mehrere Tools durchsuchen, um relevante Kontextinformationen abzurufen, da sie in Cursor verfügbar sind.

MCP-Server ermöglichen uns die Integration von:

• Datenbanken mit Kundeninformationen, etwa zur Tarifstufe des Abonnements, zu Team-Einstellungen und zu Datenschutzeinstellungen
• Gestreamten Ereignisprotokollen mit Details zu genutzten Diensten, Telemetriefehlern und Netzwerkproblemen
• Kommunikationsplattformen wie Slack, voller Threads und Unterhaltungen, die unser Verständnis davon vervollständigen, wie Kunden mit dem Produkt interagieren.
• Ticketing-Plattformen im Engineering-Bereich mit potenziell Dutzenden einzelner Teams, die jeweils unterschiedlich arbeiten
• Einem internen Dokumentationsdienst, der Runbooks und Anleitungen zur Fehlerbehebung enthält
• Einem Account-Management-Dienst mit wichtigen Kundeninformationen, die beeinflussen können, wie du auf einen Kunden zugehst

Mit Cursor und MCP-Servern können unsere Support-Ingenieure schnell die benötigten Informationen direkt in ihre Untersuchungen der Codebase einbeziehen.

#Ermitteln, wo der Fehler aufgetreten ist

Wenn ein Kunde einen Fehler meldet, müssen wir verstehen: Ist das Problem reproduzierbar oder nur vorübergehend, und an welcher Stelle genau ist Cursor fehlgeschlagen (clientseitig, am API-Edge, in einer nachgelagerten Abhängigkeit oder bei der Authentifizierung)? Mit Datadog MCP können wir die relevanten Logs und Traces direkt in den Untersuchungs-Thread ziehen, sodass wir die möglichen Ursachen eingrenzen können.

#Ähnliche Fälle aufspüren

Wenn ein neues Support-Ticket eingeht, ist das Problem wahrscheinlich schon bei einem anderen Kunden oder jemandem aus unserem Team aufgetreten. Ein MCP, das in deine Support-Plattform sowie in Slack integriert ist, erlaubt uns, diesen Kontext direkt zu durchsuchen und die relevantesten Threads in die Untersuchung einzubeziehen. Wir suchen zuerst nach eindeutigen Kennungen (Fehler-Strings, Request-IDs), weiten die Suche bei Bedarf aus und suchen dann den neuesten Thread mit aktuellem Status, Workaround und zuständiger Person.

#Feststellen, ob es sich um einen Bug handelt

Viele Untersuchungen laufen letztlich auf die Frage hinaus: „Bug oder erwartetes Verhalten?“ Mit Notion MCP können wir das relevante Runbook in den Thread holen, es mit unseren Beobachtungen abgleichen und entweder das Verhalten bestätigen oder mit einem deutlich klareren Bug-Report eskalieren.

#Einen Bug-Report erstellen

Wenn wir eine Untersuchung in Cursor abgeschlossen haben, haben wir alle Materialien beisammen, die wir brauchen, um bei Bedarf ein Ticket für das Engineering-Team zu erstellen. Mit dem Linear MCP können wir all diesen Kontext direkt aus demselben Thread in eine formatierte Eskalation umwandeln.

#Aktualisierungen der Dokumentation

Wenn mehrere Kunden auf dieselben Fragen stoßen, ist das oft ein Zeichen dafür, dass wir unsere Dokumentation verbessern müssen. Der technische Support ist gut aufgestellt, um solche Korrekturen direkt umzusetzen. Wir markieren einfach @Cursor in Slack und geben an, was aktualisiert werden muss, und ein Cloud-Agent erstellt eine PR für unser Doku-Repository.

#Prozess automatisieren

#Befehle für häufige Schritte

Wir nutzen Slash-Befehle für die am häufigsten wiederkehrenden Schritte im Prozess:

# Support-Ticket erstellen
Erstelle ein Linear-Ticket für den gemeldeten Bug oder das Problem eines Benutzers.

## Format
- **Informationen zur meldenden Person:** E-Mail, Konto-ID, Plattform, App-Version
- **Zusammenfassung:** Kurze Beschreibung in 1–2 Sätzen
- **Erwartet vs. Tatsächlich:** Was passieren sollte vs. was passiert
- **Schritte zum Reproduzieren:** Nummerierte Liste

## Hinweise
- Sammle Benutzerinformationen aus den Logs, bevor du das Ticket erstellst
- Füge Request-IDs oder Trace-IDs hinzu, falls verfügbar
- Verlinke auf zugehörige Log-Abfragen oder Dashboards
- Standardmäßig Priorität „Medium“ verwenden, sofern nicht anders angegeben

# Antwort an den Kunden entwerfen
Entwirf eine Antwort an den Kunden zu seinem Problem.

## Richtlinien
- Verwende nur den öffentlichen Produktnamen
- Vermeide interne Servicenamen, Codenamen oder Infrastrukturdetails
- Teile keine internen Fehlercodes, Dateipfade oder Umgebungsvariablen
- Halte dich an öffentlich dokumentierte Features und Standardschritte zur Fehlerbehebung

## Im Zweifelsfall
Frage: „Könnte ein Kunde dies durch die normale Produktnutzung entdecken?“
Falls nicht, formuliere es mit allgemeinen Debugging-Ansätzen um.

# Nach bekannten Problemen suchen
Durchsuche Slack, um festzustellen, ob ein Problem bereits bekannt ist.

## Workflow
1. Suche mit Kennungen (Ticket-ID, Fehlercode, exakte Fehlermeldung)
2. Nach Kanal und Zeitraum eingrenzen
3. Threads mit Status-, Workaround- oder Owner-Informationen finden

## Ausgabe
- **Ergebnis:** Bekannt / Möglicherweise bekannt / Nicht gefunden
- **Bester Thread:** Permalink + Zusammenfassung
- **Nächste Suche:** Abfrage zum Ausprobieren, falls die Ergebnisse schwach sind

# Logs durchsuchen
Durchsuche Datadog-Logs nach dem angegebenen Request, Benutzer oder Fehler.

## Häufige Muster
- @requestId:{id} — einen bestimmten Request finden
- @userId:{id} oder @email:{email} — Benutzeraktivität finden
- status:error — nur nach Fehlern filtern
- service:{name} — nach Service filtern

## Hinweise
- Gib immer einen Zeitraum an (Standard: letzte 7 Tage)
- Feldnamen variieren je nach Quelle — probiere mehrere Muster aus
- Beginne breit und grenze dann anhand der Ergebnisse ein

#Regeln und Skills für wiederkehrende Muster

Wir nutzen Regeln und Skills, um häufige Abläufe in Supportanalysen zu automatisieren.

# Skill: Kundenantwort (sicher + umsetzbar)

## Eingaben, die ich brauche
- Symptom beim Kunden (was er sieht)
- Was wir gefunden haben (faktenbasierte Zusammenfassung)
- Nächster Schritt/Workaround (falls vorhanden)
- 0–2 fehlende Informationen, nach denen gefragt werden soll

## Ausgabeformat
- Kurze Rückmeldung
- Was wir gefunden haben (keine internen Details)
- Was als Nächstes ausprobiert werden soll (nummerierte Schritte)
- Falls nötig: maximal zwei Fragen (um die Untersuchung voranzubringen)
- Zum Schluss angeben, was wir unsererseits als Nächstes tun

## Leitplanken
- Interne Implementierungsdetails und internen Jargon vermeiden
- Konkrete Schritte Spekulationen vorziehen
- Knapp halten; auf die „erste hilfreiche Antwort“ optimieren

# Skill: Ein hochwertiges Bug-Ticket erstellen

## Eingaben, die ich brauche
- Symptom (für Kunden sichtbar)
- Zeitfenster
- Vorhandene IDs (Request-ID, Benutzer-/Team-ID)
- Beleg-Snippets (bereinigt)

## Ausgabeformat
## Zusammenfassung
## Erwartet vs. Tatsächlich
## Schritte zur Reproduktion
## Belege
## Umfang/Schweregrad
## Empfohlener nächster Schritt zur Fehlerbehebung

## Qualitätsanspruch
- Keine vage Sprache („manchmal“, „funktioniert nicht“) ohne konkrete Bedingung
- Kein ausschließlich interner Jargon im Titel
- Kundenspezifische Informationen unkenntlich machen, sofern nicht ausdrücklich genehmigt

# Skill: Recherche zu bekannten Problemen (Slack + Notion)

## Eingaben, die ich brauche
- Exakter Fehlertext (oder die bestmögliche Annäherung)
- Schlüsselwörter zum Feature-Bereich
- Zeitfenster (Standard: letzte 30 Tage)

## Workflow
- Zuerst Slack nach exakten Formulierungen und Kennungen durchsuchen.
- Wenn die Ergebnisse schwach sind, die Suche mit Feature-Schlüsselwörtern und Zeitfiltern erweitern.
- Notion nach Runbooks/FAQs für denselben Feature-Bereich durchsuchen.

## Ausgabeformat
- Urteil: Bekannt / Möglicherweise bekannt / Nicht gefunden
- Beste Threads: 1–3 Links mit einer einzeiligen Angabe „warum relevant“
- Workaround / Abhilfe (falls vorhanden)
- Nächste Verfeinerung der Suche: exakte Suchanfrage, die als Nächstes ausgeführt werden soll

#Subagents, um Schritte parallel auszuführen

Mit Subagents können wir gängige Schritte im Supportprozess parallel statt nacheinander ausführen.

• LogInvestigator durchsucht Datadog nach der Fehlerstelle und passenden Belegen.
• KnownIssueMiner durchsucht Slack und Notion nach früheren Threads und Workarounds.
• TicketWriter fasst die Belege zu einer vollständigen Eskalation zusammen.
• CustomerReplyDrafter formuliert die Antwort an den Kunden und entfernt dabei interne Details.

Die Ergebnisse werden zu einer einzigen Ausgabe zusammengeführt, die wir prüfen und versenden.

supportInvestigationPack:
  goal: >
    Erstelle eine fundierte Untersuchungszusammenfassung, einen Entwurf
    für ein Bug-Ticket und eine Antwort an den Kunden, indem spezialisierte
    Agent parallel ausgeführt werden.
  inputs:
    - customer_symptom
    - time_window
    - identifiers:
        request_id: ""
        user_or_team_id: ""
        error_text: ""
    - investigation_notes
  agents:
    - name: LogInvestigator
      focus: "Datadog: identifiziere die wahrscheinlichste Fehlerstelle und passende Belege."
      output:
        - suspected_root_cause
        - strongest_evidence
        - disconfirming_checks
        - open_questions
    - name: KnownIssueMiner
      focus: "Slack/Notion: finde frühere Erkenntnisse, den aktuellen Status und einen Workaround."
      output:
        - verdict
        - best_links
        - workaround
        - next_search_query
    - name: TicketWriter
      focus: "Schreibe auf Basis von Belegen und Notizen ein Bug-Ticket für das Engineering-Team."
      output:
        - title
        - summary
        - expected_vs_actual
        - steps_to_repro
        - evidence
        - suggested_next_debug_step
    - name: CustomerReplyDrafter
      focus: "Entwirf eine Antwort an den Kunden: klar, sicher und umsetzbar."
      constraints:
        - "Keine internen Implementierungsdetails aufnehmen."
        - "Höchstens zwei fehlende Datenpunkte erfragen."
      output:
        - reply_text
        - questions_for_customer
  final_assembler:
    merges:
      - LogInvestigator
      - KnownIssueMiner
      - TicketWriter
      - CustomerReplyDrafter
    produces:
      - investigation_summary
      - ticket_draft
      - customer_reply

#KI-nativer technischer Support

Durch die Kombination dieser Tools bringen wir Code-Recherche direkt in den technischen Supportprozess. Wir schätzen, dass unser Team dadurch im Vergleich zu herkömmlichen Ansätzen, die mehr Wechsel zwischen Tools und Teams erfordern, um bis zu eine Größenordnung produktiver sein kann. Dieser Produktivitätsgewinn ermöglicht es unserem kleinen (aber wachsenden) Team von Support-Ingenieuren, unsere schnell wachsende Benutzerbasis effektiv zu unterstützen.

Wenn du mehr darüber erfahren möchtest, wie du Cursor in deinen CX-Workflow integrieren kannst, nimm Kontakt auf.