Meta Muse für die Ticket-Triage im Support: Was Metas WhatsApp-KI sortiert und was Sie 2026 selbst bauen

Was "Meta Muse für die Ticket-Triage im Support" tatsächlich bedeutet

Ich baue bei eesel Integrationen, und meist heißt das, die API eines anderen genau zu lesen, bis ich die Stelle finde, an der das Marketing aufhört. Bei der Triage ist die Lücke meist am größten. Alle sagen "KI routet Ihre Tickets", und dann öffnet man die Doku und sucht das Feld, in dem die Priorität gespeichert wird. So habe ich Metas Doku für diesen Beitrag gelesen.

Zuerst zur Benennung. "Meta Muse" kann auf drei verschiedene Produkte zeigen, und nur zwei davon berühren die Ticket-Triage:

Meta sagt, "more than one million businesses are already using a Meta Business Agent on WhatsApp and Messenger" (Meta Newsroom). Es gibt eine Self-Serve-Stufe in der Meta Business Suite und der WhatsApp Business App, und es gibt die Meta Business Agent Platform für Unternehmen auf der WhatsApp Business Platform API. Welches Modell dahintersteckt, hat Meta nicht genannt.

Einen breiteren Produktüberblick finden Sie in meiner Anleitung Meta Muse für den Kundensupport.

Die fünf Triage-Aufgaben und wer sie erledigt

Reduziert man Support-Ticket-Triage auf das Wesentliche, sind es fünf Aufgaben: die Sprache bestimmen, eine Kategorie wählen, eine Priorität setzen, es an das richtige Team schicken und ein Ticket anlegen, das jemand bearbeitet. So geht Metas Stack mit jeder davon um.

Die Sprache ist die einfachste Aufgabe, deshalb beginne ich damit.

Sprache: automatisch, aber nicht gemeldet

Meta stellt klar: "Meta Business Agent handles language automatically. There is no language setting to configure" (Capabilities). Er "Detects the language of each customer WhatsApp message and responds in the same language", fällt bei Unsicherheit auf die Hauptsprache Ihres Unternehmens zurück und liest Ihre Wissensquellen in ihrer Originalsprache. Metas eigener Vorbehalt: "English has the strongest response quality."

Der Haken für die Triage: Die erkannte Sprache verlässt den Agenten nie. Keine der Webhook- oder Connector-Seiten, die ich gelesen habe, legt einen Sprachcode offen. Wenn spanische Tickets also an ein spanischsprachiges Team gehen sollen, müssen Sie die Sprache in Ihrem eigenen System erneut erkennen. Meine Anleitung dazu, ob KI mehrsprachigen Support beherrscht, behandelt die Optionen.

Kategorie: nur über Ihr eigenes Tool

Meta Business Agent kann über Connectors Aktionen ausführen, also HTTP-Tools, die Sie gegen Ihre eigene API definieren. Metas Leitfaden für Kundensupport-Agenten führt eines namens create_support_ticket vor, und in Metas gesamter Doku ist es das Nächstliegende an Triage. Die Beschreibung weist den Agenten an: "Call this for damage, missing items, payment disputes, refund decisions, and anything the documented policies do not cover." Der Body hat vier Felder:

• category: "One of: damage, missing_item, payment, refund_request, product_fault, other."
• summary: "A short summary of what the shopper reported, in their own words where possible."
• order_id: "The related order, when the shopper is asking about one."
• customer_phone: wird automatisch aus der WhatsApp-Nummer gefüllt.

Das ist ein brauchbares Setup für die Ticket-Klassifizierung, aber mit zwei Einschränkungen. Erstens ist es keine Meta-Funktion, sondern ein Beispiel, das Sie kopieren und auf Ihren eigenen Endpunkt richten. Zweitens erzwingt nichts die erlaubten Werte. Connector-Felder können nur "string", "integer", "number" oder "boolean" sein (Connector tools), und "enum" taucht auf der Seite nicht auf. Die Kategorieliste steht als einfacher Text in der Feldbeschreibung, also muss Ihr Endpunkt eine Kategorie ablehnen, die nicht auf der Liste steht.

Priorität: gar nicht vorhanden

