Zendesk KI Confluence Integration: zwei Wege, dein Wiki anzubinden

Warum deine Zendesk KI dein Wiki noch nicht sehen kann

Ich baue beruflich Integrationen, daher prüfe ich bei jeder "KI fürs Helpdesk"-Behauptung zuerst, woraus sie eigentlich liest. Bei Zendesks nativen KI-Agenten lautet die Standardantwort: dein Help Center. Das ist in Ordnung, wenn dein Help Center umfassend ist. Das ist es selten. Die polierten, kundenzugewandten Artikel sind eine Sache; die Antwort auf ein kniffliges Ticket steht meist auf einer Confluence-Seite, die ein Support-Lead fürs Team geschrieben hat, nicht für die Öffentlichkeit. Confluence hat sogar seine eigene KI-Suche und Copilot, aber keins von beidem hilft einem Kunden, der in einem Zendesk-Ticket sitzt.

Ich habe das bei einer Support-Managerin eines Bus-Tracking-Dienstes mit 200 bis 250 Zendesk-Tickets im Monat erlebt. Ihre gesamte Wissensdatenbank war für Administratoren geschrieben, doch die Tickets kamen von Fahrgästen, einer völlig anderen Zielgruppe. Die KI antwortete selbstbewusst aus dem falschen Material, weil das das einzige Material war, das sie sehen konnte. Nicht das Modell war das Problem. Es war die Wissensgrenze.

Die eigentliche Frage lautet also nicht "Ist Zendesks KI gut", sondern "Kann ich sie auf das Wiki richten, in dem die guten Antworten wirklich liegen." Hier sind die zwei Routen, nebeneinander.

Route A: Confluence mit Zendesks nativer KI verbinden

Zuerst die gute Nachricht, weil sie real ist: Zendesk unterstützt Confluence tatsächlich nativ. In der eigenen Connector-Dokumentation ist Confluence ein benannter, eigener Knowledge-Connector, neben Google Drive, SharePoint, Notion, Guru, Salesforce und einem universellen REST-Connector für alles andere. Du richtest ihn auf eine Confluence-Site, wählst die gewünschten Spaces, und dieser Content wird über Zendesks Wissens-Erlebnisse hinweg nutzbar.

Connectors, föderierte Suche und der Knowledge Graph

Man muss sich klarmachen, dass das drei unterschiedliche Mechanismen sind, und genau diese Verwechslung ist es, worüber Teams stolpern.

• Knowledge-Connectors ziehen den tatsächlichen Inhalt einer Quelle (deine Confluence-Spaces) in Zendesk, wo er generative KI-Antworten speisen kann, über die generative Suche im Help Center, Agent-Workspace-Schnellantworten und KI-Agent-Antworten hinweg. Das ist der Connector, den man für Confluence will.
• Föderierte Suche indiziert externe Seiten, damit sie als Links in Help-Center-Suchergebnissen und im Agent-Kontextbereich auftauchen. Sie macht Content sichtbar; allein reicht sie nicht als generativer Antwortweg.
• Knowledge Graph ist der Marketing-Oberbegriff, der alles auf der Zendesk-Knowledge-Seite zusammenbindet. Es ist ein Name für das System, keine vierte Einstellung, die man konfiguriert.

Für KI-Agenten speziell ist externer Content auf den Stufen Essential und Advanced verfügbar, laut Zendesks Dokumentation zu externem Content. Der Connector allein ist also nicht die ganze Geschichte; der Agent muss auf einer Stufe sein, die ihn nutzen kann.

Was es tatsächlich kostet

Hier klaffen Listenpreis und tatsächlicher Preis auseinander. Das Verbinden externen Contents ist über die Suite-Pläne verfügbar (und bei Support mit Knowledge Professional oder Enterprise), aber die Bausteine, die Confluence für einen KI-Agenten nutzbar machen, summieren sich.

Angefangen bei Sitzplätzen, ab 19 $ pro Agent im Monat bei Support Team bis 115 $ bei Suite Professional (jährlich abgerechnet). Auto-Assist auf Agentenseite, das deine externen Quellen nutzt, braucht das Copilot-Add-on zu 50 $ pro Agent im Monat. Und der Teil, der überrascht: Eine extern gestützte Antwort, die ein Ticket über eine KI-Agent-Konversation löst, verbraucht weiterhin eine automatisierte Resolution, die Zendesk mit 1,50 $ committed oder 2,00 $ Pay-as-you-go pro verifizierter Resolution abrechnet, zusätzlich zu allem oben genannten. Die KI auf Confluence auszurichten holt sie nicht von diesem Zählwerk herunter.

