E-Mail Inbox Triage
Kunden-Onboarding

Support-Ticket-Kategorisierung und Routing

Jedes Ticket eingeordnet, zugewiesen und beantwortet

So funktioniert dieser Workflow

  1. 1TriggerNeues Support-Ticket (Betreff, Nachricht, Kundenkontext)
  2. 2KlassifikationKategorie, Priorität, zuständiges Team + Begründung als JSON
  3. 3Routing-RegelTicket dem definierten Team bzw. der Queue zuweisen
  4. 4Ticket aktualisierenKategorie, Priorität, Team und Tags im System setzen
  5. 5Erstantwort (optional)Personalisiert mit Ticket-ID und SLA-Bearbeitungszeit

Prompts zum Kopieren

Trag deine Angaben ein oder klick auf einen Namen im Text. Alles bleibt in deinem Browser — wir sehen und speichern es nicht.

Builder-Prompt

Der Builder-Prompt baut den Workflow. Die zwei Prompts darunter laufen später in ihm — sie gehören in die beiden KI-Schritte.

Baue einen Workflow nach der folgenden Spezifikation. Passe die Struktur an die Konzepte deines Tools an (z. B. Nodes, Steps, Zaps, Agenten-Aktionen) — erhalte dabei aber Trigger-Logik, Reihenfolge, die Review-Verzweigung und den Datenfluss.

## Ziel
Jedes neue Support-Ticket automatisch klassifizieren (Kategorie + Priorität), dem richtigen Team zuweisen, das Ticket-System aktualisieren und eine personalisierte Erstantwort erzeugen — mit Review-Schutz für kritische Fälle.

## Trigger
- Typ: Webhook/Integration des Ticket-Systems (Zendesk, Freshdesk) — feuert bei jedem neuen Ticket; liefert Betreff, Nachricht und Kundenkontext.

## Schritte (sequenziell)
1. KI-Schritt: Kategorisierung & Priorisierung — nutze EXAKT „Prompt 1“ (unten). Output ist JSON mit kategorie, prioritaet, team, begruendung.
2. Routing: Ticket anhand des Kategorie-→-Team-Mappings der richtigen Queue/dem Team zuweisen. Die Team-Namen müssen EXAKT den Bezeichnern im Ticket-System entsprechen.
3. Ticket aktualisieren: Kategorie, Priorität, Team und Tags im System setzen.
4. KI-Schritt: Erstantwort — nutze EXAKT „Prompt 2“ (unten).
5. VERZWEIGUNG (Versandregel): Low-Risk-Fälle (z. B. Kategorie „Frage“ mit Priorität Niedrig/Mittel) → Erstantwort automatisch senden; Kritisch, Hoch oder Beschwerde → NUR als Draft speichern und Review anfordern.

## Prompts (exakt und unverändert übernehmen)
Prompt 1 – Kategorisierung & Priorisierung:
"""
Du bist ein Support-Ticket-Analyse-Assistent. Analysiere das folgende Support-Ticket und kategorisiere es präzise.

**Ticket-Details:**
- Betreff: {{TICKET_BETREFF}}
- Nachricht: {{TICKET_NACHRICHT}}
- Kunde: {{KUNDENNAME}}

**Deine Aufgabe:**
1. Kategorisiere das Ticket in GENAU EINE dieser Kategorien:
- Bug (technischer Fehler in der Software)
- Feature Request (Wunsch nach neuer Funktion)
- Frage (allgemeine Anfrage oder How-to)
- Beschwerde (Unzufriedenheit mit Service/Produkt)
- Technisches Problem (Zugriffs- oder Konfigurationsproblem)
- Abrechnung (Fragen zu Rechnung, Zahlung, Abo)

2. Lege die Priorität fest:
- Kritisch: System down, keine Nutzung möglich, Datenverlust
- Hoch: Wichtige Funktion beeinträchtigt, mehrere Nutzer betroffen
- Mittel: Einzelnes Problem, Workaround möglich
- Niedrig: Kosmetisches Problem, Feature Request, allgemeine Frage

3. Bestimme das zuständige Team:
- Development: Bugs, technische Probleme, Feature Requests
- Customer Success: Fragen, Onboarding, Best Practices
- Sales: Upgrade-Anfragen, Produktinformationen
- Finance: Abrechnung, Rechnungen, Zahlungsprobleme
- Management: Beschwerden, Eskalationen

**Antworte ausschließlich in diesem JSON-Format:**
{
"kategorie": "[Kategorie]",
"prioritaet": "[Priorität]",
"team": "[Team]",
"begruendung": "[Kurze Begründung in 1-2 Sätzen]"
}
"""

Prompt 2 – Erstantwort:
"""
Erstelle eine professionelle, freundliche Erstantwort für ein Support-Ticket.

**Kontext:**
- Kundenname: {{KUNDENNAME}}
- Ticket-ID: {{TICKET_ID}}
- Kategorie: {{KATEGORIE}}
- Priorität: {{PRIORITAET}}
- Zuständiges Team: {{TEAM}}

**Anforderungen:**
- Persönliche Ansprache mit Namen
- Bestätigung des Ticket-Eingangs
- Kurze Zusammenfassung, dass wir das Anliegen verstanden haben
- Realistische Bearbeitungszeit basierend auf Priorität:
* Kritisch: innerhalb von 2 Stunden
* Hoch: innerhalb von 4 Stunden
* Mittel: innerhalb von 24 Stunden
* Niedrig: innerhalb von 48 Stunden
- Freundlicher, hilfsbereiter Ton
- Unterschrift mit "Support Team Name"

**Antworte NUR mit dem E-Mail-Text, ohne Betreff.**
"""

## Datenfluss
- Trigger → 1: {{TICKET_BETREFF}}, {{TICKET_NACHRICHT}}, {{KUNDENNAME}}
- Schritt 1 → 2/3: JSON-Felder kategorie, prioritaet, team, begruendung
- Trigger/Schritt 1 → 4: {{KUNDENNAME}}, {{TICKET_ID}}, {{KATEGORIE}}, {{PRIORITAET}}, {{TEAM}}
- Schritt 1 → 5: kategorie + prioritaet steuern die Versand-Verzweigung

## Fehlerbehandlung
- KI liefert kein valides JSON: „nur JSON“-Anweisung beibehalten, Output validieren, 1x wiederholen; danach Ticket unklassifiziert in eine Triage-Queue legen.
- Falsche Priorität bei vagen Tickets: Beispiele pro Stufe ergänzen; im Zweifel höhere Priorität wählen (Review fängt es ab).
- Team-Namen passen nicht: exakte Queue-/Team-Bezeichner aus dem Support-Tool abgleichen — sonst schlägt das Routing fehl.
- Kundenname nicht extrahierbar: neutrale Anrede als Fallback statt falscher Namen.
- Ticket mit mehreren Themen: nach dem dringendsten Anliegen klassifizieren, Begründung vermerkt den Rest.
- Kritisch/Beschwerde automatisch versendet: Versandregel aus Schritt 5 strikt umsetzen — diese Fälle IMMER mit Review.

## Platzhalter-Konvention
Platzhalter in geschweiften Klammern füllt der Workflow zur Laufzeit selbst. Platzhalter in eckigen Klammern legt der User einmalig fest, bevor der Workflow aktiviert wird. Dynamisch gemappt werden: {{TICKET_BETREFF}}, {{TICKET_NACHRICHT}}, {{KUNDENNAME}}, {{TICKET_ID}} sowie {{KATEGORIE}}, {{PRIORITAET}}, {{TEAM}} aus dem JSON von Schritt 1 (siehe Datenfluss). NICHT dynamisch ist: Support Team Name — muss der User vor Aktivierung manuell festlegen; ebenso das Kategorie-→-Team/Queue-Mapping als Workflow-Konfiguration. Die eckigen Klammern im JSON-Format sind Format-Anweisungen ans LLM und bleiben unverändert. Liste manuelle Platzhalter am Ende explizit auf.

## Selbst-Check vor Abschluss
Prüfe, bevor du den Workflow als fertig meldest:
1. Sind alle Schritte korrekt verbunden — inklusive der Versand-Verzweigung (Low-Risk automatisch, Kritisch/Hoch/Beschwerde nur als Draft mit Review)?
2. Sind beide KI-Prompts vollständig und unverändert eingefügt und alle Platzhalter gemappt?
3. Wird das JSON validiert und entsprechen die Team-Namen exakt den Queues im Ticket-System?
4. Liste alle Punkte auf, die manuell konfiguriert werden müssen (z. B. Ticket-System-Webhook + Schreibrechte, Kategorie-→-Team-Mapping, Low-Risk-Regel, Support Team Name, LLM-API-Key).
Alternativ direkt importierenWorkflow-JSON herunterladen

Prompt – Kategorisierung & Priorisierung

Klassifiziert das Ticket in Kategorie, Priorität und zuständiges Team und liefert eine kurze Begründung als JSON.

Du bist ein Support-Ticket-Analyse-Assistent. Analysiere das folgende Support-Ticket und kategorisiere es präzise.

**Ticket-Details:**
- Betreff: {{TICKET_BETREFF}}
- Nachricht: {{TICKET_NACHRICHT}}
- Kunde: {{KUNDENNAME}}

**Deine Aufgabe:**
1. Kategorisiere das Ticket in GENAU EINE dieser Kategorien:
- Bug (technischer Fehler in der Software)
- Feature Request (Wunsch nach neuer Funktion)
- Frage (allgemeine Anfrage oder How-to)
- Beschwerde (Unzufriedenheit mit Service/Produkt)
- Technisches Problem (Zugriffs- oder Konfigurationsproblem)
- Abrechnung (Fragen zu Rechnung, Zahlung, Abo)

2. Lege die Priorität fest:
- Kritisch: System down, keine Nutzung möglich, Datenverlust
- Hoch: Wichtige Funktion beeinträchtigt, mehrere Nutzer betroffen
- Mittel: Einzelnes Problem, Workaround möglich
- Niedrig: Kosmetisches Problem, Feature Request, allgemeine Frage

3. Bestimme das zuständige Team:
- Development: Bugs, technische Probleme, Feature Requests
- Customer Success: Fragen, Onboarding, Best Practices
- Sales: Upgrade-Anfragen, Produktinformationen
- Finance: Abrechnung, Rechnungen, Zahlungsprobleme
- Management: Beschwerden, Eskalationen

**Antworte ausschließlich in diesem JSON-Format:**
{
"kategorie": "[Kategorie]",
"prioritaet": "[Priorität]",
"team": "[Team]",
"begruendung": "[Kurze Begründung in 1-2 Sätzen]"
}

Prompt – Erstantwort

Erzeugt eine freundliche, personalisierte Erstantwort mit Ticket-ID und einer Bearbeitungszeit, die zur Priorität passt.

Erstelle eine professionelle, freundliche Erstantwort für ein Support-Ticket.

**Kontext:**
- Kundenname: {{KUNDENNAME}}
- Ticket-ID: {{TICKET_ID}}
- Kategorie: {{KATEGORIE}}
- Priorität: {{PRIORITAET}}
- Zuständiges Team: {{TEAM}}

**Anforderungen:**
- Persönliche Ansprache mit Namen
- Bestätigung des Ticket-Eingangs
- Kurze Zusammenfassung, dass wir das Anliegen verstanden haben
- Realistische Bearbeitungszeit basierend auf Priorität:
* Kritisch: innerhalb von 2 Stunden
* Hoch: innerhalb von 4 Stunden
* Mittel: innerhalb von 24 Stunden
* Niedrig: innerhalb von 48 Stunden
- Freundlicher, hilfsbereiter Ton
- Unterschrift mit "Support Team Name"

**Antworte NUR mit dem E-Mail-Text, ohne Betreff.**

Was dieser Workflow genau macht

Im Support kommt alles im selben Postfach an: der Totalausfall, die Rechnungsfrage, der Feature-Wunsch. Jemand muss jedes Ticket lesen, einordnen, an das richtige Team weiterreichen und dem Kunden bestätigen, dass es angekommen ist. Bis das passiert, wartet auch der dringende Fall in derselben Reihe wie der kosmetische.

Dieser Workflow übernimmt die Triage. Er liest Betreff und Nachricht jedes neuen Tickets, legt Kategorie und Priorität fest, bestimmt das zuständige Team und begründet seine Einordnung in zwei Sätzen. Danach schreibt er Zuweisung, Tags und Felder ins Ticket-System zurück und formuliert eine persönliche Erstantwort mit Ticket-Nummer und einer Bearbeitungszeit, die zur Priorität passt. Harmlose Fälle beantwortet er selbst; kritische, hoch priorisierte und Beschwerden legt er nur als Entwurf ab und fordert eine Freigabe an.

Der Unterschied zu einem Skill oder Agenten: Ein Workflow läuft von allein. Du richtest ihn einmal ein, danach arbeitet er ohne dich — es gibt kein Gespräch, in dem du etwas nachreichst. Deine Stellschrauben sind die Zuordnung von Kategorie zu Team, die Regel, welche Fälle ohne Freigabe hinausgehen dürfen, und der Absender, der unter der Erstantwort steht.

So richtest du ihn ein

Entscheide zuerst, wie du starten willst. Danach siehst du nur den passenden Weg.

Wie möchtest du den Workflow anlegen?

Beide Wege führen zum selben Aufbau.

Builder-Prompt: n8n · Make · Zapier · Langdock

Du siehst beim Aufbau zu und kannst eingreifen.

  1. Angaben oben ausfüllen und Builder-Prompt kopieren.
  2. Workflow-Tool öffnen, einen neuen Workflow anlegen und den KI-Chat wählen.
  3. Den Builder-Prompt einfügen.
  4. Den erzeugten Aufbau prüfen.

  1. Zugänge verbinden, bevor der Workflow das erste Mal läuft

    Das Ticket-System (Zendesk, Freshdesk o. ä.) mit Lese- UND Schreibrecht, ein E-Mail-Werkzeug für den Versand und ein LLM-Zugang. Am fehlenden Schreibrecht scheitert es am häufigsten — der Workflow liest dann sauber und kann das Ticket trotzdem nicht aktualisieren.

  2. Kategorien den Teams zuordnen

    Die Team-Namen wörtlich aus deinem Support-Tool übernehmen. Schon eine abweichende Schreibweise lässt jede Zuweisung ins Leere laufen, ohne dass irgendwo ein Fehler gemeldet wird.

  3. Die beiden Teil-Prompts in die KI-Schritte einsetzen, unverändert.

    Der zweite arbeitet mit dem, was der erste ausgibt; wer einen umschreibt, muss die Felder des anderen mitziehen.

  4. Mit einem echten Ticket testen, das du selbst einordnen könntest

    „Login funktioniert nicht seit dem Update“. Prüf drei Dinge: Passen Kategorie und Priorität zur Dringlichkeit? Landet das Ticket in der richtigen Queue? Stehen Zuweisung, Tags und Felder wirklich im System?

  5. Die Grenzfälle durchspielen, bevor du live gehst

    Ein vages Ticket ohne erkennbares Anliegen, eines mit zwei Themen gleichzeitig, eines in einer anderen Sprache und ein leeres. Genau dort entscheidet sich, ob ein Kunde eine Antwort bekommt, die an seinem Problem vorbeigeht.

  6. Schmal starten

    Wenige Kategorien, und die Erstantwort zunächst nur für harmlose Fälle automatisch verschicken. Kritisch, Hoch und Beschwerde gehören als Entwurf in eine Freigabe — eine falsch beruhigende Antwort auf einen Ausfall kostet mehr Vertrauen, als der Zeitgewinn wert ist.

