There's a version of knowledge management that most people know well. It involves opening five browser tabs, cross-referencing numerous docs, manually searching a help center for articles you half-remember writing, and spending a Tuesday afternoon updating a pricing paragraph across 12 different articles, one by one.
That was my job not long ago. I'd built up an almost encyclopedic mental map of where content lived, what it said, and what it might conflict with if something changed. That knowledge lived in my head. Which meant the moment I was out of the office, or the moment something changed faster than I could track it, the cracks started showing.
Then I started using Fin Operator as a core part of my workflow. What used to take a few hours now takes a few minutes. This article is for knowledge managers and content teammates maintaining a help center. Use it to configure Operator for your workflow, run change impact scans when product updates land, fill content gaps, and validate every piece of content against a 14-factor readiness framework.
Note: Fin Operator is currently in beta. All content changes Operator proposes require your review and approval before going live, nothing is published automatically.
Before: the manual knowledge management reality
When a product change came through, say a pricing update, a new feature rolling out to all plans, or a deprecated integration, my process looked something like this:
Search the help center manually for anything that might mention it.
Open each article, read it in full, decide whether it needed updating.
Make the edit, save in draft, and move to the next one. When ship day came, I'd republish those updated articles.
Hope I hadn't missed anything.
The problem wasn't any single step. It was the cumulative weight of it. A medium-sized product change could touch 8 to 10 articles. A significant one could touch more. And because my colleague Beth and I were the ones who had to know where everything was, the system only worked as long as we did.
After: what the same process looks like with Operator
Now when a product change comes through, I open a conversation thread with Operator and describe what's changed. Operator searches the knowledge base, surfaces the relevant content, and proposes the updates, directly in the same conversation, ready for me to review.
I don't need to know where the content lives. I don't need to open 10 tabs. I review the proposals, approve what's right, push back on what isn't, and we iterate. The whole thing, for a change that would have taken me two to three hours, takes under 10 minutes.
But the speed isn't the most valuable thing. The most valuable thing is consistency. When you're manually updating articles, inconsistency creeps in. You miss one. You word something slightly differently across two articles. You update the snippet but not the public article. With Operator, the search is systematic. The proposals are grounded in what actually exists. Nothing gets missed.
What this role actually is now
My title is AI Knowledge Manager. The role has always had two sides to it: the content writing, and the operational work of keeping a knowledge base current, consistent, and accurate across thousands of articles.
What Operator has changed is the second half. The manual retrieval work is mostly gone: the searching, the cross-referencing, the hunting for what exists before I can even start writing. That frees up more of my time for the part that actually requires judgment: deciding what content should cover, what standard it should be held to, what should be updated, and what needs to be created.
The setup: memory and style guide
The difference between using an AI assistant and working with one is configuration. Out of the box, any AI tool is generic. It doesn't know your brand voice, your terminology, your content standards, or your audience. It produces reasonable output, but reasonable isn't good enough when the content it helps you create is being used by Fin (our AI agent) to answer real customer questions.
Memory: giving Operator a brain that persists
Operator has a memory feature that persists across conversation threads. That sounds like a small thing. It isn't.
Without persistent memory, every conversation thread starts from scratch. You re-explain your style guide. You re-describe your framework. You re-establish context that you established last week, last month, a year ago. It's the AI equivalent of onboarding a new colleague every single morning.
With persistent memory, Operator carries your workspace knowledge forward. It knows your terminology. It knows your standards. It knows the frameworks you've told it to apply. You build that context once, and it compounds over time.
Adding something to memory is straightforward: in any Operator conversation, just tell it what you want it to remember. Something like "Save this to your memory" followed by the content is enough. Operator confirms it's been saved, and that information is available in every conversation from then on.
Here's what I have saved in Operator's memory right now:
The style guide — covering tone, formatting, capitalization, linking conventions, US English spelling, and terminology rules.
The content readiness framework — 14 factors that every piece of content is evaluated against before it goes live.
Naming conventions — how articles, internal articles, and macros are titled in this workspace.
Workspace context — who owns what, which teams are responsible for which areas.
The practical effect: when I ask Operator to draft or update content, it already knows how it should sound, what terminology to use, and what standard it needs to meet. I'm not prompting for those things every time. They're the baseline.
The style guide: why baking it in matters
A style guide only works if it's applied consistently. The problem with human-enforced style guides is that consistency depends on the person: how recently they read it, how much cognitive load they're carrying that day, whether they noticed the one paragraph that slips back into British English.
When the style guide is in Operator's memory, it's applied every time. Every draft uses sentence case for headings. Every article uses 'teammate' not 'agent'. Every numbered list follows the same structure. The style guide stops being an aspiration and becomes the actual output.
It also means I can hand off drafting work with confidence. When I ask Operator to create an article from scratch, I'm not reviewing it for brand alignment on top of everything else. That's already handled.
How to save your style guide to Operator memory
Do this first. Once saved, Operator applies your style guide to every article it creates or edits in your workspace.
Go to Fin AI Agent > Operator.
In the composer (the text input at the bottom of the Operator window), enter the following text: 'This is our knowledge base style guide. When generating new articles or editing existing content, you must adhere to this guide at all times.' Then paste your style guide text directly below it and press Send to submit the message to Operator.
When Operator saves the style guide, you'll see a confirmation like: "Saved for future conversations. I'll apply this style guide whenever creating or editing knowledge base content in your workspace." If you don't see a confirmation, try sending the message again.
To verify the setup worked, ask Operator to check if one of the articles in your help center aligns with your style guide rules. Operator should flag any deviations and suggest corrections. Here's an example of Operator confirming the style guide has been saved and moving on to an audit:
Note: To update your style guide in memory, send Operator the updated version with the same instruction text and it will save the new version. If Operator stops applying the guide consistently, re-send it at the start of your next conversation as a reminder.
Let Operator ask you questions
One thing that took me a while to figure out: Operator asking me questions is a feature, not a problem.
Early on, I'd get frustrated when Operator asked for clarification instead of just generating something. I wanted speed. What I learned is that the clarification questions are a signal. They're telling me where my request was ambiguous, where the content has gaps, or where I haven't given it enough to work with.
Now I actively invite it. When I start a complex task, I'll often add: "If anything is unclear or if you need more information to do this well, ask me before you draft." The output is better. The iteration is faster. And the questions Operator asks often surface things I hadn't consciously noticed were missing.
The prompts I use most
A good prompt is a tool. These are the ones I reach for regularly. Each prompt is sent to Operator in a conversation thread and Operator searches your knowledge base, retrieves relevant content, and responds with proposals for you to review. Copy and adapt them to your own process.
Content readiness check
Use this after creating or editing any article to check it against all 14 content readiness factors:
"How does this article measure up against the content readiness framework saved in your memory? For each of the 14 factors, tell me whether this content passes or needs improvement, and explain why. Provide specific rewrite suggestions for any sections that fall short, and add descriptive alt text to any images. Consider two audiences: (1) a customer reading the article directly, and (2) Fin retrieving this content to answer a customer query. Flag anything that would cause confusion or a poor experience for either."
Change impact scan
Use this when a product change, policy update, or pricing change comes through:
"We've just made the following change: [describe the change]. Search the knowledge base for any content that might conflict with or be affected by this, retrieve the most relevant articles, and propose the specific updates needed."
Gap identification
Use this when you suspect content is missing on a topic:
"We don't have sufficient content on [topic]. Search for anything related to understand what already exists, then draft a new article that fills the gap. Flag anything you need from me before drafting, like specific values, UI paths, or plan availability, rather than guessing."
Consistency check
Use this when you've noticed terminology drift across the knowledge base:
"We use the term [X] in some articles and [Y] in others to refer to the same thing. Find all instances across the knowledge base and propose updates to align them on [preferred term]."
Audience clarity check
Use this on any article aimed at new or less technical customers:
"Read this article as someone who has never used this feature before. Flag any step that assumes prior knowledge, any term that isn't defined, and any instruction that's ambiguous about what happens next. Suggest specific rewrites."
Fin failure investigation
Use this when Fin couldn't answer a customer question accurately:
"Fin failed to answer a question about [topic] in conversation [link]. Search the knowledge base for content related to this topic, retrieve the most relevant results, and tell me: does the content exist and is it accurate, does it exist but is poorly structured for Fin to retrieve, or is there a genuine gap that needs new content?"
The 14-factor content readiness framework
The prompts above are built around a 14-factor content readiness framework — a set of criteria that determines whether content is ready for Fin to use when answering customer questions. For the full framework, including good and poor practice examples for each factor and a complete checklist, see Optimizing content for Fin.
This is the full content readiness framework you can save to Operator's memory:
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.
How to run the content readiness check
After creating or editing any article, I run the ‘Content readiness check’ prompt. Operator returns a breakdown across all 14 factors: a pass or needs improvement verdict, and specific rewrite suggestions for anything that falls short. It doesn’t just flag the problem, it drafts the fix.
I review Operator’s response, approve the proposals I agree with, push back on the ones I’d phrase differently, and iterate.
It takes more than one pass, and that's normal
Content rarely passes all 14 factors on the first check. Sometimes a fix for one factor introduces a gap in another. Sometimes a section needs a structural change that only becomes apparent once the surface-level issues are resolved.
That isn't a failure of the framework or the tool. It's how quality actually works. A first draft that passes 10 of 14 factors is a good first draft. A third pass that closes the remaining four is a great piece of content for Fin and your customers to read.
What the framework gives you isn't perfection on the first try; it's a reliable system for getting there. Before I used it, I didn't have a consistent way to know when an article was done. Now I do. When all 14 factors pass, it's done.
Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts