Meta Muse für Document360: So kommt deine Wissensdatenbank 2026 in Metas WhatsApp-KI

Kurzfassung

„Meta Muse für Document360“ heißt in Wahrheit: deine Document360-Wissensdatenbank an den Meta Business Agent verfüttern, die KI, die Kunden auf WhatsApp und Messenger antwortet. Muse selbst ist ein Consumer-Agent. Der Business Agent hat keinen Document360-Importer und lernt nur aus vier Quellen: Unternehmensinfos, FAQ-Einträgen, hochgeladenen Dateien und gecrawlten öffentlichen Websites.

Document360 macht das einfacher als die meisten Tools, denn eine öffentliche Document360-Seite ist zum Crawlen gebaut. Schwierig sind private Projekte und Aktualität. Meta kann hinter einem Reader-Login nicht crawlen, hochgeladene Dateien aktualisieren sich nie von selbst, und der eigene MCP-Server von Document360 meldet sich über einen Nutzer-OAuth-Flow an, den Metas Connectors nicht unterstützen. Passend ist ein schreibgeschützter v3-API-Key.

eesel betreibt seit Jahren KI in echten Support-Warteschlangen, und der häufigste Fehler, den ich sehe, ist ein Bot, der selbstsicher antwortet, obwohl die Wissensdatenbank zum Thema nichts hat. Wenn sich deine Document360-Artikel jede Woche ändern, crawlt eesel deine Document360-Seite, verlinkt in jeder Antwort den Quellartikel und wird an deinen bisherigen Tickets getestet, bevor es irgendjemandem antwortet.

Was „Meta Muse für Document360“ eigentlich bedeutet

Ich beschäftige mich viel damit, was Leute vor dem Kauf in Google tippen, und „Meta Muse für Document360“ ist ein gutes Beispiel für eine Suche, die auf das falsche Produkt zeigt. Drei Meta-Produkte tragen den Namen Muse oder stehen ihm nahe, und nur eines spricht mit deinen Kunden (mein Hub Meta Muse für den Kundensupport geht auf alle drei ein):

1. Muse, der persönliche KI-Agent, den Meta für Alltagsaufgaben von Verbrauchern gestartet hat. Er ist nicht dafür gebaut, die Kunden eines Unternehmens zu beantworten.
2. Muse Spark 1.3, das Modell, vertrieben über die Meta Model API. Darauf könntest du selbst einen Document360-Bot bauen, und meine Übersicht zu Muse Spark 1.3 nennt die Modelldetails.
3. Meta Business Agent, den Meta im Juni gestartet hat, als KI, die Kunden auf WhatsApp, Messenger und Instagram antwortet. Laut Meta nutzen ihn bereits mehr als eine Million Unternehmen.

Die eigentliche Kauffrage hinter der Suche lautet also: Wie kommt mein Document360-Inhalt in einen WhatsApp-Bot? Das ist eine andere Aufgabe als bei den Helpdesk-Beiträgen dieser Reihe, etwa Zendesk oder Freshdesk, wo die Unterhaltungen landen. Document360 ist der Ort, an dem die Antworten liegen, und hat bereits eine eigene KI, Eddy, auf die ich noch zurückkomme.

Document360 ähnelt auch mehr der Confluence-Version dieses Beitrags als jedem Helpdesk. Der Unterschied: Die meisten Document360-Seiten sind von vornherein kundenorientiert, was ändert, welcher Weg der einfachste ist.

Vier Wege, wie Document360-Inhalte zu Metas Agent gelangen

Metas Capabilities-Seite nennt vier Wissensquellen in der Platform API: Business Info, FAQs, Files und Websites. Aktionen und Abfragen laufen über Connectors, also HTTP- oder MCP-Integrationen, die du selbst definierst. Document360 wird in Metas Dokumentation nirgends genannt.

So schneiden die vier ab, bevor ich jeden einzeln durchgehe:

Weg 1: Meta deine öffentliche Document360-Seite crawlen lassen

