Meta Muse für Jira Service Management: Metas WhatsApp-KI vor JSM einsetzen (2026)

Kurzfassung

„Meta Muse für Jira Service Management" läuft auf ein Brückenproblem hinaus: JSM hat keinen nativen WhatsApp-Kanal. Meta Business Agent kann also auf WhatsApp antworten, aber eine dritte App muss jede Übergabe in eine JSM-Anfrage tragen. Muse selbst ist ein Consumer-Agent und Muse Spark ein Modell, auf dem man aufbaut, also antwortet keines von beiden deinen Kunden von der Stange.

Der Stack besteht aus drei Schichten auf einer WhatsApp-Nummer: Metas Agent antwortet zuerst, eine Marketplace-App wie Ticblues WhatsApp Channel oder Appfires Chat for JSM dient als Eskalationspartner, und JSM hält die Anfrage. Die gute Nachricht für Entwickler ist die Authentifizierung. Ein Atlassian-Servicekonto mit OAuth-Client-Credentials passt fast genau zur Connector-Auth von Meta, was ich von Zendesk, Freshdesk oder Zoho Desk nicht sagen kann.

Bei den Kosten liegt Metas Agent bei etwa 16 bis 50 Cent pro Konversation, gegenüber 0,30 $ pro unterstützter Konversation beim Virtual Service Agent von JSM nach 1.000 im Monat (nur Slack und Teams) und 1,00 $ pro Lösung beim CSM-KI-Agenten. Ich baue die Integrationen von eesel, und der JSM-Connector von eesel verarbeitet bei einem Kunden bereits über 50.000 Anfragen im Monat. Meine Einschätzung: Die meisten JSM-Teams sollten die KI in das Service-Projekt setzen, nicht daneben. eesel bearbeitet deine JSM-Anfragen aus jedem Kanal und entwirft interne Notizen, bevor es überhaupt antwortet.

Was „Meta Muse für Jira Service Management" eigentlich bedeutet

Ich verbringe den Großteil meiner Woche mit den API-Dokus anderer Unternehmen, und Metas Namensgebung für 2026 ist der Teil, der am längsten zum Entwirren braucht. Drei Meta-Produkte tragen den Namen Muse oder stehen in dessen Nähe, und nur eines davon spricht mit deinen Kunden:

1. Muse, der persönliche KI-Agent, den Meta im September für Alltagsaufgaben von Verbrauchern vorgestellt hat. Er ist nicht dafür gebaut, die Kunden eines Unternehmens zu beantworten.
2. Muse Spark 1.3, das Modell, das über die Meta Model API verkauft wird. Darauf lässt sich ein JSM-Bot bauen, dazu weiter unten mehr. Die Übersicht zu Muse Spark 1.3 enthält die Modelldetails.
3. Meta Business Agent, den Meta im Juni gestartet hat als die KI, die deinen Kunden auf WhatsApp, Messenger und Instagram antwortet. Das ist das Produkt, das ein JSM-Team tatsächlich abwägt.

Mein Leitfaden Meta Muse für den Kundensupport enthält die Aufschlüsselung der drei Produkte. Dieser Beitrag bleibt auf der JSM-Seite: wie WhatsApp überhaupt in ein Service-Projekt kommt, was passiert, sobald Metas Agent die Nummer übernimmt, wie die Auth passt und was das Ganze kostet.

Du nutzt ein anderes Helpdesk? Die Beiträge zu Meta Muse für Zendesk und Freshdesk decken diese ab.

Es gibt auch Versionen für Zoho Desk und HubSpot.

Eines sollte gesagt sein, bevor die Technik beginnt. JSM wird für zwei verschiedene Aufgaben genutzt: interne IT- und HR-Servicedesks, in denen Mitarbeitende Anfragen aus Slack oder Teams stellen, und externen Kundenservice, den Atlassian inzwischen als Customer Service Management innerhalb der Service Collection verkauft. Wenn dein JSM-Projekt ein interner IT-Desk ist, sind deine Mitarbeitenden mit ziemlicher Sicherheit nicht per WhatsApp bei dir, und dieser ganze Beitrag ist nur eine Kuriosität. Die Meta-Frage wird erst real, wenn Kunden außerhalb deines Unternehmens dir auf WhatsApp schreiben.

