KI für Document360: zwei Wege, KI in deine Wissensdatenbank zu bringen

Zuerst eine Geschichte über eine selbstbewusst falsche Antwort

Ich baue Integrationen bei eesel, also verbringe ich viel Zeit damit, zuzusehen, wie KI die Wissensdatenbank eines Unternehmens liest und versucht, echte Fragen daraus zu beantworten. Dieser Job hat mich zutiefst misstrauisch gegenüber Demos gemacht, in denen der Bot immer alles richtig macht.

Eine, die mir in Erinnerung geblieben ist: Ein B2B-Team für Fahrzeug-Telematik, das von ein paar hundert Zendesk-Tickets pro Monat auf einige Tausend skalierte, hat einen KI-Agenten an seine Wissensdatenbank angeschlossen. Er begann, Kunden selbstbewusst zu sagen "ja, wir unterstützen dein Automodell" für Marken, die in ihrem System überhaupt nicht existierten. Warum? Weil eine einzige Zeile in ihrer Wissensdatenbank sagte "wir unterstützen alle Modelle." Die KI war nicht defekt. Sie tat genau das, was eine Wissensdatenbank ihr sagt zu tun, nämlich die Wissensdatenbank zu wiederholen. Ihre ehrliche Zusammenfassung der ersten Wochen war "Trial and Error am Anfang."

Das ist das ganze Spiel bei KI auf einer Wissensdatenbank wie Document360. Das Tooling ist der einfache Teil. Der schwierige Teil ist zu wissen, was die KI einem Kunden tatsächlich sagen wird, bevor sie es sagt. Behalte das im Kopf, während wir die Optionen durchgehen, denn es ist das, was die meisten "Füge KI zu deinen Docs hinzu"-Pitches leise auslassen.

Was "KI für Document360" tatsächlich bedeutet

Document360 ist eine Wissensdatenbank-Plattform, kein Helpdesk, also teilt sich "KI hinzufügen" klar in zwei Absichten. Diese Trennung richtig zu verstehen erspart dir den Kauf des falschen Produkts.

Die erste Absicht ist das Verfassen: das Schreiben, Bearbeiten, Übersetzen und Pflegen der Artikel selbst. Hier verbringt ein technischer Redakteur oder Support-Lead seine Zeit, und hier ist Document360s native KI stark.

Die zweite Absicht ist das Beantworten: die fertigen Artikel zu nehmen und mit ihnen Fragen zu lösen, egal ob das ein Kunde auf deiner Hilfeseite ist oder ein Agent, der mitten in einem Ticket nach einer Antwort sucht. Das ist die Absicht, die deine Support-Zahlen berührt, und es ist diejenige, bei der du tatsächlich eine Entscheidung treffen musst, weil es nicht der einzige Ort ist, an dem deine Kunden Fragen stellen. Die meisten von ihnen fragen in deinem Helpdesk, was eine andere Oberfläche ist als deine Docs-Site. Das ist derselbe Grund, warum wir separate Guides für KI für Zendesk, KI für Freshdesk und KI für Help Scout geschrieben haben: die Docs sind ein Input, aber die Warteschlange ist, wo die Arbeit landet.

Route A: Document360s natives Eddy AI

Alles, was Document360 mit KI macht, trägt den Namen Eddy AI. Wichtig zu verstehen ist von vornherein, dass Eddy nicht ein Feature ist, sondern ein Bundle plus zwei Add-ons, und genau an dieser Grenze werden Support-Teams überrascht.

Im Bundle enthalten sind der Eddy AI-Schreibassistent, KI-Content- und FAQ-Erstellung, KI-Suche und -Antwort, automatisch generierte Glossare, Duplicate-Content-Erkennung und der MCP-Server. Separat verkauft werden der AI Chatbot (das eingebettete Widget, das Lesern antwortet) und die AI Premium Suite (Bildschirmaufnahme, Schritt-für-Schritt-Anleitungen, interaktive Demos, Videoaufnahme). Beachte, auf welcher Seite dieser Grenze der kundenseitige Chatbot steht.

Docs schreiben mit Eddy AI

Für die Verfassungsabsicht ist das eine gute Passung, und ich würde es gerne nutzen. Der Schreibassistent lebt direkt im Editor, sodass du eine Gliederung generieren, einen Abschnitt erweitern, den Ton ändern, lange Sätze aufteilen und Vorschläge für verwandte Artikel und Tags bekommen kannst, ohne den Artikel zu verlassen, an dem du gerade bist. Wenn dein Ziel ist, einen Rückstau halbfertiger Docs in Form zu bringen, macht Eddy die Arbeit an dem Ort, an dem du bereits arbeitest, was genau dort ist, wo Verfassungs-KI sein sollte.

Leser beantworten: KI-Suche und der Chatbot