Diesen Weg können die meisten Document360-Teams heute nutzen, denn ein öffentliches Document360-Projekt ist bereits eine Website.

Metas Websites-API crawlt eine URL und übernimmt ihren Inhalt. Standardmäßig nimmt sie „die ganze Domain“, und du kannst mit Feldern für Subdomain, URL-Muster und einzelne URLs eingrenzen. Die Anfrage hat kein Feld für Login oder Cookie, und Metas Leitfaden für Support-Agenten beschreibt, dass „deine öffentliche Website“ gecrawlt wird. Im Umfang ist also nur Inhalt, den jeder ohne Anmeldung öffnen kann.

Document360 bietet einige Kontrollen, die einen Crawl sauberer machen:

• Sitemap. Document360 erzeugt eine für deine Seite, die Karte, der ein Crawler folgt. Die Sitemap-Doku erklärt, was hineinkommt.
• Robots.txt. Du kannst sie unter den Einstellungen der Wissensdatenbank-Seite bearbeiten, um Pfade für alle Crawler oder einen User-Agent zu sperren, laut Document360s robots.txt-Seite. Meta veröffentlicht den User-Agent seines Crawlers in der Business-Agent-Doku nicht, daher würde ich mit Metas URL-Muster-Feldern eingrenzen und mich nicht auf Robots-Regeln verlassen.
• Suchsichtbarkeit. Schalter pro Artikel schließen eine Seite von Google, von der Wissensdatenbank-Suche oder von Eddy AI aus. Der Haken steht in Document360s Doku zur Suchsichtbarkeit: Diese Einstellungen „schränken den Zugriff nicht ein“. Ein ausgeschlossener Artikel ist unter seiner URL weiter lesbar, ein Crawler, der den Link findet, kann ihn also trotzdem lesen.

Der letzte Punkt zählt, wenn du ein gemischtes Projekt betreibst, in dem manche Kategorien öffentlich sind und manche für angemeldete Leser. Document360s Preis-FAQ beschreibt Projekte als öffentlich, privat oder gemischt und sagt, Reader-Konten „gelten nur für private Wissensdatenbanken“ (Document360-Preise). Meta sieht den öffentlichen Teil und nichts sonst, prüfe also, dass die Antworten, nach denen Kunden am häufigsten fragen, nicht in der Reader-only-Hälfte liegen.

Grenze den Crawl trotzdem eng ein. Metas Leitfaden warnt, dass das Crawlen einer ganzen Seite „die Hilfeinhalte verwässert, aus denen der Agent antworten soll“. Enthält deine Document360-Seite auch API-Referenz oder Release Notes, richte Meta nur auf die Hilfekategorien.

Weg 2: Artikel als PDF exportieren und hochladen

Für ein privates Projekt kannst du Inhalte exportieren und Meta die Dateien übergeben. Document360s PDF-Export lässt dich Kategorien und Artikel wählen, eine Vorlage anwenden und ein PDF herunterladen.

Metas Files-API nimmt .pdf, .doc, .docx und Bilder, mit CSV und XLSX bei aktivierter Extraktion, bis zu 100.000.000 Bytes pro Datei. Markdown und HTML stehen nicht auf der Liste, deshalb ist das PDF hier das sinnvolle Format. Zwei Details von Document360 solltest du vorher kennen:

1. Exporte kosten Credits. „Jede Seite im erzeugten PDF verbraucht einen Credit“ aus einem monatlichen Kontingent, das mit den PDFs geteilt wird, die deine Leser von der Seite herunterladen. Ein wöchentlicher Export mit 200 Seiten summiert sich.
2. Nur veröffentlichte Inhalte kommen hinein. Versteckte Artikel und Kategorien sind nicht auswählbar, was nützlich ist, denn so bleiben Entwürfe aus dem Bot.

Dann gibt es den Teil, auf den Meta im eigenen Support-Leitfaden hinweist:

