Es gibt eine Version des Wissensmanagements, die die meisten Menschen gut kennen. Dabei öffnet man fünf Browser-Tabs, vergleicht zahlreiche Dokumente, sucht manuell im help center nach Artikeln, an deren Verfassen man sich nur halb erinnert, und verbringt einen Dienstagnachmittag damit, einen Preisteil in 12 verschiedenen Artikeln einzeln zu aktualisieren.
Das war vor nicht allzu langer Zeit mein Job. Ich hatte mir eine fast enzyklopädische mentale Karte aufgebaut, wo Inhalte lagen, was sie sagten und womit sie in Konflikt geraten könnten, wenn sich etwas änderte. Dieses Wissen lebte in meinem Kopf. Das bedeutete, sobald ich nicht im Büro war oder sich etwas schneller änderte, als ich es verfolgen konnte, zeigten sich die Risse.
Dann begann ich, Fin Operator als Kernbestandteil meines Workflows zu nutzen. Was früher Stunden dauerte, dauert jetzt nur noch Minuten. Dieser Artikel richtet sich an Wissensmanager und Content-Teams, die ein help center pflegen. Nutzen Sie ihn, um Operator für Ihren Workflow zu konfigurieren, bei Produkteinführungen Change-Impact-Scans durchzuführen, Inhaltslücken zu schließen und jeden Inhalt anhand eines 14-Faktoren-Bereitstellungsrahmens zu validieren.
Hinweis: Fin Operator befindet sich derzeit in der Beta-Phase. Alle von Operator vorgeschlagenen Inhaltsänderungen erfordern Ihre Überprüfung und Genehmigung, bevor sie live gehen; nichts wird automatisch veröffentlicht.
Vorher: die manuelle Realität des Wissensmanagements
Wenn eine Produktänderung eintraf, zum Beispiel eine Preisaktualisierung, ein neues Feature für alle Pläne oder eine veraltete Integration, sah mein Prozess ungefähr so aus:
Manuelle Suche im help center nach allem, was darauf hinweisen könnte.
Jeden Artikel öffnen, vollständig lesen und entscheiden, ob eine Aktualisierung nötig ist.
Die Änderung vornehmen, als Entwurf speichern und zum nächsten Artikel wechseln. Am Veröffentlichungstag habe ich die aktualisierten Artikel erneut veröffentlicht.
Hoffen, dass ich nichts übersehen habe.
Das Problem war nicht ein einzelner Schritt, sondern die kumulative Belastung. Eine mittelgroße Produktänderung konnte 8 bis 10 Artikel betreffen. Eine bedeutende sogar noch mehr. Und da meine Kollegin Beth und ich diejenigen waren, die wissen mussten, wo alles war, funktionierte das System nur, solange wir es taten.
Danach: So sieht derselbe Prozess mit Operator aus
Jetzt, wenn eine Produktänderung eintrifft, öffne ich einen Gesprächsverlauf mit Operator und beschreibe, was sich geändert hat. Operator durchsucht die knowledge base, zeigt die relevanten Inhalte an und schlägt die Aktualisierungen direkt im selben Gespräch vor, bereit zur Überprüfung.
Ich muss nicht wissen, wo die Inhalte liegen. Ich muss nicht 10 Tabs öffnen. Ich überprüfe die Vorschläge, genehmige das Richtige, lehne das Falsche ab, und wir iterieren. Das Ganze dauert für eine Änderung, die früher zwei bis drei Stunden gedauert hätte, unter 10 Minuten.
Aber die Geschwindigkeit ist nicht das Wertvollste. Das Wertvollste ist Konsistenz. Wenn man Artikel manuell aktualisiert, schleichen sich Inkonsistenzen ein. Man übersieht einen. Man formuliert etwas in zwei Artikeln leicht unterschiedlich. Man aktualisiert den Ausschnitt, aber nicht den öffentlichen Artikel. Mit Operator ist die Suche systematisch. Die Vorschläge basieren auf dem, was tatsächlich existiert. Nichts wird übersehen.
Was diese Rolle jetzt tatsächlich ist
Mein Titel ist KI-Wissensmanager. Die Rolle hatte schon immer zwei Seiten: das Schreiben von Inhalten und die operative Arbeit, eine knowledge base aktuell, konsistent und genau über Tausende von Artikeln zu halten.
Was Operator verändert hat, ist die zweite Hälfte. Die manuelle Abrufarbeit ist größtenteils weg: das Suchen, das Querverweisen, die Jagd nach dem, was existiert, bevor ich überhaupt mit dem Schreiben beginnen kann. Das gibt mir mehr Zeit für den Teil, der tatsächlich Urteilsvermögen erfordert: zu entscheiden, was Inhalte abdecken sollten, welchen Standard sie erfüllen müssen, was aktualisiert und was neu erstellt werden muss.
Die Einrichtung: Gedächtnis und Styleguide
Der Unterschied zwischen der Nutzung eines KI-Assistenten und der Zusammenarbeit mit einem ist die Konfiguration. Out of the box ist jedes KI-Tool generisch. Es kennt nicht Ihre Markenstimme, Ihre Terminologie, Ihre Inhaltsstandards oder Ihr Publikum. Es liefert vernünftige Ergebnisse, aber vernünftig ist nicht gut genug, wenn die Inhalte, die es erstellt, von Fin (unserem KI-Agenten) verwendet werden, um echte Kundenfragen zu beantworten.
Gedächtnis: Operator ein dauerhaftes Gedächtnis geben
Operator hat eine Gedächtnisfunktion, die über Gesprächsverläufe hinweg bestehen bleibt. Das klingt nach einer Kleinigkeit. Ist es aber nicht.
Ohne dauerhaftes Gedächtnis beginnt jeder Gesprächsverlauf bei Null. Man erklärt den Styleguide erneut. Man beschreibt das Framework erneut. Man stellt den Kontext wieder her, den man letzte Woche, letzten Monat oder vor einem Jahr etabliert hat. Es ist das KI-Äquivalent dazu, jeden Morgen einen neuen Kollegen einzuarbeiten.
Mit dauerhaftem Gedächtnis trägt Operator das Wissen Ihres Arbeitsbereichs weiter. Es kennt Ihre Terminologie. Es kennt Ihre Standards. Es kennt die Frameworks, die Sie ihm zur Anwendung mitgeteilt haben. Sie bauen diesen Kontext einmal auf, und er wächst mit der Zeit.
Etwas zum Gedächtnis hinzuzufügen ist einfach: In jedem Operator-Gespräch sagen Sie einfach, was es sich merken soll. Etwas wie „Speichere das in deinem Gedächtnis“ gefolgt vom Inhalt reicht aus. Operator bestätigt die Speicherung, und diese Information ist ab dann in jedem Gespräch verfügbar.
Das habe ich gerade im Gedächtnis von Operator gespeichert:
Der Styleguide – umfasst Ton, Formatierung, Großschreibung, Verlinkungskonventionen, US-Englisch-Rechtschreibung und Terminologieregeln.
Das Inhaltsbereitstellungs-Framework – 14 Faktoren, anhand derer jeder Inhalt bewertet wird, bevor er live geht.
Namenskonventionen – wie Artikel, interne Artikel und Makros in diesem Arbeitsbereich betitelt werden.
Arbeitsbereichskontext – wer was besitzt, welche Teams für welche Bereiche verantwortlich sind.
Die praktische Auswirkung: Wenn ich Operator bitte, Inhalte zu entwerfen oder zu aktualisieren, weiß er bereits, wie sie klingen sollen, welche Terminologie zu verwenden ist und welchen Standard sie erfüllen müssen. Ich muss das nicht jedes Mal angeben. Es ist die Basis.
Der Styleguide: Warum es wichtig ist, ihn einzubinden
Ein Styleguide funktioniert nur, wenn er konsequent angewendet wird. Das Problem bei menschlich durchgesetzten Styleguides ist, dass die Konsistenz von der Person abhängt: wie kürzlich sie ihn gelesen hat, wie hoch die kognitive Belastung an dem Tag ist, ob sie den einen Absatz bemerkt hat, der wieder ins britische Englisch zurückfällt.
Wenn der Styleguide im Gedächtnis von Operator ist, wird er jedes Mal angewendet. Jeder Entwurf verwendet Satzzeichen-Großschreibung für Überschriften. Jeder Artikel verwendet „teammate“ und nicht „agent“. Jede nummerierte Liste folgt der gleichen Struktur. Der Styleguide wird von einem Ziel zur tatsächlichen Ausgabe.
Das bedeutet auch, dass ich die Entwurfsarbeit mit Vertrauen abgeben kann. Wenn ich Operator bitte, einen Artikel von Grund auf zu erstellen, überprüfe ich ihn nicht zusätzlich auf Markenübereinstimmung. Das ist bereits erledigt.
So speichern Sie Ihren Styleguide im Gedächtnis von Operator
Tun Sie dies zuerst. Sobald gespeichert, wendet Operator Ihren Styleguide auf jeden Artikel an, den er in Ihrem Arbeitsbereich erstellt oder bearbeitet.
Gehen Sie zu Fin AI Agent > Operator.
Geben Sie im Composer (dem Texteingabefeld unten im Operator-Fenster) folgenden Text ein: ‚Dies ist unser knowledge base Styleguide. Beim Erstellen neuer Artikel oder Bearbeiten bestehender Inhalte müssen Sie sich jederzeit an diesen Guide halten.’ Fügen Sie dann Ihren Styleguide-Text direkt darunter ein und drücken Sie Senden, um die Nachricht an Operator zu übermitteln.
Wenn Operator den Styleguide speichert, sehen Sie eine Bestätigung wie: „Für zukünftige Gespräche gespeichert. Ich werde diesen Styleguide bei der Erstellung oder Bearbeitung von knowledge base-Inhalten in Ihrem Arbeitsbereich anwenden.“ Wenn Sie keine Bestätigung sehen, versuchen Sie, die Nachricht erneut zu senden.
Um die Einrichtung zu überprüfen, bitten Sie Operator zu prüfen, ob einer der Artikel in Ihrem help center mit den Regeln Ihres Styleguides übereinstimmt. Operator sollte Abweichungen markieren und Korrekturen vorschlagen. Hier ein Beispiel, wie Operator bestätigt, dass der Styleguide gespeichert ist und mit einem Audit fortfährt:
Hinweis: Um Ihren Styleguide im Gedächtnis zu aktualisieren, senden Sie Operator die aktualisierte Version mit demselben Anweisungstext, und er speichert die neue Version. Wenn Operator aufhört, den Guide konsequent anzuwenden, senden Sie ihn zu Beginn Ihres nächsten Gesprächs erneut als Erinnerung.
Lassen Sie Operator Ihnen Fragen stellen
Etwas, das ich erst nach einer Weile verstanden habe: Dass Operator mir Fragen stellt, ist eine Funktion, kein Problem.
Früher war ich frustriert, wenn Operator um Klarstellung bat, anstatt einfach etwas zu generieren. Ich wollte Geschwindigkeit. Was ich gelernt habe, ist, dass die Klarstellungsfragen ein Signal sind. Sie zeigen mir, wo meine Anfrage mehrdeutig war, wo Inhalte Lücken haben oder wo ich nicht genug Informationen gegeben habe.
Jetzt lade ich es aktiv ein. Wenn ich eine komplexe Aufgabe beginne, füge ich oft hinzu: „Wenn etwas unklar ist oder du mehr Informationen brauchst, um das gut zu machen, frag mich, bevor du einen Entwurf erstellst.“ Das Ergebnis ist besser. Die Iteration schneller. Und die Fragen, die Operator stellt, bringen oft Dinge ans Licht, die ich bewusst nicht bemerkt hatte.
Die Eingaben, die ich am häufigsten verwende
Ein guter Prompt ist ein Werkzeug. Diese verwende ich regelmäßig. Jeder Prompt wird in einem Gesprächsverlauf an Operator gesendet, der Ihre knowledge base durchsucht, relevante Inhalte abruft und mit Vorschlägen antwortet, die Sie überprüfen können. Kopieren und passen Sie sie an Ihren eigenen Prozess an.
Inhaltsbereitstellungsprüfung
Verwenden Sie dies nach dem Erstellen oder Bearbeiten eines Artikels, um ihn anhand aller 14 Inhaltsbereitstellungsfaktoren zu prüfen:
„Wie schneidet dieser Artikel im Vergleich zum in Ihrem Gedächtnis gespeicherten Inhaltsbereitstellungs-Framework ab? Für jeden der 14 Faktoren sagen Sie mir, ob dieser Inhalt besteht oder Verbesserungen benötigt, und erklären Sie warum. Geben Sie spezifische Umschreibungsvorschläge für alle Abschnitte, die nicht ausreichen, und fügen Sie beschreibenden Alt-Text zu Bildern hinzu. Berücksichtigen Sie zwei Zielgruppen: (1) einen Kunden, der den Artikel direkt liest, und (2) Fin, der diesen Inhalt abruft, um eine Kundenanfrage zu beantworten. Markieren Sie alles, was Verwirrung oder eine schlechte Erfahrung für beide verursachen könnte.“
Change-Impact-Scan
Verwenden Sie dies, wenn eine Produktänderung, eine Richtlinienaktualisierung oder eine Preisänderung eintrifft:
„Wir haben gerade folgende Änderung vorgenommen: [beschreiben Sie die Änderung]. Durchsuchen Sie die knowledge base nach Inhalten, die damit in Konflikt stehen oder davon betroffen sein könnten, rufen Sie die relevantesten Artikel ab und schlagen Sie die notwendigen spezifischen Aktualisierungen vor.“
Lückenidentifikation
Verwenden Sie dies, wenn Sie vermuten, dass zu einem Thema Inhalte fehlen:
„Wir haben nicht genügend Inhalte zu [Thema]. Suchen Sie nach allem, was damit zusammenhängt, um zu verstehen, was bereits existiert, und entwerfen Sie einen neuen Artikel, der die Lücke schließt. Markieren Sie alles, was Sie von mir vor dem Entwurf benötigen, wie spezifische Werte, UI-Pfade oder Verfügbarkeiten von Plänen, anstatt zu raten.“
Konsistenzprüfung
Verwenden Sie dies, wenn Sie eine Terminologieabweichung in der knowledge base bemerkt haben:
„Wir verwenden den Begriff [X] in einigen Artikeln und [Y] in anderen, um dasselbe zu bezeichnen. Finden Sie alle Vorkommen in der knowledge base und schlagen Sie Aktualisierungen vor, um sie auf [bevorzugten Begriff] abzustimmen.“
Zielgruppen-Klarheitsprüfung
Verwenden Sie dies bei Artikeln, die sich an neue oder weniger technische Kunden richten:
„Lesen Sie diesen Artikel wie jemand, der diese Funktion noch nie benutzt hat. Markieren Sie jeden Schritt, der Vorwissen voraussetzt, jeden Begriff, der nicht definiert ist, und jede Anweisung, die unklar ist, was als Nächstes passiert. Schlagen Sie spezifische Umschreibungen vor.“
Fin-Fehleruntersuchung
Verwenden Sie dies, wenn Fin eine Kundenfrage nicht genau beantworten konnte:
„Fin konnte eine Frage zu [Thema] im Gespräch [link] nicht beantworten. Durchsuchen Sie die knowledge base nach Inhalten zu diesem Thema, rufen Sie die relevantesten Ergebnisse ab und sagen Sie mir: Existieren die Inhalte und sind sie genau, existieren sie, sind aber schlecht strukturiert für Fin, oder gibt es eine echte Lücke, die neue Inhalte benötigt?“
Das 14-Faktoren-Inhaltsbereitstellungs-Framework
Die oben genannten Prompts basieren auf einem 14-Faktoren-Inhaltsbereitstellungs-Framework – einem Kriterienkatalog, der bestimmt, ob Inhalte bereit sind, von Fin zur Beantwortung von Kundenfragen verwendet zu werden. Für das vollständige Framework, einschließlich guter und schlechter Praxisbeispiele für jeden Faktor und einer vollständigen Checkliste, siehe Optimizing content for Fin.
Dies ist das vollständige Inhaltsbereitstellungs-Framework, das Sie im Gedächtnis von Operator speichern können:
Content Readiness is an Intercom feature that scores knowledge base content across 14 factors.
These factors must be applied as a checklist whenever creating or updating articles, snippets, or internal articles.
## Content Readiness Factors — Apply to all content
1. **disambiguation** — Avoid vague references like "this screen" or "the field shown above." Every reference must be self-descriptive. Don't use emoji (👇☝️) to point to visual content.
2. **visual_content_text** — Every image must have descriptive alt text explaining what the screenshot or diagram shows. A trailing colon followed by an image (with no alt text) is not acceptable — describe the visual in text too.
3. **undefined_terms** — Define abbreviations and product-specific terms on first use. Examples: CSV (comma-separated values), GDPR (General Data Protection Regulation), 2FA (two-factor authentication), Elasticsearch, UserMessage. Don't assume the reader knows internal terminology.
4. **structured_enumeration** — Multi-step processes must use numbered lists. Lists of items must use bullet points. Never describe steps or enumerations in flowing prose. If a sentence says "the following:" it must be followed by an actual list.
5. **query_answer_symmetry** — Headings should mirror how a customer would phrase a question. Avoid bare noun phrases ("Invite reminder emails") or bare imperatives ("Add a teammate"). Prefer "How to…" or question-form headings.
6. **self_contained_sections** — Every section must make sense if retrieved independently by Fin, without surrounding context. Avoid "as described above," "the field shown above," "Then…" as an opener, or references to prior steps without restating them.
7. **audience_specification** — State who the content is for and what permissions or plan access is required. Don't assume the reader knows their own role or access level.
8. **entity_distribution** — Repeat key entities (product names, feature names, the article's core topic) throughout the article — not just in the opening. Sections retrieved in isolation should still be identifiable as belonging to the right topic.
9. **semantic_chunk_boundaries** — Each section should cover one focused topic. Avoid mixing unrelated information in the same block. Long sections should be broken up with meaningful subheadings.
10. **restate_questions** — Tables and standalone blocks must include enough context to be understood without the heading hierarchy. Add an intro sentence before tables that states what the table covers and where it applies.
11. **overview_jtbd** — The opening paragraph must state the job(s) the reader will accomplish — not just the topic. "This article covers X" is weaker than "Use this article to do Y, troubleshoot Z, or understand W." 12. **instruction_completeness** — Step-by-step instructions must be complete end-to-end. Include what happens after the final step (confirmation dialogs, what to expect, next actions). Don't stop at "click Remove" without describing what follows.
13. **limitations_workarounds** — If a feature has known limitations, gaps, or workarounds, document them explicitly. Don't just say "some things aren't supported" — say which ones and what to do instead.
14. **numerical_clarity** — All numbers, thresholds, limits, durations, and quantities must be stated precisely. Avoid "some," "a few," "shortly," or vague ranges. Use exact values where known; ask the user if unknown.
## When to apply these Apply all 14 factors as a quality checklist when:- Creating a new article, snippet, or internal article - Proposing updates to existing content - Reviewing content for accuracy or completeness Flag any factor that would fail before submitting a proposal. If information needed to fix a factor (e.g. exact limits for numerical_clarity, or which plans are affected for audience_specification) is not available, ask the user rather than leaving it vague or fabricating it.
So führen Sie die Inhaltsbereitstellungsprüfung durch
Nach dem Erstellen oder Bearbeiten eines Artikels führe ich den ‚Inhaltsbereitstellungscheck‘-Prompt aus. Operator liefert eine Aufschlüsselung aller 14 Faktoren: ein Bestehen- oder Verbesserungsbedarf-Urteil und spezifische Umschreibungsvorschläge für alles, was nicht ausreicht. Er markiert nicht nur das Problem, sondern entwirft auch die Lösung.
Ich überprüfe die Antwort von Operator, genehmige die Vorschläge, denen ich zustimme, lehne die ab, die ich anders formulieren würde, und iteriere.
Es braucht mehr als einen Durchgang, und das ist normal
Inhalte bestehen selten alle 14 Faktoren beim ersten Check. Manchmal führt eine Lösung für einen Faktor zu einer Lücke bei einem anderen. Manchmal braucht ein Abschnitt eine strukturelle Änderung, die erst sichtbar wird, wenn die oberflächlichen Probleme gelöst sind.
Das ist kein Versagen des Frameworks oder des Tools. So funktioniert Qualität tatsächlich. Ein erster Entwurf, der 10 von 14 Faktoren besteht, ist ein guter erster Entwurf. Ein dritter Durchgang, der die restlichen vier schließt, ist ein großartiger Inhalt für Fin und Ihre Kunden.
Was das Framework Ihnen gibt, ist keine Perfektion beim ersten Versuch, sondern ein zuverlässiges System, um dorthin zu gelangen. Bevor ich es nutzte, hatte ich keinen konsistenten Weg zu wissen, wann ein Artikel fertig ist. Jetzt weiß ich es. Wenn alle 14 Faktoren bestehen, ist er fertig.