Claude für Jira Service Management: vier JSM-Tools, keines für Tickets

Atlassian hat das gemacht, was alle anderen noch versprechen

Ich baue KI-Agenten bei eesel, was in der Praxis bedeutet, dass ich beruflich die Tool-Spezifikationen anderer Leute lese. Die Frage „Kann ich Claude auf unseren Helpdesk richten" war dieses Jahr mit Abstand die häufigste in meinem Posteingang. Die Antwort ist meist irgendeine Variante von Nein.

Als ich Claude für Zendesk geprüft habe, hatte Zendesk einen MCP-Client geliefert, keinen Server. Freshdesk sitzt hinter einem Early-Access-Programm. Gorgias hat dafür überhaupt keinen Marketplace-Eintrag. Help Scout hat tatsächlich einen echten Server ausgeliefert, ihn dann aber absichtlich nur lesend gemacht.

Atlassian hat es einfach gebaut. Auf der Rovo-MCP-Seite gibt es ein Kachelraster von KI-Clients, und Claude ist eines von vieren, neben Cursor, VS Code und ChatGPT. Der Fließtext nennt es direkt: bleib im Flow, „egal ob du Kontext aus Atlassian in Claude brauchst". Ein Anbieter, der seine eigenen Kunden absichtlich auf das Modell eines anderen verweist, auf seiner eigenen Marketing-Seite.

Auch das Zugangsmodell ist ungewöhnlich großzügig. Atlassians eigene FAQ sagt „Alle Atlassian-Cloud-Kunden haben Zugang". Dein Plan ändert nur den Durchsatz: Free-Sites bekommen 500 Aufrufe pro Stunde, Standard 1.000, und Premium oder Enterprise bekommen 1.000 plus 20 weitere pro Nutzer, bis zu einer Obergrenze von 10.000. Ein Rovo-Abo ist ebenfalls nicht nötig, denn wie Atlassian es formuliert, ist der Server „kein KI-Modell, sondern eine Integrationsschicht".

Dieser Beitrag ist also keine Abrechnung. Es ist das, was ich mir gewünscht hätte, jemand hätte es mir gesagt, bevor ich einen Nachmittag damit verbracht habe, einen Service Desk zu erwarten und stattdessen einen Aufgaben-Tracker zu bekommen.

Die vier Wege, Claude mit Jira Service Management zu verbinden

Es gibt vier Wege. Sie sortieren sich entlang einer Achse, die mehr zählt als alle anderen zusammen: ob das Ding Worte vor die Person bringen kann, die das Ticket aufgegeben hat.

Die Form dieses Diagramms ist das ganze Argument. Der sofortige, offizielle, kostenlose Weg ist genau der, der einem Anfragenden nicht antworten kann. Derselbe Trade-off, den ich bei Help Scout gefunden habe, auch wenn Atlassian aus einer anderen Richtung dorthin kommt. Help Scout hat absichtlich nur lesend ausgeliefert. Atlassian hat Schreibrechte ausgeliefert und sie dann nie auf den Service Desk gerichtet.

Weg 1: der offizielle Server, von Anfang bis Ende

Der Endpunkt ist eine einzelne Zeichenkette:

https://mcp.atlassian.com/v1/mcp/authv2

Eine Warnung, bevor du eine ältere Konfiguration von irgendwoher hineinkopierst. Atlassian hat den alten SSE-Transport abgeschaltet: nach dem 30. Juni 2026 wird https://mcp.atlassian.com/v1/sse nicht mehr unterstützt. Dieses Datum ist bereits vergangen. Wenn du also eine Konfiguration aus dem Blogbeitrag eines Kollegen vom Frühjahr geerbt hast, ist sie tot, und das Symptom sieht eher wie ein Auth-Fehler aus als eine Abschaltung.

Für Claude Code ist es ein einzelner Befehl:

claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2

Dann /mcp, um den OAuth-Flow auszuführen. In Claude Desktop führt der Weg über Settings, Extensions, Browse extensions, Plugins, Suche nach Atlassian. Und auf claude.ai sitzt der Atlassian-Eintrag im Connector-Verzeichnis, beschrieben als Lesen und Schreiben, gebaut von Atlassian.

Ein Implementierungsdetail bringt Leute schon beim allerersten Aufruf zu Fall. Jedes Tool will eine cloudId, und der Weg, an eine zu kommen, ist getAccessibleAtlassianResources, was Atlassian als erforderlichen ersten Aufruf für jedes Tool beschreibt. Wenn du ihn überspringst und Claude direkt auf searchJiraIssuesUsingJql feuern lässt, liest sich die zurückkommende Fehlermeldung wie ein Berechtigungsproblem. Ist es nicht.

Das andere, was man am ersten Tag wissen sollte: Claude erreicht deinen MCP-Server aus Anthropics Infrastruktur, nie von deinem Laptop aus. Das gilt auch in Claude Desktop. Wenn deine Atlassian-Site also hinter einer IP-Allowlist sitzt, schlagen die Tool-Aufrufe fehl, während der OAuth-Zustimmungsbildschirm trotzdem ganz problemlos erscheint – das ist wohl der verwirrendste Fehlermodus, den es gibt.

Weg 2: die vier JSM-Tools, und die Token-Schranke davor

Jetzt zu dem Teil, der mich innehalten und die Seite zweimal lesen ließ.

Atlassian veröffentlicht rund 46 Tools, verteilt auf 13 Berechtigungsgruppen. Jira bekommt 14. Confluence bekommt 12, Bitbucket ebenfalls 12, Compass 10. Jira Service Management bekommt vier:

Jedes einzelne davon lebt auf der Ops-Seite, dem Teil von JSM, der vom Bereitschaftsalarmierung abstammt. Kein einziges berührt den Service Desk. Es gibt kein veröffentlichtes Tool für Anfragen, Anfragetypen, Warteschlangen, SLAs, Genehmigungen, Portal-Kunden oder Portal-Konfiguration.

Und selbst vor diesen vieren steht eine zweite Schranke. Atlassians Seite zu unterstützten Tools besagt, dass JSM-Tools „nur die Authentifizierung per API-Token unterstützen" und „nur verfügbar sind, wenn die Authentifizierung per API-Token von deinem Organisations-Admin aktiviert wurde". OAuth ist unterdessen der Standard-Flow, und der empfohlene. Das praktische Ergebnis für die meisten Leute also: ein normaler Claude-Login zeigt keines der JSM-Tools an, und nichts in der Oberfläche erklärt, warum.

Compass läuft übrigens nach der umgekehrten Regel: nur OAuth, kein API-Token. Bitbucket will ein API-Token und einen verknüpften Workspace. Drei Produkte, drei verschiedene Auth-Regeln, alle in einem Server.

Was du in einem Service Desk tatsächlich erreichen kannst

Das alles heißt nicht, dass Claude blind für deine Tickets ist. Ein JSM-Projekt ist im Kern ein Jira-Projekt, also funktionieren die generischen Jira-Tools darauf. getVisibleJiraProjects, getJiraIssue, searchJiraIssuesUsingJql, getTransitionsForJiraIssue, transitionJiraIssue, editJiraIssue und addCommentToJiraIssue funktionieren allesamt ganz problemlos auf JSM-Arbeitsobjekten.

Diese Unterscheidung zählt mehr, als sie klingt. Atlassians eigene Dokumentation ist unverblümt darüber, was ein Anfragetyp bringt: „Wenn du ein Arbeitsobjekt ohne Anfragetyp erstellst, haben deine Anfragen keinen Zugriff auf alle Jira-Service-Management-Funktionen." Claude schaut auf die Jira-Schicht unter dem Service Desk, nicht auf den Service Desk selbst. Wo deine Agenten eine Anfrage mit SLA-Uhr, Warteschlange, Portal und angehängtem Kunden sehen, sieht Claude ein Arbeitsobjekt.

Die schärfste Version dieser Lücke sind Kommentare. In der Service-Desk-API läuft die Kundensichtbarkeit auf genau ein Boolean im Kommentar-Body hinaus:

POST /rest/servicedeskapi/request/{issueIdOrKey}/comment
{ "body": "Hello there", "public": true }

public: true ist eine Antwort, die der Anfragende im Portal sieht. public: false ist eine interne Notiz, nur für Agenten. Kein separater Endpunkt, kein Sichtbarkeitsobjekt, nur das Flag. Und das MCP-Tool addCommentToJiraIssue führt in seiner veröffentlichten Beschreibung kein entsprechendes Argument, was bedeutet, dass Claude keine Möglichkeit hat, festzulegen, ob die Worte, die es schreibt, für den Anfragenden gedacht sind. Auf einem IT-Desk ist das keine fehlende Nettigkeit. Es ist der Unterschied zwischen einer Notiz an deinen Kollegen und einer E-Mail an eine Führungskraft.