„Es gibt keinen Update-Aufruf. Um ein Dokument zu ersetzen, lösche den alten Eintrag und lade den neuen hoch, sonst greift der Agent auf beide Versionen zurück und kann einen Begriff zitieren, den du bereits zurückgezogen hast.“

Metas Leitfaden für Support-Agenten

Angenommen, deine Rückgabefrist ändert sich von 30 auf 14 Tage, und jemand lädt das neue PDF hoch, ohne das alte zu löschen. Der Agent kann auf WhatsApp beide Zahlen nennen. Document360s eigene Export-Doku sagt dasselbe von der anderen Seite: Ein exportiertes PDF „ist statisch“, und spätere Änderungen „erscheinen nicht im PDF“. Dieser Weg bedeutet also ein Skript, das bei jeder Inhaltsänderung die vorherige Datei anhand ihrer ID löscht und die neue hochlädt.

Meta warnt auch davor, alles hochzuladen: „Ein großer Dokumentensatz macht den Agenten langsamer beim Finden der richtigen Passage.“ Kleinere PDFs pro Kategorie schlagen einen riesigen Export.

Weg 3: Deine wichtigsten Artikel als FAQ-Einträge umschreiben

Metas FAQs-API speichert Frage-Antwort-Paare, die du an Ort und Stelle aktualisieren kannst. Der Agent behandelt einen passenden Eintrag als die Antwort und „antwortet daraus, statt eine Antwort aus deinen anderen Wissensquellen abzuleiten“. Damit sind FAQs die berechenbarste Eingabe für Antworten, die exakt sein müssen, etwa Rückerstattungsbedingungen oder Preise.

Die Obergrenze ist niedrig: Meta sagt, die Qualität könne „im Allgemeinen ab ein paar Hundert“ Einträgen nachlassen. Für ein Document360-Team ist dieser Weg günstiger, als er klingt, denn Eddys AI-FAQ-Generator entwirft bereits Q&A-Paare aus einem Artikel. Ich würde die häufigsten Ticket-Treiber des letzten Quartals nehmen (dieselbe Liste wie für WhatsApp-Ticket-Deflection), FAQs für diese Artikel generieren, sie von Hand bearbeiten und an Meta schicken. Der lange Schwanz geht an den Crawl oder einen Connector.

Weg 4: Einen API-Connector mit begrenztem v3-Key bauen

Das ist der einzige Weg, der private Inhalte privat und zugleich aktuell hält, und du musst ihn selbst bauen.

Metas Connectors-Referenz erlaubt es, den Agenten auf eine HTTP-API oder einen Remote-MCP-Server zu richten. Die Authentifizierung ist begrenzt: „Derzeit werden nur OAUTH2_CLIENT_CREDENTIALS, API_KEY und NONE unterstützt.“ Diese eine Zeile entscheidet, welche Document360-Schnittstelle du nutzen kannst.

Der Document360-MCP-Server passt laut Dokumentation nicht. Er ist der naheliegende erste Gedanke, denn er hat bereits ein Tool document360-mcp-search. Aber die MCP-Übersicht sagt, er „nutzt OAuth zur Authentifizierung“ und bindet jede Verbindung an „das Benutzerkonto, das den OAuth-Flow abschließt“. Das ist ein Zustimmungsbildschirm im Browser, und Metas Connectors können sich nicht durchklicken.

Die v3-REST-API passt. Wenn du mit MCP noch neu bist: Meine Erklärung MCP für den Kundensupport zeigt, warum das Authentifizierungsmodell so wichtig ist. Document360s API-Key-Seite sagt, ein Key kommt in einen X-API-Key-Header und wird „auch als Authorization: Bearer akzeptiert“, was auf Metas Auth-Typ API_KEY passt. Nützlich ist die Eingrenzung: Ein v3-Key trägt eine Portalrolle, eine Inhaltsrolle und einen Inhaltszugriffsbereich, du kannst also einen reinen GET-Key ausstellen, der einen Workspace oder einige Kategorien liest und sonst nichts. Projekte, die vor v3 angelegt wurden, haben eventuell noch das ältere v2-api_token, das ebenfalls funktioniert, aber keine Inhaltseingrenzung hat.

