Support-Tickets per KI einordnen und beantworten

Montagmorgen, 38 neue Tickets. Ein Kunde meldet, dass der Export nicht mehr läuft, einer fragt nach einer Rechnungskopie, ein dritter schreibt zum vierten Mal in zwei Wochen und ist hörbar verärgert. Bevor irgendjemand eine Antwort schreibt, muss jemand lesen, sortieren, Prioritäten setzen und entscheiden, wer zuständig ist. Diese Sortierarbeit ist die teuerste halbe Stunde des Tages, denn sie bindet genau die Leute, die das Produkt am besten kennen. Und sie ist fehleranfällig: Die verärgerte Nachricht rutscht zwischen zwei Routinefragen durch, weil sie um 7:12 Uhr kam und die Liste nach Eingang sortiert ist.

Diese Seite zeigt, wie Sie das Einordnen und das Vorformulieren von Antworten an ein Sprachmodell abgeben, ohne die Kontrolle über das zu verlieren, was Ihre Kunden lesen. ameax bleibt das Ticketsystem, in dem alles steht. n8n ist der Taktgeber, der neue Tickets abholt. Das Sprachmodell liest und schlägt vor. Und ein Mensch entscheidet, welche Antwort den Kunden erreicht.

Wichtig zur Einordnung: Eine automatische Triage ist in ameax nicht eingebaut. Was ameax mitbringt, ist das Fundament, auf dem sie sauber funktioniert: Vorgänge mit frei definierbaren Status je Vorgangsart, eine eigene Ticket-Adresse je Vorgangsart, ein Kundenportal und vor allem ein Sichtbarkeitsschalter an jedem einzelnen Kommentar. Genau dieser Schalter macht es möglich, dass eine KI Antworten vorbereitet, ohne dass sie ungeprüft beim Kunden ankommen.

Der Ablauf im Überblick

Der Workflow hat vier Beteiligte mit klar getrennten Rollen. ameax ist das führende System und das Gedächtnis: Hier liegt das Ticket, hier liegt die Historie des Kunden, hier landet jedes Ergebnis. n8n gibt den Takt vor und transportiert Daten. Das Sprachmodell bearbeitet Text, es klassifiziert und formuliert. Der Mensch gibt frei, wo es um Außenwirkung geht.

1. Ticket kommt an. Der Kunde schreibt an die Ticket-Adresse der Vorgangsart, eröffnet den Vorgang selbst über das Ticketsystem im Kundenportal, oder ein externes Formular legt ihn über die API an. ameax setzt den Vorgang in den Eingangsstatus.
2. n8n holt neue Tickets ab. Ein zeitgesteuerter Workflow fragt alle paar Minuten die Vorgänge im Eingangsstatus ab und lädt zu jedem den Kommentarstrang, denn dort steht der Mailinhalt.
3. Das Sprachmodell ordnet ein. Es bestimmt Thema, Dringlichkeit, Stimmung und das zuständige Team und liefert das Ergebnis als festes JSON zurück.
4. n8n schreibt die Einordnung zurück. Priorität, Zuständigkeit und Status werden am Vorgang gesetzt; die Begründung landet als interner Kommentar.
5. Das Sprachmodell entwirft eine Antwort. Grundlage sind Ihre Textvorlagen aus ameax, nicht das Allgemeinwissen des Modells.
6. Der Entwurf wird intern abgelegt. Als Kommentar, der für den Kunden nicht sichtbar ist.
7. Ein Mitarbeiter prüft und gibt frei. Er passt den Entwurf bei Bedarf an und schaltet ihn für den Kunden sichtbar. Nur eng definierte Standardfälle darf der Workflow direkt beantworten.
8. Der Prozess läuft weiter wie gewohnt. Prozess-Buttons des Vorgangs setzen Folgeschritte, Benachrichtigungen und Statuswechsel funktionieren wie bei jedem anderen Ticket.

Vorbereitung in ameax

Die meiste Arbeit steckt nicht im Workflow, sondern in einer sauberen Struktur. Ein Sprachmodell kann nur Kategorien wählen, die es gibt, und nur Teams zuweisen, die im System angelegt sind. Richten Sie deshalb einmalig Folgendes ein — zuletzt den technischen Benutzer, dessen Token Sie brauchen, um n8n an ameax anzubinden.

Vorgangsart mit Ticket-Adresse

Legen Sie eine Vorgangsart für den Support an oder nutzen Sie eine bestehende. Jede Vorgangsart hat einen eigenen Nummernkreis und kann als Ticketsystem mit Mail-Eingang betrieben werden. Dann bekommt sie eine eigene Ticket-Adresse nach dem Muster ticket.s<Vorgangsart-ID>@<Ihre Installation>. Eingehende Mails werden über die Ticket-Nummer im Betreff oder Text dem richtigen Vorgang zugeordnet, auch über ältere Ticket-Nummern. Findet ameax keinen Vorgang, eröffnet es einen neuen und schreibt den Mailinhalt als Kommentar hinein; auf Wunsch wird bei unbekanntem Absender auch ein Kunde angelegt. Für die Triage heißt das: Der Text, den das Sprachmodell lesen soll, steht im Kommentarstrang des Vorgangs.

Status für den Eingang und für die Triage

Status sind in ameax frei definierbar, und zwar je Vorgangsart. Für diesen Workflow brauchen Sie mindestens zwei:

• Einen Eingangsstatus, zum Beispiel „Neu, unsortiert". Nur Vorgänge in diesem Status holt der Workflow ab. Legen Sie ihn als Standardstatus der Vorgangsart fest, damit jedes neue Ticket automatisch dort landet.
• Einen Status nach der Triage, zum Beispiel „Vorsortiert, Entwurf liegt vor". In diesen Status schiebt der Workflow jedes bearbeitete Ticket. Damit ist sichtbar, was die KI angefasst hat, und kein Ticket wird zweimal verarbeitet.

Die IDs der Status müssen Sie nicht in den Einstellungen suchen: GET /api/v2/task-schemes/{id}/states liefert sie mit Titel und Statustyp. Dort sehen Sie auch, welcher Status als Standard markiert ist.

Teams und Zuständige

Ein Vorgang kann einem Benutzer oder einem Team zugewiesen werden. Für die Triage ist das Team meist die bessere Wahl, denn das Sprachmodell kennt Ihre Abteilungen, aber nicht die Urlaubsplanung. Notieren Sie die IDs der Teams, die als Ziel in Frage kommen, und geben Sie jedem Team eine Beschreibung in einem Satz. Diese Beschreibung wird Teil des Prompts.

Prozess-Buttons im Vorgang

Prozess-Buttons sind die Workflow-Werkzeuge eines Vorgangs — dieselben geführten Prozesse, die Sie im Vorfeld definieren und einrichten. Ein Button kann den Status wechseln, die Priorität ändern, einen Zuständigen setzen, eine Checkliste anwenden, eine Fälligkeit „in X Tagen" setzen, eine Nachricht an den Kunden schicken, eine Wiedervorlage oder einen Folge-Vorgang anlegen. Wenn Ihr Team für bestimmte Fälle bereits Buttons nutzt, etwa „An Technik übergeben" oder „Rückmeldung vom Kunden erforderlich", kann der Workflow genau diese Buttons auslösen, statt die Schritte einzeln nachzubauen. Welche Buttons ein Vorgang gerade anbietet, liefert GET /api/v2/tasks/{id}/proceedings.

Textvorlagen als Wissensquelle

Legen Sie eine Kategorie für Support-Antworten an und pflegen Sie dort die Antworten, die Ihr Team ohnehin immer wieder schreibt: Rechnungskopie im Portal, Passwort zurücksetzen, Lieferzeiten, bekannte Fehlerbilder. Das Sprachmodell soll diese Vorlagen als Grundlage nehmen und an den Einzelfall anpassen. Das hat zwei Vorteile: Die Antworten bleiben inhaltlich bei dem, was Ihr Unternehmen zusagt, und Ihr Team pflegt das Wissen an einer Stelle, die es ohnehin nutzt.

Kundenportal und Kommentarsichtbarkeit