Gut zu wissen, falls du später doch den API-Weg gehst: Die Service-Desk-Kommentar-Ressource legt nur GET und POST offen. Kein PUT, kein DELETE. Einen Kommentar zurückzuziehen bedeutet, auf die Jira-Plattform-API unter /rest/api/3/issue/{id}/comment/{id} auszuweichen, mit entweder der Berechtigung Eigene Kommentare bearbeiten oder Eigene Kommentare löschen. Plane das Rückgängigmachen, bevor du es brauchst.

Weg 3: die Service-Desk-REST-API, wenn du sie selbst baust

Wenn du das warteschlangen-, SLA- und kundensichtbare Verhalten willst, schreibst du es selbst gegen /rest/servicedeskapi/. Das ist ein echtes Projekt und kein Wochenende, und drei Dinge werden das Design mehr prägen, als man erwartet.

Rate-Limits sind drei Systeme gleichzeitig, und Atlassian sagt, deine Integration „muss alle drei handhaben". Ein punktebasiertes Stunden-Kontingent, Pro-Sekunde-Burst-Limits, dann noch Pro-Ticket-Schreiblimits obendrauf. Der Standard-Global-Pool liegt bei 65.000 Punkten pro Stunde, geteilt über Mandanten hinweg; ein Pro-Mandant-Pool reicht von 65.000 auf Free bis 150.000 plus 30 pro Nutzer auf Enterprise, gedeckelt bei 500.000. Burst-Standardwerte liegen bei 100 Anfragen pro Sekunde bei GET und POST, und 50 bei PUT und DELETE. Pro-Ticket-Schreibvorgänge sind auf 20 in zwei Sekunden und 100 in dreißig gedeckelt. Und ein Endpunkt ist deutlich enger als alle anderen: GET /servicedeskapi/servicedesk/{id}/customer ist auf 5 Anfragen pro Sekunde gedrosselt, und das wird die erste Wand sein, gegen die du bei jedem Kunden-Backfill läufst.

Stille Berechtigungsfehler. Atlassian dokumentiert, dass bei GET /request/{id}/comment „kein Berechtigungsfehler angezeigt wird, falls der Nutzer beispielsweise keinen Zugriff auf den Service Desk oder die Anfrage hat, die Methode gibt einfach eine leere Antwort zurück". Ein Agent, der keine Kommentare liest und dann daraus schließt, es gäbe keine, beantwortet also mit voller Zuversicht die falsche Frage.

Zugriff auf die Wissensdatenbank ist nur Suche. GET /rest/servicedeskapi/knowledgebase/article liefert Artikel, die zu einer Anfrage passen, pro Service Desk oder über alle hinweg, und query ist Pflicht. Nichts in diesem Namensraum ruft den vollständigen Text eines Artikels ab, sodass die Verankerung in deiner Wissensdatenbank einen zweiten Ausflug zur Confluence-API bedeutet. Die gute Nachricht: Beide KB-Endpunkte sind von den App-Zugriffsregeln ausgenommen, anders als jeder Anfrage- und Kommentar-Endpunkt.

Was eine einzelne JSM-Antwort tatsächlich kostet

Hier wird die Nur-Lesen-Grenze finanziell interessant. Tokens sind billig, und was sie kaufen, ist schmal.

Eine fundierte Antwort läuft auf grob 12.000 Input-Tokens hinaus, sobald du das Ticket, die Übergänge und zwei Confluence-Seiten gezogen hast, plus etwa 700 Output-Tokens auf dem Rückweg. Auf Claude Sonnet 5 bei 2 $ und 10 $ pro Million sind das etwa 3,1 Cent. Näher an 1,3 Cent, sobald Prompt-Caching seine Arbeit tut, bei 0,20 $ pro Million gecachte Reads. Auf Claude Opus 5 bei 5 $ und 25 $ landet dieselbe Antwort näher an 7,8 Cent.