Ein einfacher Connector braucht zwei Tools:

1. Suche, mit dem v3-Endpunkt search workspace articles. Es ist eine Stichwortsuche über veröffentlichte, sichtbare Artikel, und page_size liegt maximal bei 100.
2. Artikel abrufen, um den vollständigen Text des besten Treffers zu holen.

Es gibt eine dritte, interessantere Option: Der v3-Endpunkt AI search query schickt eine Frage in natürlicher Sprache an Eddy und liefert eine generierte Antwort aus deinen Docs. Bindest du das als Tool ein, fragt Metas Agent Eddy nach der Antwort. Es funktioniert mit demselben API-Key, aber jeder Aufruf ist eine Eddy-Anfrage, und Eddy-Anfragen sind per Credit abgerechnet.

Plane drei Haken von Anfang an ein:

• Ratenlimits. v3 erlaubt je nach Tarif 120 oder 200 Lesezugriffe pro Minute und Key, laut Seite zum Rate Limiting. Für ein kleines Team reicht das, vor einer Hochsaison lohnt sich die Prüfung.
• Antwortgröße. Metas Referenz zu Connector-Tools warnt, dass übergroße Antworten „die Antwortqualität des Agenten verschlechtern“. Nutze seine transformation_spec, um Artikeltexte auf den Text zu kürzen.
• Es ist eine Abfrage, keine Wissensquelle. Meta dokumentiert Connectors für Aktionen und Kundenabfragen wie den Bestellstatus. Nirgends beschreibt es einen als Wissensdatenbank, ein Tool „Document360 durchsuchen“ solltest du also hart testen, denn Meta verspricht es nicht.

Rechne mit den Limits bei beiden Wegen, die Document360s Technik berühren. Ein Document360-Admin auf G2 nannte genau die zwei, auf die dieser Beitrag setzt:

„Schließlich gibt es Beschränkungen bei API-Token-Nutzung, täglichen Export-Größenlimits und anderen Nutzungsobergrenzen. Diese Limits können zusätzliche Kosten oder Reibung für Teams verursachen, die Dokumentation im großen Maßstab verwalten.“

Vignesh S., G2

Das Aktualitätsproblem, das in keiner Demo vorkommt

Die meisten Einrichtungsanleitungen enden, sobald der Bot die erste Testfrage beantwortet. Für ein Document360-Team ist der eigentliche Test, was am Dienstag danach passiert, wenn jemand eine Änderung veröffentlicht.

Meta sagt, gecrawlte Seiten würden „regelmäßig neu gecrawlt“, nennt aber kein Intervall, und sein Leitfaden ergänzt, Website-Wissen sei „eine Momentaufnahme zum Crawl-Zeitpunkt“. Dateien aktualisieren sich nie. FAQs ändern sich, wenn du die API aufrufst. Nur ein Live-Connector sieht eine Änderung sofort.

Document360 hat ein Feature, das hier hilft: Webhook-Benachrichtigungen. Du kannst Ereignisse wie Artikel veröffentlichen, aktualisieren und löschen einer Webhook-URL zuordnen, laut Doku zum Webhook-Kanal, und Document360 nennt Cache-Invalidierung als Anwendungsfall. Das ist der Auslöser, den ein Re-Upload-Skript braucht, und es ist dasselbe Muster wie bei jeder WhatsApp-Support-Automatisierung: Beim Veröffentlichen den Artikel exportieren, Metas alte Datei löschen, die neue hochladen. Es bleibt ein Skript, das du selbst betreibst, aber es läuft bei einem echten Ereignis und nicht, weil sich jemand erinnert.