Wenn dein Workflow läuft

Du bist fertig. Diese Hinweise brauchst du erst, wenn etwas hakt oder du den Workflow erweitern möchtest.

  • Die Einordnung springt bei vagen TicketsBeispiele je Prioritätsstufe im ersten Prompt ergänzen
  • Das Ergebnis lässt sich nicht auswertenauf sauberes JSON bestehen und den Output validieren
  • Die Zuweisung geht ins LeereTeam-Namen gegen das Support-Tool abgleichen
  • Die Erstantwort klingt nach BausteinAnsprache mit Namen und Ticket-Nummer verpflichtend machen

So richtest du ihn ein

  1. Angaben oben ausfüllen und Prompts kopieren —deine Angaben setzen sich beim Kopieren mit ein. Den Prompt selbst kannst du dabei frei ändern — kürzen, ergänzen, umschreiben.
  1. Zugänge verbinden, bevor der Workflow das erste Mal läuft: das Ticket-System (Zendesk, Freshdesk o. ä.) mit Lese- UND Schreibrecht, ein E-Mail-Werkzeug für den Versand und ein LLM-Zugang. Am fehlenden Schreibrecht scheitert es am häufigsten — der Workflow liest dann sauber und kann das Ticket trotzdem nicht aktualisieren.
  2. Kategorien den Teams zuordnen: Die Team-Namen wörtlich aus deinem Support-Tool übernehmen. Schon eine abweichende Schreibweise lässt jede Zuweisung ins Leere laufen, ohne dass irgendwo ein Fehler gemeldet wird.
  3. Die beiden Teil-Prompts in die KI-Schritte einsetzen, unverändert. Der zweite arbeitet mit dem, was der erste ausgibt; wer einen umschreibt, muss die Felder des anderen mitziehen.
  4. Mit einem echten Ticket testen, das du selbst einordnen könntest — „Login funktioniert nicht seit dem Update“. Prüf drei Dinge: Passen Kategorie und Priorität zur Dringlichkeit? Landet das Ticket in der richtigen Queue? Stehen Zuweisung, Tags und Felder wirklich im System?
  5. Die Grenzfälle durchspielen, bevor du live gehst: ein vages Ticket ohne erkennbares Anliegen, eines mit zwei Themen gleichzeitig, eines in einer anderen Sprache und ein leeres. Genau dort entscheidet sich, ob ein Kunde eine Antwort bekommt, die an seinem Problem vorbeigeht.
  6. Schmal starten: wenige Kategorien, und die Erstantwort zunächst nur für harmlose Fälle automatisch verschicken. Kritisch, Hoch und Beschwerde gehören als Entwurf in eine Freigabe — eine falsch beruhigende Antwort auf einen Ausfall kostet mehr Vertrauen, als der Zeitgewinn wert ist.
  7. Wenn es hakt, sind es fast immer dieselben vier Stellen: Die Einordnung springt bei vagen Tickets (Beispiele je Prioritätsstufe im ersten Prompt ergänzen), das Ergebnis lässt sich nicht auswerten (auf sauberes JSON bestehen und den Output validieren), die Zuweisung geht ins Leere (Team-Namen gegen das Support-Tool abgleichen), die Erstantwort klingt nach Baustein (Ansprache mit Namen und Ticket-Nummer verpflichtend machen).
  8. Ausbauen, wenn der Kern läuft: Eskalation bei erkennbarem Ärger, VIP-Erkennung, SLA-Überwachung, Zusammenführen doppelter Tickets.

Screenshots

Alle Workflows