Wie WhatsApp heute in Jira Service Management gelangt

Das ist der Teil, der alles Weitere prägt: WhatsApp ist kein JSM-Kanal. Atlassians Dokument zu Anfragekanälen nennt „E-Mail, Help Center und darin enthaltene Portale, Chat und ein anpassbares Widget", und Chat meint dort Slack. Die Seite zu Kundenanfragen ergänzt Microsoft Teams. Das ist die komplette native Liste.

Auch Customer Service Management schließt die Lücke nicht. Auf Atlassians CSM-Seite heißt es, Kunden „wechseln nahtlos zwischen Web, Chat, E-Mail, Sprache und Live-Support", und es gibt eine Voice AI, die Anrufe mit Transkripten in Arbeitselemente verwandelt. WhatsApp wird nicht genannt, und einen nativen WhatsApp-Kanal habe ich in Atlassians CSM-Dokumentation nirgends gefunden, zumindest nicht, soweit ich es sehen konnte.

JSM-Kunden fragen seit Jahren danach. Im Atlassian-Community-Forum schrieb ein Admin:

"I want to integrate our Service Desk with WhatsApp to ensure users can do Password reset from their whatsapp."

Jude, Atlassian Community

Die Standardantwort eines ehrenamtlichen Community Champions in einem Thread von 2024 stimmt auch 2026 noch: „You'll need one of the WhatsApp integration apps available on the Atlassian Marketplace to do this, or develop an integration of your own."

Die Marketplace-Apps, die WhatsApp und JSM verbinden

Hier sind die sechs WhatsApp-Apps, die ich im Atlassian Marketplace gefunden habe, mit den Installationszahlen vom 29.09.2026. In keinem der Einträge wurde ein Preis pro Nutzer angezeigt, prüfe also den Preis-Tab jeder App, bevor du dich festlegst.

Zwei Details aus diesen Einträgen sind für die Meta-Frage wichtig. Erstens ist jede dieser Apps selbst eine App, die mit deiner WhatsApp-Nummer verbunden ist, entweder direkt mit Metas Cloud API oder über einen Anbieter wie Infobip. Zweitens setzen zwei von ihnen bereits einen Bot auf die Nummer: Ticblues Virtual Agent führt Entscheidungsbäume aus, und Hey WhatsApp Me hat einen optionalen „AI Concierge" mit deinem eigenen OpenAI-Schlüssel. Merk dir das, es kommt später wieder.

Es gibt außerdem ein Identitätsproblem, das die Apps im Hintergrund still lösen. Die Kunden-API von JSM legt einen Kunden aus „einer E-Mail-Adresse und einem Anzeigenamen" an. Ein WhatsApp-Nutzer kommt mit einer Telefonnummer und sonst nichts. Apps wie Hey WhatsApp Me „legen Kunden automatisch an", und OmniChat lässt dich „eine Telefonnummer für bestehende JSM-Kunden hinzufügen". Sie übernehmen also einen Zuordnungsschritt, den du sonst selbst bauen müsstest.

Was passiert, wenn Meta Business Agent auf diese Nummer kommt

Metas Doku wurde im September deutlich detaillierter, und diese Details zählen, wenn deine WhatsApp-Nummer bereits über eine dieser Apps in JSM einspeist.

Er antwortet zuerst, und deine WhatsApp-App geht in den Standby

Metas Conversation Routing entscheidet, welche verbundene App jede Nachricht beantwortet. Deine Marketplace-App ist eine dieser Apps. Wenn du Business Agent einschaltest, wird „der Agent zum alleinigen Primary für Messaging-Einstiegspunkte", und „frühere primäre Ziele wechseln in den Standby, damit sie den Kontext behalten", so Metas Routing-Einrichtungsleitfaden.

Einfach gesagt: Neue WhatsApp-Nachrichten landen zuerst bei Metas Agent und nicht in deiner JSM-Queue. Du kannst nach Einstiegspunkt aufteilen, etwa deine JSM-App als Primary für Direktnachrichten behalten und die KI auf Click-to-WhatsApp-Anzeigen setzen. Diese Einrichtung gibt es nur in der Meta Business Suite, und Meta sagt das ausdrücklich: „There is no public API for configuring Conversation Routing."

Eine KI pro Nummer, such dir also deinen Bot aus

Metas Plattformübersicht legt die Zulassungsregel fest: Die Nummer darf „nicht bereits einen anderen KI-Agenten auf dieser Nummer betreiben", denn „eine aktive Integration eines autorisierten Agenten blockiert Meta Business Agent".

Was genau zählt, buchstabiert Meta aber nicht aus. Ich würde davon ausgehen, dass eine Marketplace-App mit eigenem Bot auf der Nummer zählt, sodass Ticblues Virtual-Agent-Abläufe oder der AI Concierge von Hey WhatsApp Me zuerst abgeschaltet werden müssten. Eine reine Brücken-App, die Nachrichten nur an menschliche Agenten in JSM weiterreicht, sollte als Standby- und Eskalationspartner in Ordnung sein.

Die Übergabe läuft über den Thread, und Atlassian ist kein genannter Partner

Wenn Business Agent übergibt, zieht der Chat nicht in einen Meta-Posteingang um. Er bleibt im selben WhatsApp-Thread, und nur die Zuständigkeit geht an eine andere App auf der Nummer über. Metas Leitfaden für den Kundensupport nennt „ein besetztes Ziel für übergebene Konversationen" als Voraussetzung, und eine einfache Übergabe geht an die App, die du als „Eskalationspartner" festlegst, laut der Thread-Control-Doku.

Für ein JSM-Team ist dieser Partner deine Marketplace-App, und die App erstellt die Anfrage. Als Meta Business AI vorstellte (der frühere Name für Business Agent), nannte es „Salesforce, Microsoft Dynamics 365 Contact Center, ServiceNow, Zendesk, Gorgias und Klaviyo Service". Der Launch-Beitrag vom Juni nennt „Shopify, Zendesk und Shopee". Atlassian steht auf keiner der beiden Listen, und keiner der sechs App-Einträge erwähnt Business Agent. Nach Metas Routing-Doku sollte eine Übergabe in der App als normale Konversation ankommen, weshalb ich sie zuerst auf einer Ersatznummer testen würde, bevor ein echter Kunde beteiligt ist.

Ein paar weitere Details zur Übergabe, die man kennen sollte:

• Der Kontext reist in einer 2.000-Zeichen-Notiz mit. Das Übergabe-Event trägt ein Freitextfeld metadata, das Meta empfiehlt, „um die Ticket- oder Bestellreferenz mitzugeben". Ob deine App es in die JSM-Anfrage kopiert, liegt beim App-Anbieter.
• Du steuerst die Auslöser nicht. Die Übergabe erfolgt bei geringer Sicherheit, Integritätsproblemen oder wenn ein Kunde nach einem Menschen fragt, und „you do not configure the triggers", laut Metas Capabilities-Seite. Mein Leitfaden zur Übergabe von KI-Agenten zeigt, wie eine gute aussieht.
• Meta warnt vor der Übergabe um 2 Uhr nachts. Im Leitfaden steht: „An agent that hands off at 02:00 into an unstaffed queue produces a worse outcome than one that says when the team is next available and raises a ticket." JSM hat für genau diesen Fall SLA-Kalender, was dafür spricht, den Agenten direkt eine Anfrage anlegen zu lassen (nächster Abschnitt).

Ein BSP-Berater mit frühem Plattformzugang wies auf die Genauigkeitsseite hin:

"Consistency is a problem. I saw the same product come back at two different prices in two replies. If you don't ground it properly, it just makes things up. No third-party connectors yet. CRM, order systems, anything to actually complete a sale - not there yet."

u/Kira_SENPAI_1, Reddit

Seit diesem Beitrag vom Juli sind Connectors erschienen, und damit komme ich zu dem Teil, in dem sich JSM als überraschend guter Partner erweist.

Metas Agent mit der JSM-API verbinden: Die Auth passt tatsächlich

Business Agent führt Aktionen über Connectors aus, also HTTP-APIs oder Remote-MCP-Server, die du selbst definierst. Metas Connectors-Referenz sagt: „Currently, only OAUTH2_CLIENT_CREDENTIALS, API_KEY, and NONE are supported." An dieser Zeile sind die Freshdesk- und Gorgias-Varianten dieses Setups gescheitert, weil beide Basic Auth wollen, und bei Zoho Desk wurde es wegen der Refresh-Tokens fummelig.

Bei Atlassian ist es anders, und Servicekonten sind der Grund. Ich baue solche Connectors beruflich, es war also die schönste Überraschung des gesamten Recherchedurchgangs.

• Servicekonten unterstützen OAuth 2.0 Client Credentials. Laut Atlassians OAuth-Credential-Leitfaden sendest du client_id, client_secret und grant_type=client_credentials per POST an https://auth.atlassian.com/oauth/token und erhältst ein Bearer-Token, das „60 Minuten gültig" ist. Das ist genau der Grant, den Metas Typ OAUTH2_CLIENT_CREDENTIALS erwartet, mit Token-URL, Client-ID, Secret und form-urlencoded-Body.
• API-Tokens von Servicekonten nehmen Bearer. Atlassians Seite zu Servicekonto-Tokens sagt: „You can use Bearer token authentication or basic authentication in the HTTP header" am api.atlassian.com-Gateway, mit einer Laufzeit von 1 bis 365 Tagen. Das entspricht Metas API_KEY mit dem Präfix Bearer .
• Fünf gibt es kostenlos. Atlassian stellt „5 kostenlose einzelne Servicekonten" pro Organisation bereit, bis zu 250 mit Atlassian Guard Standard, und Servicekonten „zählen nicht auf dein Nutzerlimit".

Nicht passen die älteren Wege. Ein klassisches persönliches API-Token ist Basic Auth mit deiner E-Mail-Adresse, laut Atlassians API-Token-Doku, und Meta führt BASIC als nicht unterstützt. Du könntest versuchen, es in einen API_KEY-Header vorzucodieren, doch dann hängt der Bot am Konto einer echten Person. Und eine OAuth-2.0-App (3LO) kennt nur den Authorization-Code-Flow mit rotierenden Refresh-Tokens, die Metas Connector nicht speichern kann.

Die Tools, die du definieren würdest, und drei Stolperfallen

Ist die Auth geklärt, besteht der Connector aus wenigen JSM-REST-Aufrufen über die Request-API:

1. Die Anfrage erstellen. POST /rest/servicedeskapi/request mit serviceDeskId, requestTypeId und requestFieldValues. Metas eigenes Beispiel ist ein Tool create_support_ticket, dessen Zusammenfassung der Agent aus dem Chat füllt, und seine Makros können die WhatsApp-Telefonnummer und die Konversations-ID an Felder binden, damit der Agent sie nicht rät.
2. Den Status abfragen. Ein GET auf die Anfrage, damit der Agent „Gibt es etwas Neues zu meinem Laptop-Ersatz?" ohne Übergabe beantworten kann.
3. Einen Kommentar hinzufügen. Der Kommentar-Endpunkt nimmt einen booleschen Wert public. Kunden sehen nur öffentliche Kommentare, der Connector muss ihn also bewusst setzen.

Die Stolperfallen, alle aus Atlassians Doku:

• Die cloudId gehört in die URL. Tokens von Servicekonten funktionieren nur unter https://api.atlassian.com/ex/jira/{cloudId}/..., nicht unter yourcompany.atlassian.net. Die Basis-URL deines Connectors muss sie enthalten.
• Scopes sind heikel. Ein JSM-Nutzer stellte in einem Atlassian-Community-Thread fest, dass Servicekonto-Tokens zum Auflisten von Service Desks funktionierten, aber nicht für Anfragen, und gab die Antwort des Atlassian Supports weiter: „For fetching requests, the scope read:user:jira is required." Plane granulare JSM-Scopes plus read:user:jira ein.
• Kunden sind per E-Mail identifiziert. raiseOnBehalfOf „is not available to Users who have the customer permission only", und zum Anlegen eines Kunden braucht es die „Jira Administrator Global permission". Bei einem WhatsApp-Nutzer nur mit Telefonnummer erstellst du die Anfrage entweder als Servicekonto und legst die Nummer in ein Feld, oder du behältst diese Zuordnung in der Marketplace-App.

Und der Rovo MCP Server als MCP-Connector? Er akzeptiert Servicekonto-Schlüssel als Bearer-Tokens, wenn ein Admin die API-Token-Auth aktiviert, laut Atlassians MCP-Auth-Doku. Seine vier JSM-Tools sind aber Bereitschafts-Alarm-Tools, keine Anfrage-Tools, was mein Beitrag Claude für Jira Service Management genauer beleuchtet. Für einen Support-Connector ist der schlichte REST-Weg meiner Meinung nach einfach sauberer.

Meta benennt das Risiko stiller Fehler selbst in seinem Leitfaden: „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." Nutze den Test-Run-Endpunkt des Connectors, bevor du den Agenten etwas versprechen lässt.

Was es kostet: Meta Business Agent gegen die KI von JSM

Hier wird der Vergleich etwas schief, denn die drei KIs antworten nicht auf denselben Kanälen.

Zwei Dinge fallen auf. Die Einheit des Virtual Service Agent ist breiter, als sie aussieht: Atlassian zählt eine Konversation als unterstützt, wenn sie „einer Absicht zugeordnet wurde, unabhängig davon, ob der Virtual Service Agent das Problem löst oder eskaliert". Auch ein eskalierter Chat wird also berechnet. Und Metas Agent ist der einzige der drei, der tatsächlich auf WhatsApp antwortet, weshalb ein JSM-Team, das WhatsApp braucht, immer wieder bei ihm landet. Die Erklärung zu Atlassian Intelligence und Rovo-Preisen und der Beitrag Lohnt sich JSM AI? gehen auf der Atlassian-Seite tiefer.

Frühe Business-Agent-Nutzer bemerkten die Rechnung pro Nachricht schnell:

"My concern is that the per-message cost is insanely high at approximately 5 cents per message."

u/Aromatic-Surround167, Reddit

Vergiss die Marketplace-App obendrauf nicht. Jede Brücken-App wird über Atlassian pro Nutzer abgerechnet, und bei einem Projekt mit 50 Agenten lohnt es sich, diesen Posten zu prüfen, bevor du die KI-Rechnung ansiehst.

Der 1. Oktober verändert die Rechnung für die Antworten deiner Agenten

Was die meisten JSM-Teams auf WhatsApp tatsächlich spüren werden, ist nicht der KI-Preis. Ab dem 1. Oktober 2026 berechnet Meta Service-Nachrichten pro Nachricht, nach 1.000 kostenlosen pro Telefonnummer und Monat. Metas Preisseite sagt, jede Nachricht werde „entweder als Meta-Business-Agent-Nachricht oder als Service-Nachricht abgerechnet, nie beides".