Die andere Hälfte der Aktualität ist, was der Bot tut, wenn deine Wissensdatenbank zur Frage nichts hat. Meta hat keinen Schalter „nur aus Wissen antworten“. Grounding ist eine Zeile in deinen Anweisungen, und Metas Beispiel lautet: „Beantworte Richtlinienfragen nur aus den dokumentierten Richtlinien und sage, dass du bei einer Kollegin oder einem Kollegen nachfragst, statt zu raten, wenn die Antwort dort nicht steht.“ Ein früher Tester des Business Agent auf Reddit beschrieb, was ohne sie passiert:

„Konsistenz ist ein Problem. Ich habe dasselbe Produkt in zwei Antworten mit zwei verschiedenen Preisen zurückkommen sehen. Wenn du es nicht sauber verankerst, erfindet es einfach Dinge.“

u/Kira_SENPAI_1, Reddit

Dasselbe habe ich bei echten eesel-Rollouts gesehen. Wir hatten zahlende Kunden, deren Bot echten Kunden Antworten erfand, wenn die Suche leer zurückkam. Deshalb sind ein Fallback bei fehlendem Wissen und ein Testlauf gegen historische Tickets heute Standard, bevor ein Bot live geht. Der Leitfaden zur Halluzinationsvermeidung geht dieses Setup durch.

Es hilft auch, Artikel so zu schreiben, dass der Bot sie nutzen kann. Kurze Seiten zu einem Thema mit der Antwort im ersten Absatz werden besser abgerufen als lange, und die Anleitung zum Training auf der Wissensdatenbank zeigt, wie man sie strukturiert.

Wo Eddy AI passt

Bevor du etwas davon baust, ist die Frage berechtigt, ob Document360s eigene KI den Job nicht schon erledigt. Eddy antwortet auf deiner Wissensdatenbank-Seite, im KB-Widget und über einen eigenständigen Chatbot, den du mit einem Chatbot-Key einbettest. Er kann auch auf Freshdesk- oder Zendesk-Tickets trainieren, was der Leitfaden Freshdesk und Document360 durchgeht. Er zitiert die genutzten Artikel und respektiert Artikelberechtigungen für angemeldete Leser.

Was Document360 nicht dokumentiert, ist ein WhatsApp-Kanal für Eddy. Der Chatbot wird auf einer Website eingesetzt, einer pro Domain, und seine einzige Helpdesk-Aktion ist, ein Ticket in Zendesk oder Freshdesk zu erstellen. Die Aufteilung ist also simpel:

• Kunden fragen auf deiner Seite oder im Help Center: Eddy ist schon da. Mein Test Document360 AI geht ausführlich darauf ein, und die Liste der Eddy-AI-Alternativen zeigt, was sonst aus einer Document360-KB antwortet.
• Kunden fragen auf WhatsApp: Metas Agent besitzt diese Nummer, und Eddy hilft nur, wenn du seine AI-Such-API in einen Connector einbindest.

Willst du stattdessen einen Allzweck-Assistenten auf Document360, behandeln die Leitfäden ChatGPT für Document360 und Grok Bot für Document360 diese Wege, und KI für Document360 vergleicht das Schreiben von Docs mit dem Antworten daraus.

Was es kostet

Es gibt zwei Rechnungen: die von Meta und die von Document360.

Die Document360-Seite lässt sich schwer beziffern, da jeder Tarif ein individuelles Angebot ist. Meine Aufschlüsselung der Document360-Preise erklärt, was ihn bewegt. Von den sechs Faktoren ist das Datenschutzmodell der, der zu diesem Beitrag zurückführt: Ein privates Projekt braucht kostenpflichtige Reader-Konten, und es ist auch das Setup, das Meta nicht crawlen kann.

Auf der Meta-Seite solltest du die Änderung zum 1. Oktober beachten. Metas Preisseite sagt, jede Nachricht werde „entweder als Meta-Business-Agent-Nachricht oder als Service-Nachricht abgerechnet, nie beides“, die Antworten der KI werden also als Tokens abgerechnet und alles, was dein Team nach einer Übergabe sendet, als Service-Nachrichten. Meine Erklärung zu den WhatsApp-API-Preisen zeigt die ganze Historie.