Ob ein Kommentar für den Kunden sichtbar ist, entscheidet ein Schalter je Kommentar. Voreingestellt ist „intern". Die Freigabe-Checkbox erscheint im Backend nur, wenn die Vorgangsart überhaupt Portalzugriff hat. Prüfen Sie also, dass die Rolle Ihrer Kundenzugänge die Vorgangsart sehen und Kommentare lesen darf. Kundenzugänge, für die Benachrichtigungen eingeschaltet sind, erfahren von Statuswechseln und neuen Nachrichten zusätzlich per E-Mail; auch dort gilt der Filter: Interne Kommentare werden nicht mitgeschickt.

Technischer Benutzer und API-Token

Legen Sie für den Workflow einen eigenen Benutzer an, etwa „KI-Triage", und erzeugen Sie für ihn einen API-Token unter /c/apitoken. Ein Token hat keine eigenen Rechte-Scopes, er erbt die Rechte seines Benutzers. Geben Sie dem Benutzer deshalb genau die Rechte, die der Workflow braucht: Vorgänge der Support-Vorgangsart lesen und bearbeiten, Kommentare schreiben, Textvorlagen lesen. Schränken Sie den Token zusätzlich auf die IP-Adresse Ihres n8n-Servers ein und setzen Sie ein Ablaufdatum. Ein eigener Benutzer hat noch einen Nebeneffekt, der bei der Kontrolle hilft: Jeder Kommentar, den der Workflow schreibt, steht unter seinem Namen.

Auslöser

ameax meldet neue Tickets nicht aktiv an andere Systeme. Der Workflow startet deshalb zeitgesteuert: Ein Schedule-Trigger in n8n läuft zum Beispiel alle fünf Minuten während der Servicezeiten und fragt die Vorgänge im Eingangsstatus ab.

GET https://ihrefirma.ameax.de/api/v2/tasks?filter[scheme_id]=3&filter[state_id]=21&sort=-created_at&per_page=50
Authorization: Bearer <Token des technischen Benutzers>

Die Werte 3 (Vorgangsart) und 21 (Eingangsstatus) sind Beispiel-IDs. Weil der Workflow jedes bearbeitete Ticket aus dem Eingangsstatus herausnimmt, braucht er kein Gedächtnis darüber, was er schon gesehen hat. Der Status ist die Markierung. Das ist robuster als ein Zeitstempel in n8n, denn es funktioniert auch dann, wenn ein Lauf ausfällt oder abbricht: Beim nächsten Lauf liegen die offenen Tickets einfach noch da.

Es gibt zwei weitere Wege, den Workflow anzustoßen, die sich mit dem zeitgesteuerten Abruf kombinieren lassen:

• Ein externes System ruft n8n auf. Ein Kontaktformular auf Ihrer Website, ein Chat-Widget oder ein Voice-Agent-Dienst schickt die Anfrage per Webhook an n8n. n8n legt das Ticket selbst an (siehe unten) und kann die Triage sofort im selben Lauf erledigen.
• Einzelne Tickets auf Zuruf. Ein manueller Trigger in n8n, dem ein Mitarbeiter eine Vorgangs-ID übergibt, ist nützlich für die Testphase und für Tickets, die jemand von Hand in den Eingangsstatus zurückgelegt hat.

Wenn Anfragen nicht als Mail an die Ticket-Adresse gehen, sondern von einem Formular kommen, legt n8n den Vorgang über die API an. Pflicht sind Vorgangsart, Titel und ein Kunde oder Ansprechpartner:

POST https://ihrefirma.ameax.de/api/v2/tasks
Content-Type: application/json

{
  "scheme_id": 3,
  "task": "Export bricht mit Fehlermeldung ab",
  "description": "Text aus dem Kontaktformular …",
  "customer_id": 4711,
  "person_id": 815,
  "state_id": 21
}

Auch hier sind alle IDs Beispielwerte. Den Kunden sucht der Workflow vorher über GET /api/v2/customers?filter[email]=… oder GET /api/v2/persons?filter[email]=…. Die Antwort auf die Anlage enthält die url des Vorgangs, die n8n zum Beispiel in eine Bestätigung an das Formular zurückgeben kann.

Umsetzung Schritt für Schritt

Der Workflow besteht in n8n aus wenigen Knoten: Schedule Trigger, ein HTTP-Request-Knoten für die Liste, eine Schleife über die Tickets, darin je ein HTTP-Request für die Kommentare, ein KI-Knoten für die Einordnung, ein Code- oder Switch-Knoten für die Regeln, und HTTP-Requests zum Zurückschreiben. Für alle HTTP-Requests gilt dieselbe Anmeldung: Header Authorization: Bearer <Token>, Body als JSON mit Content-Type: application/json.

