Owning knowledge management for Fin
Structure who owns Fin's knowledge so it stays accurate as you scale.
As your Fin deployment grows, someone has to keep its knowledge accurate, current, and complete. But who owns that work, and how do you structure it so it doesn’t quietly fall behind? The answer is less about a single job title than you might expect.
Prerequisites
Before you work through this lesson, it helps to have the following in place:
- Fin is live: You already have Fin deployed and automating some of your informational queries. This lesson is about sustaining an existing deployment, not standing one up.
- Familiarity with Fin’s core components: If you’re newer to Fin, start with the Launch Fin course, which covers launching Fin over chat in an initial pilot.
Video transcript
So when I started at Intercom a couple of years ago now, it was as a help center manager. However, with the advent of AI and using a range of support content to power our AI agent Fin. We quickly saw a need to manage our support content more holistically. Several content types were emerging to document knowledge in snippets, articles, PDFs, and public URLs to feed the AI agent. And so the knowledge manager was born to try and encompass all of this. Very interesting. Thanks for the insight there, Pev. So what does a typical day look like for you as a knowledge manager at Intercom? How do you prioritize your tasks, and what are the general responsibilities? So now that we've seen how effectively Fin can resolve customer queries using our support content, our knowledge base has grown dramatically to handle more and more types of questions customers have. From getting started to best practices and troubleshooting, Fin has to deal with a lot. Not only do we have more articles, the actual word count in our help center has almost doubled in the last year. Content is continuously added and improved as we learn from Fin's conversations. So this is definitely not a one man band anymore. I work with thirteen customer service agents who have dedicated time out of the inbox and handling queries to update and improve our support content. This includes both internal content the team uses in their day to day and our customer facing content. We call this team our knowledge specialty, and they're amazing. So every Monday, I'll set them up with our key focus for the week. This often involves actioning back office tickets, which anyone in the org can submit when they need a piece of knowledge creating or updating. It includes macros, snippets, and internal and public articles. They'll also help with large scale audits. For example, when we redesign a core feature or area of the product, this results in a lot of screenshots and navigational instructions which need updating. I'll get them set up with a tracking sheet to kick off the project, and they'll chip away at the content throughout the week. More regular work includes reviewing content, which hasn't been updated in the last six months to ensure it's still accurate, and also adding new knowledge. For example, when there's something we didn't have documented, which turns out to be expected product behavior, they'll add this to our content so that customers are also aware. I really love working with this group because they're so close to customers. They know exactly what kinds of questions and pain points customers have, and this helps me understand what content needs to be prioritized. They can also see the benefit of having well documented knowledge. This is twofold because it directly impacts the amount of inbound volume they deal with and makes their jobs easier by having great internal resources to hand when supporting customers in the Inbox. So there's a real incentive for them to make sure our content is well looked after. Plus, they know the product inside and out, so who better to ensure the accuracy of the support content? Yeah. Big shout out to them. Hooray to the team. Yeah. And having the Knowledge Specialty take care of the regular maintenance, if you will, then frees me up to work really closely with product managers before we release a new feature. Not only does this involve, obviously, writing new articles, but since we use Intercom for customer service ourselves, we're often our first beta testers. As a core user of the new Knowledge Hub and Fin AI Copilot, for example, I provided a lot of early feedback to the product teams on what was working or not working for us. These insights turn into those small iterations and help us launch new features successfully. Part of a new product release is also about staying really aligned with product marketing managers on messaging and key launch dates. So leading up to a release, I'll have weekly syncs with them to make sure the new support content I'm creating is what they're expecting, and I'll share the new article URLs with them so they can link to them from their outbound campaigns. I recently collaborated with them on three new proactive support guides we wanted to share with customers during their onboarding. So they'd identified some of the issues customers were having, and I was able to help address these with detailed guides we now link to from the product onboarding page to make the customer journey a bit smoother. But, like, all that I've listed is basically what we call business as usual at Intercom.
Knowledge management is a shared responsibility
Managing knowledge is far from a one-person job, especially as you grow as a business. The knowledge manager orchestrates rather than creating every piece of content alone.
Beth-Ann, who owns this work at Fin, describes it as a shared responsibility. Her Support team has dedicated time out of the inbox to flag gaps and improve content, and everyone from Product Managers to Engineers plays a role in keeping Fin’s knowledge current.
How the role scales
This is also how it scales naturally. At Fin, we started with Beth-Ann taking on knowledge work as part of her existing role. As the impact on resolution became clear, a small group of Support teammates began contributing a few hours a week. Those hours grew over time, and eventually the results justified bringing on a second full-time AI Knowledge Manager.
The real risk is isolation
The biggest risk isn’t that the work is too much for one person. It’s that the knowledge manager ends up working in isolation. If the person responsible for updating knowledge isn’t looped in before launches or major changes, and your Support team isn’t flagging content gaps from the inbox, even the best knowledge manager will fall behind. Those cross-functional partnerships are what make the role work.
Note: This is a summary of a framework that worked for us at our scale. We wanted to share it so you can see what’s actually involved in keeping knowledge properly maintained. If this shape fits your team, that’s great. If it doesn’t, take what’s useful from it and build your own version instead.
As Beth-Ann puts it:
“When these workstreams are in motion, knowledge management becomes a dynamic, shared practice that continuously evolves to meet the needs of your team and your customers.”