Wo Metas Agent für ein Document360-Team aufhört

Metas Agent ist für manche Teams eine vernünftige Wahl. Hier sind seine Grenzen:

• Eine KI pro Nummer. Metas Plattformübersicht sagt: „Eine aktive Integration eines autorisierten Agenten blockiert den Meta Business Agent.“ Du wählst einen Bot pro WhatsApp-Nummer.
• Nur Meta-Oberflächen. Er antwortet auf WhatsApp, Messenger, Instagram und einem Website-Plugin, das vorerst an Shopify gebunden ist. Meine Liste WhatsApp-Chatbot vergleicht Tools, die über Metas Apps hinaus antworten. E-Mail und Helpdesk-Warteschlangen sind außer Reichweite, und dort landen die meisten Document360-Leser, wenn Self-Service scheitert.
• Keine Einstellung für Quellenangaben. Nichts in Metas Doku lässt den Agenten den genutzten Artikel verlinken. Eddy tut es, ebenso die meisten Wissensdatenbank-Chatbots.
• Übergabe verschiebt den Posteingang. Sobald der Business Agent die Nummer übernimmt, geht dein bestehender WhatsApp-Posteingang in den Standby. Die Zendesk-Version dieses Beitrags behandelt Metas Conversation Routing, und der Leitfaden zur KI-Agent-Übergabe zeigt, wie eine gute Übergabe aussieht.
• API-Docs sind keine Support-Antworten. Viele Document360-Seiten mischen Hilfeartikel mit API-Referenz. Halte die Referenz aus dem Crawl heraus, sonst beantwortet der Bot eine Abrechnungsfrage mit einer Endpunktbeschreibung.

Welches Setup zu deinem Document360-Team passt

So würde ich auswählen:

Du vergleichst noch Tools statt Wege? Meine Übersicht beste KI für WhatsApp-Support und die Liste der besten KI-Wissensdatenbank-Tools nähern sich von beiden Seiten, und Document360-Alternativen behandelt den Wechsel der KB selbst.

Wenn du versucht bist, den Connector selbst zu bauen, lohnen sich zehn Minuten mit dem Beitrag Build vs. Buy vorher.

eesel mit Document360 testen

Jeder der obigen Wege endet damit, dass jemand in deinem Team Metas Kopie deiner Wissensdatenbank synchron hält. eesel überspringt diesen Schritt. Es ist ein KI-Helpdesk-Teammitglied, das deine Document360-Seite als Website-Wissensquelle liest: Du gibst die URL des Help Centers an, es crawlt über deine Sitemap und Links bis zu 2.000 Seiten, und jede Antwort verlinkt den Artikel, aus dem sie stammt. Include- und Exclude-Pfade halten deine API-Referenz draußen, und eigene Header (Cookie, Basic oder Bearer) gibt es für Seiten hinter einem Login, was du bei einem privaten Projekt testen solltest.

Es gibt keinen nativen Document360-Connector, das will ich nicht verschweigen. Was eesel über den Crawl hinaus liefert, ist alles andere, was eine Support-Antwort braucht: deine bisherigen Tickets, Makros und dein Helpdesk, zusammengeführt mit den Document360-Artikeln, und eine Simulation gegen deine historischen Tickets, bevor der Bot einem echten Kunden antwortet. Wenn du im Terminal arbeitest, führt die eesel CLI dasselbe Setup als Befehle aus: eesel integrations connect website fügt die Document360-Seite hinzu, und eesel status zeigt die Seitenzahl, sodass Claude Code oder Cursor es für dich erledigen können.

Wenn WhatsApp der Kanal ist, den du brauchst, sieh dir eesels WhatsApp-Integration an und denk bei der Wahl an Metas Regel „eine KI pro Nummer“. Der kostenlose Tarif kommt mit 100 Credits und ohne Karte, und bezahlte Tarife beginnen bei 299 $ für 500 Tickets oder Chats im Monat. Probier eesel an deinem Document360-Help-Center aus und sieh, wie es antwortet.