Schritt 1: Kontext laden

Zu jedem Ticket aus der Liste lädt der Workflow den Kommentarstrang. Bei Tickets aus dem Mail-Eingang steht dort der eigentliche Text der Kundenmail.

GET https://ihrefirma.ameax.de/api/v2/tasks/1234/comments

Zwei weitere Abrufe machen die Einordnung deutlich besser. Erstens die bisherigen Vorgänge desselben Kunden, damit das Modell erkennt, ob jemand zum wiederholten Mal schreibt:

GET https://ihrefirma.ameax.de/api/v2/tasks?filter[customer_id]=4711&sort=-created_at&per_page=10

Zweitens die Textvorlagen der Support-Kategorie, die als Wissensbasis in den Antwortentwurf eingehen:

GET https://ihrefirma.ameax.de/api/v2/text-modules?filter[category_id]=12&per_page=100

Die Vorlagen ändern sich selten. Es genügt, sie einmal pro Lauf zu laden und für alle Tickets zu verwenden.

Schritt 2: Einordnen lassen

Der KI-Knoten bekommt Titel, Kommentartext und die Kurzliste der früheren Vorgänge. Entscheidend ist ein Prompt, der das Ausgabeformat festlegt und die zulässigen Werte vorgibt. Das Modell wählt aus Ihrer Liste, es erfindet keine Kategorien.

ROLLE
Du ordnest Support-Tickets eines Softwareunternehmens ein. Du antwortest
ausschließlich mit gültigem JSON im unten beschriebenen Format.

TEAMS (nur diese IDs sind zulässig)
7  = Technik: Fehler, Abstürze, Schnittstellen, Datenexporte
8  = Buchhaltung: Rechnungen, Zahlungen, Mahnungen, Gutschriften
9  = Kundenservice: Zugänge, Passwörter, allgemeine Fragen, Termine

PRIORITÄT (nur diese Werte)
critical = Kunde kann nicht arbeiten, mehrere Nutzer betroffen
high     = wichtige Funktion gestört, es gibt eine Umgehung
normal   = Frage oder Störung ohne Zeitdruck
low      = Wunsch, Anregung, Information

EINGABE
Titel: {{ticket.task}}
Nachricht: {{kommentartext}}
Frühere Vorgänge dieses Kunden (letzte 10): {{vorgangsliste}}

AUSGABE
{
  "thema": "kurze Bezeichnung, max. 5 Wörter",
  "prio": "critical|high|normal|low",
  "team_id": 7,
  "stimmung": "positiv|neutral|verärgert",
  "wiederholung": true,
  "standardfall": "rechnungskopie|passwort|keiner",
  "begruendung": "ein bis zwei Sätze, warum",
  "sicherheit": 0.0
}

REGELN
- Wenn du unsicher bist, setze "sicherheit" unter 0.7 und "team_id" auf 9.
- "standardfall" nur setzen, wenn die Anfrage eindeutig und ausschließlich
  diesen Fall betrifft. Sonst "keiner".
- Erfinde keine Fakten über Produkte, Preise oder Fristen.

Die Team-IDs 7, 8 und 9 sind Beispielwerte. Der Wert sicherheit ist die Selbsteinschätzung des Modells. Sie ist kein Messwert, aber als Weiche nützlich: Unsichere Fälle gehen an ein Team, das breit aufgestellt ist, und werden nicht automatisch beantwortet.

Schritt 3: Regeln anwenden

Zwischen Modell und ameax gehört eine Prüfung in einem Code- oder Switch-Knoten. Sie stellt sicher, dass nur zulässige Werte weitergehen: Ist prio einer der vier Werte? Ist team_id in Ihrer Liste? Liefert das Modell ungültiges JSON, geht das Ticket mit Priorität normal an das Standardteam und bekommt einen internen Hinweis, dass die automatische Einordnung fehlgeschlagen ist. Hier legen Sie auch Ihre eigenen Regeln fest, die Vorrang vor dem Modell haben. Ein Beispiel: Schreibt ein Kunde zum dritten Mal innerhalb kurzer Zeit und ist verärgert, wird mindestens high gesetzt, egal wie das Modell den Inhalt bewertet.