Für diesen Beitrag habe ich jede Meta-Seite nach "priority" und "urgent" durchsucht. Nichts in der Routing-Doku, den Agent-Einstellungen, der Connector-Referenz oder den Support-Leitfäden definiert ein Prioritäts- oder Dringlichkeitsfeld, und das Beispiel-Ticket-Tool hat keines. Sie können Ihrem eigenen Tool einen String priority hinzufügen und die Regeln in dessen Beschreibung festhalten, oder die Priorität in Ihrem Endpunkt aus Kategorie und Bestellwert berechnen. Wie auch immer Sie es lösen, die Regeln schreiben Sie. Wenn Sie sie von Grund auf formulieren, bietet mein Beitrag zur KI-Ticket-Priorisierung einen Startsatz.

Wie WhatsApp Conversation Routing tatsächlich routet

Die meisten verstehen diesen Teil falsch, und mir ging es beim ersten Lesen genauso. Meta hat Conversation Routing für WhatsApp veröffentlicht, und "Routing" klingt nach Triage. Ist es aber nicht.

Meta weist "each inbound message to a single responder based on the message's entry point" zu, den es als "the context in which the WhatsApp user's message arrives" definiert (Overview). Es gibt fünf Einstiegspunkte: eine normale Nachricht (Service, der Standard), eine Antwort auf eine Click-to-WhatsApp-Anzeige, eine Antwort auf eine Utility-Vorlage, eine Antwort auf eine Marketing-Vorlage und einen eingehenden Anruf. "Each entry point maps to exactly one responder" (Entry points and routing). Und sobald ein Thread einen Besitzer hat, "the message is delivered to the current owner regardless of its entry point."

Dieser Dialog ist die gesamte Konfiguration. Es gibt keine Zeile für "Erstattungsfragen" oder "VIP-Kunden". Ein Kunde, der sich über ein kaputtes Produkt beschwert, und einer, der nach Ihren Öffnungszeiten fragt, kommen beide als "Customer sends a message" an und landen deshalb beim selben Responder.

Drei weitere Regeln bestimmen, was Sie bauen können:

1. Ein Eskalationspartner pro Konto. Der Eskalationspartner "can take control of any thread, regardless of who currently owns it. Each account has at most one escalation partner" (Overview). Ihr Abrechnungs- und Ihr Tech-Team können nicht in getrennten Apps sitzen und beide Eskalationsziel sein.
2. Übergaben zielen auf Rollen, nicht auf Teams. Eine gezielte Übergabe setzt target_role auf ai_agent, ctwa, customer_service, escalation, marketing oder utility (Thread control). Diese entsprechen Einstiegspunkten, nicht Abteilungen.
3. Die Konfiguration gibt es nur in der Oberfläche. "There is no public API for configuring Conversation Routing" (Get started). Wenn Sie Business Agent aktivieren, wird er zu "the sole primary for messaging entry points", und Ihr bisheriger Primary, oft Ihr Helpdesk, wird in den Standby verschoben. Was das für ein Zendesk-Setup bedeutet, habe ich in meinem Beitrag Meta Muse für Zendesk beschrieben.

In der Praxis machen Sie Ihren Helpdesk zum Eskalationspartner und übernehmen dort das Team-Routing. Dafür ist intelligentes Routing im Helpdesk da, ob Freshdesk, das WhatsApp-Tickets an eine Gruppe routet, oder Zendesk-Trigger.

Entwickler fragten genau danach, bevor die Routing-Doku erschien:

"Is there anything in the WhatsApp Business Platform that supports this natively ; a queue, an agent assignment concept, a way to mark a conversation as "human handling now" so my webhook knows not to auto-reply, or any equivalent of the Messenger handover protocol (primary and secondary receiver apps) for WhatsApp?"

u/_Udara27, r/WhatsappBusinessAPI auf Reddit

Conversation Routing beantwortet nun die Übergabe-Hälfte dieser Frage. Für die Hälfte mit Warteschlange und Zuweisung gibt es weiterhin nichts.

Eskalation: Was eine Übergabe auslöst

Die Eskalation ist die eine Triage-Entscheidung, die Meta für Sie trifft. Sie ist auch die, über die Sie die geringste Kontrolle haben.

Die eingebauten Auslöser sind fest: "the agent starts a handoff automatically when it detects a signal such as low confidence, an integrity violation, or a customer asking for a human. You do not configure the triggers" (Capabilities). Die API für die Agent Settings gibt Ihnen handoff.enabled, die Übergabenachricht und einen Follow-up-Timer, aber kein Feld für Schwellenwerte oder Regeln.