Für ein JSM-Setup heißt das: Jede Antwort, die ein Agent aus einem Arbeitselement über die Marketplace-App sendet, wird zur kostenpflichtigen Service-Nachricht, sobald die Nummer das Freikontingent überschreitet. Metas Agent zu wählen, umgeht das nicht. Es ändert nur, wer die ersten Antworten schreibt: Business-Agent-Nachrichten werden als Tokens abgerechnet, und alles, was dein Team nach der Übergabe sendet, als Service-Nachrichten. Wie der App-Anbieter diese Gebühren weiterreicht (ein Meta-Konto, das dir gehört, oder Guthaben bei einem BSP wie Infobip), solltest du vor dem 1. klären. Meine Erklärung zu den WhatsApp-API-Preisen enthält den vollständigen Preisverlauf, und der Beitrag zu den Meta-Richtlinienänderungen zeigt, was Meta bei Drittanbieter-Bots getan hat.

Einen eigenen JSM-Bot auf Muse Spark bauen

Der dritte Weg überspringt Business Agent und baut direkt auf dem Modell auf. Er liegt meinem Berufsalltag am nächsten, ich kann also sagen, was er wirklich bedeutet.

Beim Modell kostet Muse Spark 1.3 in der Standardstufe 1,25 $ Input und 4,25 $ Output pro 1 Mio. Tokens (Meta-Model-API-Doku). Die günstigere Contributor-Stufe scheidet für Support aus, denn Metas Bedingungen besagen: „You must not submit sensitive, confidential, or personal information to the Discounted Services." Eine JSM-Anfrage steckt voller Namen, E-Mail-Adressen und Gerätenummern. Mein Muse-Spark-1.3-Test zeigt, wo das Modell stark ist.

Auf der JSM-Seite ist alles Übrige deine Sache:

1. Die WhatsApp-Brücke. Du brauchst weiterhin eine Marketplace-App oder eine eigene Cloud-API-Integration, um Nachrichten hinein- und Antworten hinauszubekommen, denn JSM tut das nicht.
2. Auth. Ein Servicekonto mit Client Credentials, die cloudId in deiner Basis-URL und alle 60 Minuten ein Token-Refresh. Ehrlich gesagt der einfache Teil des Ganzen.
3. Wissen. Confluence-Seiten, Anfrageverlauf und gelöste Kommentare, synchron gehalten. Hier greifen Ratenlimits: Atlassians punktebasierte Limits gelten seit dem 2. März 2026 auch für OAuth-Apps.
4. Die Schleife. Die Anfrage lesen, eine Antwort oder einen internen Kommentar entwerfen, Anfragetyp und Bearbeiter setzen. Für eine erste Version würde ich nur interne Kommentare schreiben lassen, damit nichts ohne einen Menschen zum Kunden gelangt.
5. Eskalation und Tests. Eine eigene Konfidenzschwelle, dazu ein Replay echter Anfragen, bevor irgendetwas live geht. Mein Leitfaden Selbst bauen oder kaufen enthält die vollständige Liste.

Ich habe viele Teams beim Abwägen dieses Wegs beobachtet, und mein Rat ist immer derselbe: Rechne auch die Wartung mit, nicht nur den Bau. Denselben Bau auf anderen Modellen behandeln Grok für Jira Service Management und ChatGPT für Jira Service Management.

Wo Metas Agent für ein JSM-Team endet

Nichts davon ist versteckt, es steht alles in Metas eigenen Docs, aber es trifft härter, wenn dein Team in JSM lebt:

• Er antwortet nur in Metas Apps. Dein JSM-Projekt nimmt auch Portal, E-Mail, Slack und Teams entgegen. Business Agent deckt keinen davon ab, du würdest also zwei KIs mit zwei Regelwerken betreiben. Mein Beitrag zum KI-Chatbot für JSM behandelt den Rest.
• Dein Anfrageverlauf ist keine Wissensquelle. Metas Support-Leitfaden rät dir, „die häufigsten Themen deines Helpdesks aus dem letzten Quartal zu exportieren" und FAQ-Einträge von Hand zu schreiben. Deine Confluence-Wissensdatenbank und Jahre gelöster Anfragen bleiben außer Reichweite.
• Er kennt deine SLAs und Anfragetypen nicht. Der Wert von JSM ist Struktur: Anfragetypen, Queues, SLA-Uhren, Genehmigungen. Metas Agent sieht einen Chat, kein Service-Projekt, solange dein Connector es ihm nicht beibringt.
• Regulierte Branchen sind ausgeschlossen. Unternehmen aus Finanzen, Gesundheit, Behörden, Alkohol oder Glücksspiel dürfen die Plattform nicht nutzen.
• Die Genauigkeit braucht weiterhin Grundlagen. Metas Hilfecenter warnt: „Some AI messages may be inaccurate or inappropriate."