Schritt 4: Einordnung zurückschreiben

Mit einem einzigen PATCH setzt der Workflow Priorität, Team und den neuen Status:

PATCH https://ihrefirma.ameax.de/api/v2/tasks/1234
Content-Type: application/json

{
  "prio": "high",
  "assignee_division_id": 7,
  "state_id": 22
}

22 steht hier als Beispiel-ID für den Status „Vorsortiert, Entwurf liegt vor". Statt eines Teams kann der Workflow auch einen Benutzer setzen (assignee_user_id), etwa wenn Sie feste Ansprechpartner für bestimmte Kunden haben. Ein Vorgang hat entweder einen zuständigen Benutzer oder ein zuständiges Team.

Die Begründung des Modells schreibt der Workflow als internen Kommentar in den Vorgang. So sieht der Mitarbeiter, der das Ticket öffnet, sofort, warum es bei ihm gelandet ist:

POST https://ihrefirma.ameax.de/api/v2/tasks/1234/comments
Content-Type: application/json

{
  "message": "KI-Einordnung: Thema „Datenexport“, Priorität hoch, Stimmung verärgert, dritte Meldung in 14 Tagen. Begründung: Export bricht seit dem letzten Update ab, Kunde nennt Frist zum Monatsende.",
  "public": false
}

Schritt 5: Antwort entwerfen

Für den Antwortentwurf bekommt das Sprachmodell die Kundennachricht, die Einordnung aus Schritt 2 und die passenden Textvorlagen. Der zweite Prompt ist bewusst getrennt vom ersten. Einordnen und Formulieren sind verschiedene Aufgaben, und getrennte Prompts lassen sich getrennt verbessern.

ROLLE
Du formulierst einen Antwortentwurf für einen Support-Mitarbeiter.
Der Entwurf wird vor dem Versand von einem Menschen geprüft.

WISSEN (nur dieses verwenden)
{{textvorlagen: name, subject, message}}

EINGABE
Nachricht des Kunden: {{kommentartext}}
Einordnung: {{ergebnis_schritt_2}}

AUFGABE
- Beantworte die Anfrage in der Sie-Form, sachlich und freundlich.
- Nutze die Inhalte der Wissensvorlagen. Wenn keine Vorlage passt,
  bestätige den Eingang, fasse das Anliegen in einem Satz zusammen
  und kündige die Rückmeldung des zuständigen Teams an.
- Keine Zusagen zu Terminen, Preisen oder Kulanz.

AUSGABE
{
  "antwort": "Text der Antwort",
  "genutzte_vorlagen": ["Name der Vorlage"],
  "offene_punkte": "was der Mitarbeiter noch klären muss"
}

Schritt 6: Entwurf intern ablegen

Der Entwurf wird als eigener Kommentar mit "public": false angelegt. Er steht damit im selben Strang, in dem später die freigegebene Antwort steht, aber der Kunde sieht ihn nicht. Der Filter greift in der Datenbankabfrage: Interne Kommentare werden an das Portal gar nicht erst ausgeliefert.

POST https://ihrefirma.ameax.de/api/v2/tasks/1234/comments
Content-Type: application/json

{
  "message": "Guten Tag Frau Beispiel,\n\nvielen Dank für Ihre Nachricht …",
  "public": false
}

Die Antwort enthält die ID des neuen Kommentars. Speichert n8n sie, kann der Workflow später gezielt auf diesen Entwurf zugreifen.

Schritt 7: Freigabe durch einen Menschen

Der Mitarbeiter öffnet den Vorgang, liest Einordnung und Entwurf, passt den Text bei Bedarf an und klickt am Kommentar auf „Für Accounts lesbar machen". Ab diesem Moment sieht der Kunde die Antwort. ameax protokolliert, wer den Kommentar wann freigegeben hat. Geht die Freigabe von außen aus, etwa aus einer Freigabeliste in einem Chat-Werkzeug, erledigt das ein einzelner Aufruf:

PATCH https://ihrefirma.ameax.de/api/v2/tasks/1234/comments/98765
Content-Type: application/json

{
  "public": true
}