Ihre eigenen Auslöser gehören in die Anweisungen. Metas Support-Leitfaden empfiehlt das ausdrücklich: "Enumerate the escalation triggers rather than describing them. 'Escalate when appropriate' is not an instruction an agent can follow consistently." Sein Beispiel übergibt, "when the shopper reports damage or a missing item, disputes a payment, asks for a refund decision, mentions a legal or safety issue, or asks twice for a person." Das ist ein guter Rat für jedes Setup zur KI-Eskalation. Ein Satz aus Metas Post-Purchase-Leitfaden gehört allerdings an die Wand: "Telling the agent to escalate does nothing on its own. Configure the handoff policy in agent settings and implement thread control."

Was bei der Übergabe ankommt

Wenn ein Thread an Ihren Helpdesk übergeht, können zwei Dinge mitkommen:

• Ein metadata-String, "Free-form string, maximum 2,000 characters, forwarded verbatim to the receiving app" (Thread control). Metas Leitfaden schlägt vor, ihn zu nutzen, "to carry the ticket or order reference", mit dem Beispiel "Ticket MF-T-40917, damaged glass shade".
• Eine KI-Zusammenfassung in conversation_context. Meta sagt, "Identifiers and amounts are preserved verbatim" und "Open items are framed as unresolved", was für den Mitarbeiter nützlich ist, der übernimmt. Es sagt aber auch, summary.text sei "human-readable prose, not structured data", und man solle es "not parse it for fields" (Conversation context).

Sie bekommen eine lesbare Ticket-Zusammenfassung für Menschen, keinen Grundcode, nach dem sich routen ließe. Wenn Ihr Helpdesk auf dem eskalierten Ticket Kategorie und Priorität braucht, müssen diese aus Ihrem Aufruf von create_support_ticket kommen, nicht aus dem Übergabe-Ereignis. Außerdem gibt es "no endpoint that reports which responder currently owns a thread", also muss Ihr System die Zuständigkeit selbst anhand der Übergabe-Ereignisse nachverfolgen.

Die Self-Serve-Stufe ist einfacher und manueller

Auf der Self-Serve-Seite in der Business Suite ist die Triage noch schlichter. Sie können "assign conversations in Inbox to different people" (Assign conversations) und Labels "by category, topic or importance" vergeben (Labels), beides von Hand. Der Agent fügt seine eigenen Labels "Meta Business Agent Responding" und "Meta Business Agent Transferred" hinzu (Manage responses).

Inbox-Automatisierungen erkennen "up to 5 specific keywords or phrases", und "keywords are case-sensitive, and an automated message will not be sent unless the keywords match exactly" (Inbox automations). Meta weist außerdem darauf hin, dass das Aktivieren von Business Agent bestehende Automatisierungen pausiert und dass eine manuelle Antwort den Agenten in diesem Chat pausiert, bis "after 7 days of inactivity". Automatisches Labeln, Round-Robin oder eine Team-Warteschlange gibt es nicht. Ein Shop mit zwei Personen, die WhatsApp beantworten, kommt damit klar, aber bei zehn Personen wird daraus schnell eine Tabellenkalkulation.

Die selbstgebaute Triage-Pipeline

Setzt man die Teile zusammen, sieht Triage auf Basis von Meta Business Agent so aus:

1. Definieren Sie create_support_ticket mit Ihren echten Kategorien. Halten Sie die Liste kurz und überschneidungsfrei. Sechs bis zehn Kategorien, die zu den Ticket-Feldern Ihres Helpdesks passen, schlagen zwanzig, die sich überlappen. Meine Triage-Prompt-Vorlagen sind ein Ausgangspunkt für die Beschreibungen.
2. Zählen Sie die Eskalationsauslöser in den Anweisungen einzeln auf, so wie Metas Leitfaden es tut, damit das Tool in denselben Situationen immer aufgerufen wird.
3. Validieren Sie in Ihrem Endpunkt. Lehnen Sie unbekannte Kategorien ab, ergänzen Sie die Priorität nach Ihren eigenen Regeln und schreiben Sie das Ticket mit angehängter WhatsApp-Konversations-ID in die richtige Helpdesk-Gruppe.
4. Machen Sie den Helpdesk zum Eskalationspartner in der Business Suite, damit die menschliche Seite des Threads dort landet, wo auch das Ticket liegt.
5. Überwachen Sie Connector-Fehler. Metas eigener Leitfaden warnt: "A failed ticket is invisible: the agent has already said a colleague will be in touch, the shopper waits, and nobody finds out until they message again angrier." Die Connector-Logs decken nur "the last seven days" ab, richten Sie also einen täglichen Alarm für Fehler ein.

Muse Spark als Klassifikator nutzen