Ein Kommentator in r/WhatsappBusinessAPI brachte die Grenze gut auf den Punkt:

"If you look at the current AI agent closely, it can only do things inside Meta, but nothing outside it."

u/Ok_West333, Reddit

Das ist mehr oder weniger die Neurahmung, die ich einem JSM-Team mitgeben würde. Metas Agent ist eine Eingangstür für WhatsApp. JSM ist der Ort, an dem die Arbeit wirklich liegt, mit Anfragetypen, SLAs und Verlauf, und die KI, die sich ihren Platz verdient, ist die, die dort arbeitet.

Welches Setup zu deinem JSM-Team passt

So würde ich wählen, je nachdem, wo deine Anfragenden schreiben und wie dein Team arbeitet.

Bei den meisten JSM-Teams, mit denen ich spreche, trifft die erste oder die dritte Zeile zu. Entweder ist WhatsApp gar kein Kanal, oder es ist ein Kanal unter mehreren, und der Anfragende, der auf WhatsApp schreibt, per E-Mail nachfasst und später im Portal kommentiert, braucht all das in einer Anfrage. Die Wahl der KI innerhalb von JSM ist deshalb am Ende wichtiger als die Meta-Frage.

Wenn du diese vergleichst, sind mein Vergleich beste KI für JSM und die Übersicht zu JSM AI gute nächste Lektüre.

Die Liste der JSM-Alternativen hilft, wenn du das Tool selbst überdenkst, und beste KI für WhatsApp-Support behandelt WhatsApp über Helpdesks hinweg.

eesel in Jira Service Management ausprobieren

eesel ist ein KI-Helpdesk-Teammitglied, das Jira Service Management beitritt wie ein neuer Mitarbeiter. Es übernimmt eine Anfrage, wenn jemand sie stellt oder kommentiert, liest den Verlauf, sucht verwandte Vorgänge und antwortet dann dem Melder, hinterlässt eine interne Notiz, bewegt den Vorgang weiter, weist ihn zu oder versieht ihn zur Triage mit Labels. Es lernt aus deinem Help Center, Confluence und früheren Anfragen und folgt Anweisungen in einfacher Sprache dazu, welche Anfragen es anfassen darf.

Es läuft bereits im großen Maßstab auf JSM: Design.com bearbeitet damit über 50.000 Anfragen im Monat, und Kim Simpson von Gridwise sagte auf eesels JSM-Seite: „In the first month, eesel is resolving 73% of our tier 1 requests." Es antwortet auch selbst auf WhatsApp. Wenn du also lieber eine KI für WhatsApp und deine JSM-Queue hättest, kann es den einen KI-Platz der Nummer statt Metas Agent belegen. Die Preise sind ein fester monatlicher Credit-Tarif, bei dem eine Anfrage oder ein Chat als ein Credit zählt, egal wie viele Antworten es braucht.

Wenn du es lieber skriptest, kannst du mit dem eesel CLI selbst oder über einen Coding-Agenten wie Claude Code oder Cursor eesel integrations connect jira ausführen, eesel status prüfen und eesel automations auflisten, direkt aus dem Terminal, gegen dasselbe Teammitglied, das du im Dashboard einrichten würdest.

eesel testen, kostenlos mit 100 Credits und ohne Karte, und sieh, wie es deine JSM-Anfragen bewältigt, bevor die WhatsApp-Preisänderung vom 1. Oktober greift.