Für die Beantwortungsabsicht innerhalb der Docs-Site gibt dir Document360 zwei Oberflächen. Die erste ist KI-Suche und -Antwort, die eine direkte Antwort aus deinen Artikeln synthetisiert statt zehn blaue Links zurückzugeben, und die Artikel zitiert, aus denen sie gezogen hat.

Mir gefällt, dass es seine Quellen zeigt und, erfreulich, "KI kann Fehler machen, bitte wichtige Informationen überprüfen" direkt unter der Antwort ausgibt. Diese Ehrlichkeit ist die richtige Haltung für einen Wissensdatenbank-Bot, und sie ist die Kehrseite meiner Telematik-Geschichte oben.

Die zweite Oberfläche ist der Eddy AI Chatbot, das Add-on-Widget, das du auf deiner Site einbettest. Er antwortet aus deinem Content und bietet an, ein Ticket zu erstellen, wenn er nichts hat, statt sich etwas auszudenken.

Der Chatbot ist flexibler, als er zunächst aussieht. In seinen Quelleinstellungen kannst du ihn auf deine Wissensdatenbank, eine externe Website, Rohtext, hochgeladene Dateien, FAQs und sogar Zendesk- oder Freshdesk-Tickets richten, alles mit einer Content-Zugriffskonfiguration und einer Speichergrenze.

Zwei ehrliche Grenzen, die man ansprechen sollte, beide sollten dich nach der Geschichte aus der Einleitung interessieren. Erstens: Der Chatbot antwortet auf deiner Docs-Site, nicht innerhalb des Helpdesks deiner Agenten, also lenkt er am Help Center ab, entwirft aber keine Antworten in der Ticket-Warteschlange. Zweitens gibt es hier keinen Trockenlauf über deine eigenen historischen Tickets: Du konfigurierst die Quellen und veröffentlichst. Das ist das Muster "umschalten und sehen", und genau so wird aus einer Wissensdatenbank-Zeile wie "wir unterstützen alle Modelle" eine selbstbewusst falsche Antwort in Produktion.

Der MCP-Server (der eigentlich moderne Teil)

Das eine native Feature, das ich vorne mit dabei nennen würde, ist der MCP-Server. Model Context Protocol ist der aufkommende Standard, damit ein KI-Assistent ein externes System abfragen kann, und dass Document360 einen ausliefert, bedeutet, dass ein MCP-fähiger Assistent deine Wissensdatenbank direkt lesen kann. Wenn dein Team in einem Assistenten lebt, der MCP spricht, ist das eine echte Brücke, und das ist seltener, als es sein sollte. Wir gehen durch, was du damit tun kannst und was nicht, in ChatGPT für Document360, und dasselbe Muster zeigt sich bei Wiki-Tools generell, was wir in ChatGPT für Confluence behandeln.

Was Eddy AI tatsächlich kostet

Hier musst du langsamer machen. Document360 veröffentlicht keine festen Plan-Preise mehr. Die Preisseite ist ein reiner Angebots-Konfigurator mit der Überschrift "individuelle Preisgestaltung, aufgebaut um deine Bedürfnisse", und sie leitet dich zu einem Vertriebsgespräch.

Document360s eigenes FAQ listet die sechs Faktoren, die dein Angebot bewegen:

Die Testphase ist großzügig (14 Tage, keine Kreditkarte, jedes Feature aktiv), und jedes Angebot enthält einen dedizierten Success Manager und Onboarding. Aber das Modell bedeutet, dass du keinen KI-Preis bekommen kannst, ohne mit dem Vertrieb zu sprechen, und die Teile, die die meisten Support-Teams wollen, sind Add-ons auf einer Basis, über die du bereits verhandelst. Nutzer merken das. Die Zusammenfassung eines G2-Rezensenten zum Nachteil war deutlich:

"Es ist teuer, und viele neue Features benötigen eine separate Lizenz."

Document360-Rezension, G2

Und auf Reddit brachte es ein Product Manager, der es als seine Wissensdatenbank nutzt, noch direkter auf den Punkt:

"Ich nutze Document360 als meinen Wissensdatenbank-Anbieter, und ich mag sie wirklich nicht, und sie sind sehr teuer für das, was sie bieten."

r/ProductManagement, Knowledge Base Provider?

Um fair zu sein, das Kernprodukt erhält auch echtes Lob und hält bei etwa 4,5 bis 4,7 auf G2 über 542 Rezensionen, wobei die Oberfläche und die Suche am häufigsten hervorgehoben werden. Die Kostenbeschwerde bezieht sich speziell auf die Add-on-plus-Angebot-Struktur, nicht auf die Software. Unsere vollständige Document360-Preisaufschlüsselung hat mehr dazu, und wenn du auch einen Wechsel abwägst, behandelt Document360 vs. Helpjuice diesen direkten Vergleich.