Eine reine generative-Suche-Antwort in deinem Help Center, die nie zu einer KI-Agent-Konversation eskaliert, verbraucht keine Resolution; sie zählt gegen ein separates monatliches Kontingent von 100.000 Suchen, danach braucht man das Add-on Generative Search Extender. Gut zu wissen, aber die meisten Teams wollen, dass der KI-Agent die Lösung übernimmt, und das ist der abgerechnete Pfad.

Die Limits, die man vor der Entscheidung kennen sollte

Keins davon ist ein Dealbreaker, aber sie prägen, was die native Route leisten kann:

• 50 externe Content-Quellen pro Konto ist die Obergrenze.
• Der universelle Connector aktualisiert vollständig alle 24 Stunden, eine Seite, die du heute Morgen bearbeitest, taucht in Zendesk also möglicherweise erst morgen aktualisiert auf.
• Persönliche Confluence-Spaces sind nicht erlaubt, und nur die ersten 20 Spaces erscheinen im Dropdown (den Rest tippt man, um sie zu finden).
• Man muss Knowledge-Admin sein, um Verbindungen einzurichten.
• Bei den Berechtigungen liegt der eigentliche Vorbehalt: Der Connector indiziert mit den Berechtigungen des verbindenden Kontos, und Zendesk stellt klar, dass quellenspezifische, benutzerbezogene Einschränkungen für externen Content nicht erhalten bleiben. Eine Seite, die das Connector-Konto sehen kann, wird also für jeden beantwortbar, dem die KI dient, egal ob dieser Endnutzer sie sehen dürfte oder nicht.

Wer bereits voll auf Zendesks native KI-Agenten setzt und auf der passenden Plan-Stufe sitzt, für den ist Route A ein legitimer, unterstützter Weg. Für viele Teams sind es aber genau die Plan-Beschränkungen plus das Pro-Resolution-Zählwerk, die sie nach einer zweiten Option suchen lassen.

Route B: eesel über dasselbe Zendesk legen

Der andere Ansatz lässt Zendesk genau so, wie es ist, und legt die KI als Schicht obendrauf. eesel tritt deinem Zendesk per OAuth als echter KI-Agent bei, liest deine Tickets, entwirft und versendet Antworten, aktualisiert Felder und routet an Gruppen. Was es für dieses konkrete Problem passend macht: Seine Wissensquellen sind unabhängig davon, wo es eingesetzt ist, sodass derselbe Agent, der deine Zendesk-Warteschlange bearbeitet, auch dein Confluence liest.

Confluence als Quelle, Zendesk als Ziel

eesel verbindet sich mit Confluence über seine Atlassian-Marketplace-App, die nur Lesezugriff anfordert: deine Seiten und Spaces, plus die Nutzer- und Gruppeninformationen, die sie braucht, um Berechtigungen zu respektieren. Sie erhält nie Schreibzugriff. Man installiert sie in seiner Confluence-Cloud-Site, wählt die Spaces oder eine übergeordnete Seite (alles darunter, einschließlich später erstellter Seiten, kommt automatisch mit), und dieses Wissen wird Teil desselben Agenten, der in Zendesk läuft.

Die Dokumentation bringt es klar auf den Punkt: "Jede andere Integration auf dem Agenten ist ebenfalls eine Quelle, sodass eine Confluence-Antwort gleichzeitig auf Notion, Google Drive, dein Helpdesk und deine Dateien zurückgreifen kann." In der Praxis bedeutet das: ein Agent beantwortet ein Zendesk-Ticket, indem er dein Confluence-Runbook, deine bisherigen gelösten Tickets, deine Makros und ein Richtlinien-PDF liest, alles in derselben Antwort, mit einem Verweis darauf, woher die Antwort stammt. Das ist genau der Teil, den der native Connector nicht an einem Ort hinbekommt, weil er externen Content als eine Eingabe für Zendesks eigenes Wissen behandelt, statt deine Quellen unter einem einzigen Agenten zu vereinen.

Berechtigungen, auf Seitenebene umgesetzt

Weil eesels Confluence-App die nötigen Gruppeninformationen mitführt, indiziert sie nur Seiten, die sie tatsächlich sehen darf. Schränkst du einen Space oder eine Seite in Confluence ein, taucht sie beim Agenten erst auf, wenn du der App Ansichtsrechte gewährst. Geprüft wird das sowohl auf Space-Ebene (Space-Einstellungen, Space-Zugriff) als auch bei den Einschränkungen der einzelnen Seite.