Für eng definierte Standardfälle können Sie auf die Freigabe verzichten. Ein Beispiel ist die Frage nach einer Rechnungskopie, wenn Rechnungen ohnehin im Dokumentenportal liegen: Die Antwort ist immer dieselbe, sie verweist auf das Portal und enthält keine Zusage. In diesem Fall legt der Workflow den Kommentar direkt mit "public": true an. Legen Sie diese Standardfälle als Liste fest und lassen Sie das Modell nur aus dieser Liste wählen. Alles, was nicht eindeutig passt, bleibt beim Menschen.

Schritt 8: Prozess-Buttons auslösen

Wenn in der Vorgangsart Prozess-Buttons für typische Folgeschritte hinterlegt sind, kann der Workflow sie ausführen. Das ist sinnvoll, wenn ein Button mehrere Dinge auf einmal erledigt, die Ihr Team ohnehin so will, etwa Status wechseln, Checkliste anwenden und Fälligkeit setzen:

POST https://ihrefirma.ameax.de/api/v2/tasks/1234/proceedings/5/execute

Die Antwort enthält das Feld done. Nur wenn es true ist, wurde der Button ausgeführt. Ein Button kann an Bedingungen hängen, etwa an den aktuellen Status; ist die Bedingung nicht erfüllt, meldet ameax done: false mit einer Nachricht. Der Workflow muss dieses Feld prüfen und im Fehlerfall einen internen Kommentar schreiben, statt stillschweigend weiterzumachen. Die 5 ist eine Beispiel-ID; die verfügbaren Buttons eines Vorgangs liefert GET /api/v2/tasks/{id}/proceedings.

Was in ameax sichtbar wird

Das Ergebnis des Workflows ist kein separates Dashboard, sondern steht dort, wo Ihr Team ohnehin arbeitet.

Im Vorgang

Jeder bearbeitete Vorgang trägt Priorität, zuständiges Team und den Status nach der Triage. Im Kommentarstrang stehen die Einordnung mit Begründung und der Antwortentwurf, beide als intern gekennzeichnet und unter dem Namen des technischen Benutzers. Die freigegebene Antwort trägt den Vermerk „Für Accounts lesbar", und ameax protokolliert, wer sie wann freigegeben hat. Öffnet der Kunde die Antwort im Portal, steht am Kommentar „Dem Account angezeigt" mit dem ersten und letzten Zeitpunkt. Jeder Statuswechsel landet in der Status-Historie des Vorgangs.

Bei den Zuständigen

Wird ein Vorgang einem Team oder Benutzer zugewiesen, greifen die normalen Benachrichtigungen von ameax. Änderungen werden in Klartext übersetzt und gebündelt, damit nicht jede Kleinigkeit eine eigene Mail erzeugt. Bei Priorität „kritisch" geht die Benachrichtigung sofort raus.

In Hub und Auswertungen

Im Hub stehen Container für Vorgänge bereit: das Aufgaben-Dashboard, fällige Vorgänge, Vorgänge mit Änderungen und die Verweildauer je Status. Die Verweildauer ist für diesen Workflow besonders aufschlussreich. Sie zeigt, wie lange Tickets im Eingangsstatus liegen, bevor sie eingeordnet sind, und wie lange sie danach bis zur ersten freigegebenen Antwort brauchen. Wenn der Workflow wirkt, schrumpft die erste Zahl. Unter den Auswertungen zu Vorgängen finden Sie zusätzlich das Status-Cockpit und die Auswertung der Status-Verweildauer.

Beim Kunden

Der Kunde sieht im Kundenportal seine Vorgänge und den freigegebenen Gesprächsverlauf, also genau die Kommentare, die freigegeben sind, und seine eigenen. Einordnung, Begründung und nicht freigegebene Entwürfe sieht er nicht. Wenn die Vorgangsart dafür eingerichtet ist, kann er selbst Prozess-Buttons drücken, etwa „Problem besteht weiterhin" oder „Kann geschlossen werden".

Best Practices und Stolperstellen