Route B: eesel zusätzlich auf Document360 legen

Wenn dein eigentliches Ziel die zweite Absicht ist, Support-Fragen zu beantworten, gibt es einen anderen Weg, das zu tun, der nicht von Document360s Chatbot-Add-on abhängt: Richte einen dedizierten KI-Support-Teamkollegen auf deine Document360-Docs und lass ihn innerhalb deines Helpdesks arbeiten.

Volle Transparenz: Das ist es, woran ich arbeite, also lies diesen Abschnitt mit diesem Wissen. eesel ist ein KI-Support-Teamkollege, der deine Wissensquellen liest, sich dem Helpdesk anschließt, den du bereits betreibst, und Tickets löst. Es hat heute keinen nativen One-Click-Document360-Connector, also ist die ehrliche Mechanik: Es nimmt deinen Document360-Content auf, indem es das veröffentlichte Help Center oder die URLs crawlt, die du ihm gibst, genauso wie es von jeder Docs-Site lernt. Wenn deine Document360-Wissensdatenbank öffentlich ist, ist das unkompliziert; wenn sie vollständig privat ist, würdest du eesel auf die Quellen richten, die es erreichen kann.

Wo sich die beiden Routen am meisten unterscheiden:

• Es arbeitet in der Warteschlange, nicht nur im Widget. eesel klinkt sich in Zendesk, Freshdesk, Gorgias, Help Scout und andere ein, sodass es Antworten dort entwerfen oder automatisch senden kann, wo deine Agenten tatsächlich arbeiten, und Document360-Antworten als eine seiner Wissensquellen einbeziehen kann statt als die einzige.
• Du kannst simulieren, bevor du live gehst. Das ist der Teil, der meinem Telematik-Kunden geholfen hätte. eesel kann über Tausende deiner echten vergangenen Tickets laufen und dir zeigen, was es geantwortet hätte, sodass du die "wir unterstützen alle Modelle"-Fallen erkennst, bevor ein Kunde sie je sieht, statt danach.
• Die Preisgestaltung ist flach und vorhersehbar. Kein Angebot, keine Pro-Seat-Gebühr. Du zahlst pro Ticket, das die KI bearbeitet.

Hier ist das eesel-Kostenmodell bei ein paar Teamgrößen, damit du es mit einem Document360-Angebot vergleichen kannst:

Ein gelöstes Ticket oder eine Chat-Session ist eine Aufgabe zu 40 Cent, egal wie viele Nachrichten es braucht, ohne Plattformgebühr und ohne Minimum (Preise). Du zahlst nur für Tickets, die die KI tatsächlich bearbeitet, sodass ein schrittweiser Rollout, der 200 deiner 1.000 monatlichen Tickets an KI weiterleitet, $80 kostet, nicht den vollen Betrag. Es ist dasselbe Modell, das wir für KI für HubSpot Service Hub und KI für Salesforce Service Cloud darlegen.

Welche Route solltest du also wählen?

Es gibt hier keinen einzelnen Gewinner, weil die beiden Routen den zwei Absichten dienen. Passe das Tool an die Aufgabe an.

Wenn du nur je die Verfassungshälfte gebraucht hast, hör auf zu lesen und nutze Eddy AI, es ist gut darin. Die Entscheidung wird erst interessant, wenn "KI für Document360" tatsächlich "meine Kunden beantworten" bedeutet, weil diese Frage nicht in deinem Docs-Tool lebt, sondern in deinem Helpdesk. Das ist auch, warum Teams, die KI für Front oder KI für Jira Service Management vergleichen, an derselben Stelle landen: Die Wissensdatenbank ist ein Input, die Warteschlange ist die Aufgabe.

Teste eesel an deinen Document360-Docs

Wenn die Beantwortungsabsicht dich hierher gebracht hat, ist eesel genau dafür gebaut. Richte es auf dein Document360-Help-Center, verbinde den Helpdesk, den du bereits betreibst, und es entwirft und löst Tickets mit deinen bestehenden Docs als Wissen, ohne dass eine Überarbeitung nötig ist.

Das Unterscheidungsmerkmal, dem ich am meisten vertrauen würde, nachdem ich selbstbewusste Bots habe scheitern sehen, ist der Simulationsschritt: Lass eesel über deine echte Ticket-Historie laufen und sieh seine Antworten, bevor ein einziger Kunde sie sieht. Dann rolle es schrittweise aus und zahle pauschal 40 Cent pro Ticket, das es bearbeitet. Es ist kostenlos zu testen, keine Kreditkarte und kein Vertriebsgespräch, sodass du sehen kannst, wie es deine Docs liest, bevor du dich festlegst. Starte mit eesel.