Das ist der schärfste praktische Unterschied zwischen den beiden Routen. Wenn dein Confluence Spaces hat, die nicht jedem Kunden beantwortbar sein sollten, ist das seitenweise Berechtigungsmodell viel wert.

Vor dem ersten echten Ticket testen

Die Gewohnheit, der ich mehr vertraue als jedem Feature-Bullet, ist ein Testlauf. eesels Simulation lässt den Agenten über deine bisherigen Zendesk-Tickets laufen, bewertet, wie er jedes Thema gehandhabt hätte, und zeigt dir die Abdeckungslücken, bevor je ein Kunde damit in Berührung kommt. Wenn eine Simulation zeigt, dass etwa Rückerstattungsfragen nur zu 28 Prozent abgedeckt sind, weil die Richtlinie auf einer noch nicht verbundenen Confluence-Seite liegt, verbindest du sie, lässt es erneut laufen und siehst die Zahl steigen. Diese Schleife ist der Grund, warum ich nie einfach einen Schalter umlege und hoffe, eine Lektion, die eesel selbst auf die harte Tour gelernt hat, nach Jahren voller selbstbewusster Bots mit falschen Antworten auf echten Warteschlangen.

Wo es kostet, und wo es ehrlich über Limits ist

Die Preisgestaltung ist nutzungsbasiert: pauschal 0,40 $ pro Ticket, das die KI bearbeitet, keine Sitzplatzgebühr, keine Plattformgebühr, kein Minimum, und das Verbinden von Confluence selbst kostet nichts. Wenn dein Team 1.000 Tickets im Monat bearbeitet, aber nur 200 an die KI weiterleitet, zahlst du für 200. Es gibt kein separates Zählwerk dafür, ob die Antwort auf Confluence oder auf deinem Help Center basiert, weil es einfach der Agent ist, der seine Arbeit macht.

Um bei den Limits ehrlich zu sein, weil ich sie vor einem Wechsel kennen wollen würde: Die Self-Service-Confluence-App ist nur für die Cloud und braucht Admin-Zugriff, Data Center ist daher ein betreutes Setup statt eines Klick-Installs (die Marketingseite übertreibt das; die Docs sind präzise). Seitenanhänge werden nicht indiziert, nur der Seitentext, alles, was in einem angehängten PDF liegt, muss also in die Seite eingefügt oder direkt beim Agenten hochgeladen werden. Und die Standardgrenze von 3.000 Seiten pro Verbindung kappt statt zu scheitern, man kann aber um eine Erhöhung bitten.

Welche Route solltest du wählen?

Wenn du tief in Zendesks nativem Agenten-Stack steckst, bereits auf einer Knowledge-Professional- oder Enterprise-Stufe bist und mit dem Pro-Resolution-Zählwerk zurechtkommst, ist der native Confluence-Connector ein unterstützter, legitimer Weg, und du brauchst keine Drittanbieter-Schicht, damit er funktioniert. Lies die Bewertung zu Zendesk KI-Agenten und zu den wichtigsten Zendesk-KI-Funktionen, wenn du diese Route für sich abwägst.

Wenn Confluence der Ort ist, an dem dein Team tatsächlich dokumentiert, du die KI in Tagen statt nach einem Plan-Upgrade live willst, seitengenaue Berechtigungen wichtig sind oder dich die Preisgestaltung nach automatisierten Resolutions bei Volumen nervös macht, ist es der schnellere, günstigere Weg, eesel über dein bestehendes Zendesk zu legen, um eine KI zu bekommen, die aus deinem Wiki antwortet. So oder so gilt es, auf eines zu bestehen: Die KI sollte dort lesen, wo deine besten Antworten bereits liegen, statt dich zu zwingen, sie erst in ein Help Center zu migrieren.

eesel für Zendesk und Confluence testen

Wenn deine Zendesk KI aus Confluence antworten soll, ohne auch nur eine Seite zu migrieren, ist eesel genau für dieses Problem gebaut. Es tritt deiner Zendesk-Warteschlange als KI-Agent bei, liest deine Confluence-Spaces (dazu Notion, Google Drive und deine eigenen bisherigen Tickets) unter Beachtung seitengenauer Berechtigungen und rechnet pauschal 0,40 $ pro Ticket ab, ohne Sitzplätze und ohne Pro-Resolution-Zählwerk. Du verbindest es per OAuth, simulierst es an deiner Ticket-Historie und bist in unter 30 Minuten live.

Du kannst kostenlos starten und noch heute einen Confluence-Space anvisieren, um zu sehen, was es anhand deiner echten Tickets entwirft.