Jetzt die Vergleiche. Atlassians eigener Virtual Agent enthält 1.000 unterstützte Gespräche pro Monat, dann berechnet er ab 0,30 $ pro Stück danach, und ein Gespräch, das einer Absicht zugeordnet und dann an einen Menschen eskaliert wird, wird trotzdem berechnet. Rovo-Credits sind ein separates, eigenes Zählwerk: Standard bekommt 25 pro Nutzer und Monat, Premium 70, Enterprise 150. Die Beta-Teamwork-Graph-Tools im MCP-Server sind heute kostenlos, aber Atlassian hat gesagt, sie „werden bei allgemeiner Verfügbarkeit mit mindestens 1 Rovo-Credit pro Aufruf abgerechnet", mit 90 Tagen Vorlauf.

Eine Warnung, bevor du irgendeine Pro-Gespräch-Zahl für bare Münze nimmst, von einem IT-Manager, der das Thema direkt zum Produktteam gebracht hat:

"One example: virtual agent will count a ticket as "successfully deflected" if the user gives up responding and it auto closes. That's not a successful deflection, that's an awful user experience."

u/Goose-tb, r/ITManagers

Das lohnt sich, gegen jedes Tool zu prüfen, das du wählst, unseres eingeschlossen. Eine Deflection-Rate, die Abbruch als Sieg zählt, misst das Falsche, und es ist die Zahl, die dir am wahrscheinlichsten in einem Vertragsverlängerungsgespräch zitiert wird.

Setz deine eigenen Zahlen ein:

Die ehrliche Lesart dieser drei Zahlen: Die Token-Spalte ist am billigsten, weil sie am wenigsten kauft. Keine Antwort-Pipeline, kein Sichtbarkeits-Flag, kein Warteschlangen-Routing, kein SLA-Bewusstsein, und keine Möglichkeit, sich selbst zu testen, bevor sie auf einen echten Anfragenden trifft. Das mit einem Pro-Anfrage-Preis zu vergleichen, ist wie einen Recherche-Assistenten mit einem Agenten zu vergleichen. Nützlich. Nicht derselbe Job.

Die Admin-Seite, und warum sie „Zugriff verweigert" sagen wird

Vier separate Dinge müssen alle wahr sein, bevor ein einziger Tool-Aufruf ankommt. Jedes davon scheitert anders.

1. Die KI-Domain muss erlaubt sein. Atlassian liefert eine Standardliste von KI-Partner-Domains, Claude und ChatGPT eingeschlossen. Admins können sie erlauben oder blockieren, aber Atlassian ist explizit: „Du kannst keine einzelnen Domains blockieren. Du kannst nur die gesamte Domainliste erlauben oder blockieren." Was keinen Weg lässt, Claude zu erlauben und alles andere abzulehnen.
2. Die IP muss die Allowlist passieren, und das hier ist fies, denn „der OAuth-2.1-Zustimmungsbildschirm kann bei Nutzern von blockierten IPs trotzdem erscheinen, aber Tool-Aufrufe schlagen fehl". Die Verbindung sieht bis zu dem Moment erfolgreich aus, in dem sie nichts tut.
3. Die Auth-Methode muss erlaubt sein. API-Token-Auth ist ein organisationsweiter Schalter, und genau dieser Schalter entscheidet, ob die JSM-Tools für dich überhaupt existieren. Domain-Blocking gilt übrigens nicht für API-Token-Verbindungen.
4. Der Netzwerk-Egress muss *.atlassian.net erreichen, da der Server interaktive Jira- und Confluence-Widgets im KI-Client über iframes rendert.

Obendrauf lässt ein Berechtigungen-Tab Org-Admins jetzt Lesen, Schreiben und Suchen unabhängig pro App erlauben oder blockieren, und Atlassian sagt, das „hat Vorrang vor Einstellungen in Connected Apps". Es gibt auch einen „Auf zukünftige Ergänzungen anwenden"-Umschalter. Der still bedeutet, dass neu hinzugefügte Berechtigungen ein Erlauben erben können, ohne dass jemand sie überprüft. Falls du die Person bist, die Zugriffsreviews absegnet, lohnt sich ein Blick auf diesen Schalter.

Zwei Compliance-Fakten für dein Sicherheitsteam, bevor sie überhaupt fragen. Der Server speichert und cacht keine Jira- oder Confluence-Inhalte, und er läuft strikt innerhalb der Berechtigungen des angemeldeten Nutzers, was ein besserer Standard ist als bei den meisten Connectors. Aber Atlassian gibt an, dass er „derzeit keine FedRAMP- oder HIPAA-Anforderungen unterstützt", und er ist nur Cloud, keine Data-Center- oder Server-Option veröffentlicht. Für viele regulierte IT-Service-Desks beenden diese zwei Sätze die Prüfung dann und dort.

Womit die Leute tatsächlich zu kämpfen haben

Die lauteste Beschwerde geht nicht um Tools oder Credits. Es geht darum, dass das Token ständig abläuft. Ein Atlassian-Community-Thread mit dem Titel „The MCP Auth expires too fast" läuft von Oktober 2025 bis März 2026, mit rund 16.500 Aufrufen und ohne Lösung, und ist voller Claude-Code-Nutzer:

"Bump! I need to reauthenticate sometimes once an hour, sometimes once every 10-20 minutes. This morning I authenticated the MCP connection then sent my prompt, 12 minutes later claude code was getting a 401 response and I only had a single terminal session open. This is basically unusable, I guess I'll just need to build some custom tools to utilize the API."

Aaron Kirn, Atlassian Community

Ein Community Champion im selben Thread nennt die Ursache klar: Der Server stellt kurzlebige OAuth-Tokens aus, externe Clients können sie nicht automatisch erneuern, und langlebige Tokens sind noch nicht ausgeliefert. Zwei Dinge folgen daraus, wenn du Agenten betreibst statt nur zu chatten.

Parallele Sessions bekämpfen sich gegenseitig. Mehrere Leute berichten, dass sich das Authentifizieren in einem Fenster still die anderen abmeldet, was jeden Multi-Agenten-Workflow zur Qual macht. Und der neuere /mcp-Endpunkt scheitert leiser als der alte: Ein Nutzer merkte an, dass /sse wenigstens einen 401 warf, den man abfangen konnte, während der Ersatz „einfach still versagt". Wenn du Retries verdrahtest, fang das leere Ergebnis ab, nicht nur den Fehlercode.

Tool-Qualität hat ihren eigenen Thread, und das ist der Teil, den ich nicht erwartet hatte. Ein Atlassian-PM, der am MCP-Server arbeitet, antwortete auf Reddit, offiziell:

"Tool quality - the problem you mention where the Jira create tool doesn't respect required fields is something we just need to fix. We've been moving quickly to release a broad range of tools, and now we need to go back and fix some of those pain points. Tool descriptions included. You'll see some improvements here soon Context bloat - we acknowledge this is a problem as well. There are many more tools we want to provide but the current design is already at it's limit."

u/atlassiadam, Atlassian PM, r/mcp

Credit-Angst ist das andere große Thema, und dabei geht es hauptsächlich um Rovo statt um MCP. Ein Bitbucket-Nutzer berichtete, dass ein einziges Pull-Request-Review fast die Hälfte eines Monatskontingents gefressen hat:

"Rovo had a look at the PR and made a few suggestions and in doing so appeared to use 965 of my 2000 credits with 760 being marked as 'Code review in Bitbucket', I'm not sure where the other 205 went?? Either I'm doing something amazingly wrong or that's not value for money at all."

Chris Mingay, Atlassian Community

Ein Atlassian-Product-Manager antwortete in diesem Thread und stimmte zu, dass die Rechnung happig ist, was fair und ungewöhnlich offen ist. Dieselbe Sorge taucht auf Reddit auf, wo ein Nutzer im Standard-Plan den Vergleich laut angestellt hat:

"advertised ($0.01 per credit after the initial 2000), copilot is a mere $10 for 300 claude 4.5 requests why is it so expensive? the free tier..."

Rovo Dev credits, r/RovoDev

Derselbe Poster beschrieb, dass er drei Viertel von 2.000 Credits innerhalb weniger Stunden verbrannt hat, über nicht mehr als 30 Anfragen.

Genau dieser Kontext ist der Grund, warum das Preismodell des MCP-Servers sich heute wie eine Erleichterung liest statt wie eine Sorge. Und genau deshalb verdient die Teamwork-Graph-Abrechnungsnotiz einen Kalendereintrag. Kostenlos-mit-deinem-Plan ist ein ganz anderes Produkt als abgerechnet-in-Credits, und Atlassian hat dir bereits gesagt, in welche Richtung sich zwei dieser Tools bewegen.

Wie ich tatsächlich entscheiden würde