Wenn Sie lieber außerhalb des Agenten klassifizieren möchten, etwa jede WhatsApp-Nachricht, die Sie über Standby-Webhooks erfassen, kann die Muse Spark API das übernehmen. Strukturierte Ausgabe über response_format bedeutet, "the response is always constrained to your JSON Schema" (Structured output), sodass jedes Ticket in derselben Form {category, priority, language} zurückkommt. Anders als Connector-Felder kann ein JSON Schema ein echtes Enum enthalten. Metas Vorbehalt gilt trotzdem: Es "guarantees the shape, not that the model read" die Eingabe richtig (Chart analysis cookbook).

Zwei Preisregeln sind wissenswert. Die günstige Contributor-Stufe ist für Support-Daten tabu, denn "You must not submit sensitive, confidential, or personal information to the Discounted Services" (Terms of Service). Sie zahlen also Standardpreise: 1,25 $ Input und 4,25 $ Output pro 1 Mio. Tokens, mit gecachtem Input zu 0,15 $ (Prompt caching). Legen Sie Kategorieliste und Regeln in ein festes Präfix, damit dieser Teil gecacht wird.

Der Kompromiss: Sie bekommen einen sauberen Klassifikator, aber Standby-Webhooks und die Übergabe-Zusammenfassung schließen sich pro Konversation gegenseitig aus, und Sie betreiben nun zwei KI-Systeme, die denselben Chat lesen. Für die meisten Teams gehört der Klassifikator dorthin, wo das Ticket liegt, also in den Helpdesk.

Was Ticket-Triage auf WhatsApp kostet

Jede Ebene hat ihren eigenen Zähler. Aus Metas Preisdokumentation und den Seiten zur Model API:

Meta sagt, eine typische Agent-Nachricht verbrauche 20.000 bis 25.000 Tokens, und beziffert eine Anfrage mit vier Nachrichten auf etwa 16 bis 20 Cent und einen Chat mit zehn Nachrichten auf 40 bis 50 Cent. Die zweite Zeile übersehen die meisten Teams. Eskalierte Tickets sind genau die, bei denen Ihr Team mehrere Antworten sendet, und ab dem 1. Oktober ist jede davon eine kostenpflichtige Nachricht, sobald die kostenlosen 1.000 aufgebraucht sind. Agenturen haben das bemerkt:

"If Meta is gonna charge for every single service message after the first 1000, our clients' bills are gonna be insane."

u/assylzhan09, r/WhatsappBusinessAPI auf Reddit

Meine Aufschlüsselung der WhatsApp-Business-API-Preise enthält die vollständige Preishistorie.

Wo Metas Stack bei der Triage an Grenzen stößt

Fairerweise: Business Agent ist ein vernünftiger Einstieg für ein Unternehmen, das WhatsApp an erste Stelle setzt, und ich habe ihn neben Freshdesk beschrieben, mit einem eigenen Beitrag für Gorgias-Nutzer. Speziell für die Triage würde ich diese Grenzen abwägen:

• Nirgends eine Priorität. Weder im Routing, in den Einstellungen noch im Beispiel-Tool.
• Das Routing ignoriert den Inhalt. Einstiegspunkte bestimmen den Responder, und es gibt einen Eskalationspartner.
• Kategorien werden nicht erzwungen. Connector-Felder sind einfache Strings, deshalb erreichen fehlerhafte Werte Ihren Endpunkt.
• Eine KI pro Nummer. "An active authorized-agent integration blocks Meta Business Agent" (Überblick), Sie können also Metas Agenten und eine Triage-KI nicht nebeneinander als Responder betreiben. Metas weitergehende Haltung steht in Metas Richtlinie zu KI von Drittanbietern.
• Er sieht nur Metas Apps. Ein Kunde, der wegen derselben Bestellung eine E-Mail schreibt, wird zu einem zweiten, nicht verknüpften Ticket.

Ein BSP-Berater, der den Agenten früh getestet hat, bevor es Connectors gab, zählte vier Steuerungen: Wissen, Persönlichkeit, Zielgruppe und Übergabe. Sein Urteil:

"Fine for a simple FAQ or catalog bot. But if you want real step-by-step logic, you hit the wall fast."

u/Kira_SENPAI_1, r/WhatsappBusinessAPI auf Reddit

Connectors haben die Lücke bei den "Aktionen" seither geschlossen. Die Triage-Logik schreiben Sie aber weiterhin selbst.

Triage muss bei der ersten Nachricht passieren