• Mit reiner Einordnung starten. Lassen Sie den Workflow in den ersten Wochen nur Priorität, Team und Begründung setzen, ohne Antwortentwürfe. So sieht Ihr Team, wie oft das Modell richtig liegt, bevor es Texte vorschlägt. Wer umsortieren muss, schreibt einen kurzen Kommentar; diese Korrekturen sind die beste Grundlage, um den Prompt nachzuschärfen.
• „critical" sparsam vergeben. Bei Priorität „kritisch" verschickt ameax die Benachrichtigung an die Zuständigen sofort, statt sie zu bündeln. Das ist gewollt, aber nur solange es selten passiert. Setzen Sie für „critical" eine hohe Sicherheitsschwelle oder lassen Sie das Modell höchstens „high" vorschlagen und die Hochstufung einem Menschen.
• Den Status als Markierung nutzen. Die API kennt keine Idempotenz-Schlüssel. Dass ein Ticket nicht doppelt verarbeitet wird, stellt der Statuswechsel sicher. Setzen Sie ihn deshalb im selben PATCH wie Priorität und Team, bevor der Entwurf geschrieben wird. Schlägt der Entwurf fehl, ist das Ticket trotzdem eingeordnet und nur der Entwurf fehlt.
• Nur Werte aus Ihrer Liste zulassen. Ein Sprachmodell gibt manchmal ein Team zurück, das es nicht gibt, oder schreibt die Priorität auf Deutsch. Die Prüfung zwischen Modell und ameax fängt das ab. Eine ungültige Eingabe beantwortet die API mit einem Fehler im Format application/problem+json, der das betroffene Feld nennt; loggen Sie diese Fehler in n8n mit der X-Request-Id aus der Antwort.
• Öffentliche Antworten nur für Fälle ohne Zusage. Ein direkt sichtbarer Kommentar ist eine Aussage Ihres Unternehmens. Automatisch beantworten sollte der Workflow nur Fälle, bei denen die Antwort immer gleich ist und nichts verspricht: Hinweis auf das Portal, Eingangsbestätigung, Link zu einer Anleitung. Sobald Termine, Preise, Kulanz oder Fehlerursachen im Spiel sind, gehört ein Mensch dazwischen.
• Die Wissensbasis in ameax pflegen, nicht im Prompt. Wenn sich eine Antwort ändert, soll Ihr Team die Textvorlage ändern und nicht den n8n-Workflow. Der Workflow lädt die Vorlagen bei jedem Lauf neu. So bleibt Fachwissen bei den Fachleuten und die Technik bleibt stabil.
• Datenschutz vor dem ersten Lauf klären. Ticket-Inhalte enthalten personenbezogene Daten und manchmal mehr: Zugangsdaten, Gesundheitsangaben, Vertragsdetails. Bevor Tickettexte an ein Sprachmodell gehen, sollten Sie prüfen lassen, welcher Dienst dafür in Frage kommt, auf welcher Rechtsgrundlage die Verarbeitung erfolgt und was in Ihrer Datenschutzerklärung stehen muss. Das ist eine Einzelfallprüfung, die dieser Artikel nicht ersetzt.
• Rechte des technischen Benutzers eng halten. Der Token kann alles, was sein Benutzer darf. Ein Triage-Workflow muss keine Kunden löschen und keine Belege sehen. Je enger die Rechte, desto kleiner der Schaden, wenn ein Token in falsche Hände gerät.

Fazit

Die Triage ist die Stelle im Support, an der sich am meisten Zeit verliert, ohne dass jemand einem Kunden hilft. Ein Sprachmodell kann diese Arbeit gut vorbereiten, wenn es aus festen Listen wählen muss und seine Ergebnisse dort ablegt, wo Ihr Team sie ohnehin sieht. ameax liefert dafür den Rahmen: Vorgänge mit eigenen Status, Teams und Prozess-Buttons, Textvorlagen als Wissensbasis und einen Sichtbarkeitsschalter an jedem Kommentar, der standardmäßig auf „intern" steht. Der n8n-Workflow verbindet beides über die REST-API. Wer mit reiner Einordnung beginnt, die Entwürfe intern hält und nur eng definierte Fälle automatisch beantwortet, gewinnt Zeit, ohne die Kontrolle über das abzugeben, was beim Kunden ankommt. Wie Sie dieselben Daten nutzen, um Betreuer vor einem Termin zu informieren und Abwanderungssignale früh zu sehen, zeigt das Szenario Account-Briefings und Abwanderungssignale.