Wenn dein Ziel Analyse, QA, Vorfallsberichte oder das Stellen von Fragen über Jira und Confluence hinweg an einem Ort ist, installier den Connector heute. Es ist das beste kostenlose Jira-KI-Plugin, das ich dieses Jahr getestet habe. Kostenlos, offiziell, das Berechtigungsmodell ist solide, und nur-lesend-in-der-Praxis ist ein Feature, wenn du zum ersten Mal eine KI auf einen produktiven Desk richtest. Das stärkste kostenlose Ding in der Kategorie, und ich würde niemanden davon abbringen.

Wenn dein Ziel Bereitschaftsdienst ist, verdienen sich die vier JSM-Tools ihren Platz, und es lohnt sich, mit deinem Admin über die Aktivierung der API-Token-Auth zu sprechen. Alarme direkt aus einem Chat-Fenster zu bestätigen und zu eskalieren, ist ein echter Workflow.

Wenn dein Ziel ist, Tier-1-Anfragen abzuarbeiten, damit dein Team aufhört, dieselbe VPN-Frage zu beantworten, ist der Connector nicht dieses Tool, und keine Menge an Prompting wird ihn dazu machen. Was du brauchst, ist etwas, das /rest/servicedeskapi/ spricht, den Unterschied zwischen einer öffentlichen Antwort und einer internen Notiz kennt, die Warteschlange und die SLA-Richtlinie respektiert, die du bereits konfiguriert hast, Eskalation sauber handhabt, und sich gegen Anfragen testen lässt, die bereits passiert sind, bevor es auf eine trifft, die es noch nicht getan hat. Meine Übersicht zur besten KI für ITSM deckt das Feld ab, wenn du es richtig durchsehen willst.

eesel AI für Jira Service Management

Genau diesen letzten Job bauen wir. eesel tritt deinem Service Desk als echter KI-Agent bei, nicht als seitlich angeschraubtes Widget. Es liest Anfragen, entwirft und versendet Antworten, fügt interne Notizen hinzu, aktualisiert Anfragefelder, setzt Priorität und routet an Teams, alles innerhalb der Zuweisungsregeln und SLA-Richtlinien, die du bereits hast.

Der Teil, der mir am wichtigsten wäre, wenn ich das auf einem echten Desk bewerten würde, ist die Simulation. Du spielst deine vergangenen Anfragen ab, bevor irgendetwas an eine echte herangeht, bekommst Abdeckungsprozente nach Thema aufgeschlüsselt, füllst welche Lücken auch immer der Durchlauf aufdeckt, und startest erst, wenn die Zahl gut genug ist. Wir haben das gebaut, weil wir gesehen haben, wie selbstsicher klingende Bots auf den Warteschlangen anderer Leute falsche Antworten geben, und ein Testlauf über deine eigene Historie ist der einzige ehrliche Weg, das vorher herauszufinden.

Für ein Gefühl dafür, wie das auf einem internen Support-Desk aussieht: InDebted betreibt JSM für ein 5- bis 10-köpfiges IT-Team, das Hunderte Mitarbeiter über fünf Märkte hinweg unterstützt. Ihr Wissen kommt aus Confluence und aus einem Slack-Bot:

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Jason Loyola, IT Team, InDebted, eesel case study

Heute liegen sie bei 15 % der eingehenden Jira-Tickets abgewehrt, mit 55 % als Ziel, sobald sich die Wissensdatenbank füllt. Eine echte Zahl von einem echten Desk, keine Demo-Zahl. Und der ehrliche Teil ist, dass es bei 15 % angefangen hat, nicht bei 55 %.

Die Preisgestaltung liegt bei 0,40 $ pro bearbeiteter Anfrage. Abgerechnet pro Anfrage statt pro Antwort, sodass ein Fünfzehn-Nachrichten-Hin-und-Her trotzdem als eine Abrechnung zählt. Zum Start gibt es 50 $ kostenlose Nutzung ohne Karte, was auf 125 Anfragen hinausläuft, mit jedem Feature freigeschaltet.

Wenn dein Service Desk irgendwo anders als in JSM lebt, läuft derselbe Agent auf Zendesk und sechs weiteren Helpdesks.

Nutze den Atlassian-Connector fürs Denken. Für das Antworten nutze etwas, das die Service-Desk-API spricht. Unterschiedliche Jobs, und die gute Nachricht ist, dass du dich 2026 nicht mehr für nur eines entscheiden musst.