Die Lehre, die ich daraus ziehe, stammt eher aus eesels Vertriebsgesprächen als aus Metas Doku. Ein CX-Leiter bei einer DTC-Marke mit rund 7.000 Tickets im Monat sagte dem Team, seine eigentliche Anforderung sei konfidenzbasiertes Routing: Die KI antwortet, wenn sie sicher ist, und ein Mensch bekommt den Fall sofort, wenn nicht. Als ihm ein monatlicher Analytics-Bericht als Antwort angeboten wurde, entgegnete er, Kunden wollten nicht auf einen Monatsbericht warten.

Das ist die Lücke in einem Meta-zuerst-Setup. Der Agent antwortet, übergibt mit einer Zusammenfassung in Prosa, und das Ticket landet in Ihrem Helpdesk mit der Kategorie, die Ihr Tool gefüllt hat. Die Priorität, das Team und die Markierung "das ist das dritte Mal, dass sie nachfragen" werden erst später entschieden, von einer Person, die die Zusammenfassung liest. Triage, die wirklich funktioniert, geschieht, wenn das Ticket eröffnet wird, bevor jemand antwortet. Das ist die Idee hinter KI-Support-Tagging in der Warteschlange, ebenso beim Spam-Filtern, und es ist der Grund, warum ich die Triage dort laufen ließe, wo das Ticket liegt.

eesel für die Ticket-Triage im Support ausprobieren

Der Großteil des obigen Aufbaus existiert, weil Metas Agent Kunden antwortet, aber keine Tickets sortiert. eesel setzt am anderen Ende an. Es ist ein KI-Helpdesk-Teammitglied, das sich mit WhatsApp verbindet und in Zendesk arbeitet, außerdem in Freshdesk und Gorgias.

In Zendesk läuft der Triage-Trigger "Only on the customer's first message ... when a ticket is opened, before anyone replies" (eesel-Zendesk-Doku). Er versieht das Ticket mit Tags, aktualisiert Felder "like status or priority" und liest Ihre Feldoptionen, "so tags get set correctly". Das Routing nutzt die eigenen Zuweisungsaktionen des Helpdesks, "driven by your own instructions, for example low confidence or an angry customer" (Helpdesk-Anwendungsfall). Sie schreiben die Regeln in einfachem Englisch, so wie Metas Leitfaden Sie die Auslöser aufzählen lässt, nur dass sie echte Ticket-Felder setzen.

Die Zahl, auf die ich verweisen würde, stammt aus einem Test mit echtem Traffic in einem E-Commerce-Posteingang mit rund 1.000 Tickets im Monat: 93 % Triage-Genauigkeit und 100 % des Spams erkannt, ohne Fehlalarme, in einem Posteingang, in dem 22 % der Tickets Spam waren. Jede Aktion erscheint mit der Begründung im Aktivitätsprotokoll, und Sie können jede Aktion auf automatisch oder genehmigungspflichtig stellen, während Sie Vertrauen aufbauen. Bevor eesel ein Live-Ticket anfasst, können Sie es außerdem auf Ihren vergangenen Tickets laufen lassen und sehen, wie es den letzten Monat getaggt und geroutet hätte.

Wenn Sie Ihren Support-Stack per Skript steuern, führt die eesel CLI dasselbe Teammitglied und denselben Workspace über ein Terminal aus. Jeder Befehl gibt JSON aus, sodass Sie oder ein Coding-Agent wie Claude Code mit eesel activity falsch geroutete Tickets prüfen, mit eesel approvals Freigaben durchsehen oder die Triage-Automatisierung anpassen können, ohne das Dashboard zu öffnen. Es gibt außerdem eine API für Kundensupport-Agenten.

Ein Hinweis: Wegen Metas Regel "eine KI pro Nummer" betreiben Sie auf einer WhatsApp-Nummer entweder eesel oder Meta Business Agent, nicht beides. Wenn WhatsApp Ihr einziger Kanal ist und eine Person jede Eskalation liest, ist Metas Agent mit manuellen Labels ein vernünftiges, günstiges Setup. Wenn Tickets über WhatsApp und E-Mail eintreffen und in der richtigen Reihenfolge zu verschiedenen Teams gelangen müssen, ist Triage bei der ersten Nachricht weniger Aufwand. Die Preise sind ein fester monatlicher Credit-Tarif, bei dem ein Ticket oder Chat ein Credit ist, egal wie viele Antworten es braucht.

Testen Sie eesel kostenlos und lassen Sie es zuerst auf den WhatsApp- und E-Mail-Tickets des letzten Monats laufen.