Your Slack answers what your docs can’t

Summary: The most accurate product knowledge at SaaS companies lives in Slack threads, not the help center. That's because product updates move fast, and documentation is always a step behind. This is getting worse because of AI chatbots that pull from your help center, so every gap in your help documentation turns into a wrong answer from your bot. We talked to dozens of support and knowledge teams to understand why this keeps happening and covered what some teams are doing differently to manage this.

Your threads are the real treasure 

Support leaders know where the answers actually are: scattered across 100s of Slack threads with engineering and shockingly not their own help centers.

One knowledge manager puts it bluntly: "Agents search Slack over our help centers because there's so much up-to-date information." She manages four help centers and nearly a thousand articles. She's not bad at her job. Slack’s just more up-to-date, and closer to the truth.

And this isn't an edge case. Across dozens of conversations with support and knowledge teams at SaaS companies, we kept finding the same pattern. The most accurate product knowledge in the company lives inside the little jumping button on your dock (cue the knockbrush).

How knowledge actually flows 

It's worth talking about the workflow of a knowledge manager, because from the outside, it seems simple enough. Their week is probably structured like this: 

1. Scan the release notes channel every morning. 

2. Check if any updates affect existing articles. 

3. Figure out which ones to edit (there might be ten articles that reference a feature that just changed). 

4. Open each article, and look for what specifically needs to change. 

5. Take new screenshots if the UI changed. 

6. Update the text. 

7. Make sure the bot will interpret the new version correctly. 

8. Finally, hit publish. And the cycle repeats. 

Multiply that by biweekly releases, or, at fast-moving companies, daily deployments, and you start to see why the help center is always behind Slack.

"Something that does stress me out is... sometimes I'm hoping that when I update articles, I'm catching everything." 

— Support Leader, SaaS company

But here’s another issue. They’re working blind. Your engineering team likely merged a PR today. Maybe this was noted down on a channel like #product-updates or #engineering, or maybe it wasn’t. A Linear ticket was marked as completed, and the team moved on. 

Somewhere downstream, however, a knowledge manager is trying to catch all of this. A job made painful by the fact that critical updates could be hiding inside any of the 35 channels. Well done on shipping 8 features in one week, Adam, but how is Emma going to support that customer when they finish onboarding and have questions?

One support lead told us she spends four to five hours a week just on this - figuring out what needs updating before she writes a single word. The help center gets updated eventually. Sometimes that same week. Sometimes not. In the meantime, Slack has the answer and the help center doesn't. 

The 80% that already exists

Here's the thing that surprised us. At the companies with the most mature processes, the PM's Slack post is already 80% of the finished help center article. There’s enough content and context in those updates. All that needs to be done is for someone to restructure it, add the (dreaded) screenshots, and upload it into the help center. That "someone" is usually one person who’s probably juggling a lot of other things.

At one company, they‘ve built a dedicated #just-launched Slack channel where PMs post structured blurbs every time a feature goes live. This is a strategic move, keeping all your knowledge structured and organised. And yet, it doesn't solve the problem, because turning a Slack blurb into a published, formatted, screenshot-rich help center article is a completely different kind of job.

At another company, a support lead described her relationship with the release notes channel like this: early on, she called it "my dream." Months later, the same channel had become too noisy, with updates coming through extremely fast. The backlog "just keeps getting backed up, backed up." Today, she struggles to keep up with her help documentation.

“I’ll be honest, we don't have a single Slack channel where it says this was just launched." 

— Knowledge manager, edtech company

Now, this (referring to the quote above) is the more realistic scenario because most Product teams are too pressed for time to post any updates at all. This leads to Product knowledge living in scattered threads across multiple channels. Just whatever someone happened to post, wherever they happened to post it. 

While the two companies described before are taking initiative to organise their data, this is not the norm.  

Why this matters more now 🤖

Maybe in 2018, this situation was okay. Manageable. But now we live in the world of LLMs. Added a chatbot to an already stale help desk? I guess you already know what happens next.

All AI chatbots run on information. And the quality of input determines the quality of output. Specifically, support AI chatbots run on the information they have access to, which is often your outdated help centres.

Every article on there trains the bot. And just like that, every gap in your docs is a question the bot can't answer. Every stale paragraph is a confidently wrong response waiting to happen. So naturally, the dejected user will raise a ticket, which will now be escalated to a human. A preventable problem, but a difficult one to prepare for.

"Someone will Slack me and be like, '@Holly, Decagon said this.' Then I'll have to be like, wait — what should it say? And where are the sources?"

— Senior knowledge manager, fintech company

One support lead told us their bot's reported resolution rate was "a lie — it's too high." The real rate, by his estimate, was almost half of what the dashboard showed. The bot was closing conversations without actually resolving them. And the root cause? The knowledge base it was drawing from didn't reflect the current product.

The uncomfortable truth

I'll be gentle. Actually, no I won't. 

If your agents don't trust your help center enough to search it first, why would your customers? And if your bot is only as good as your help center, what does it mean if your help center is always a week behind Slack? 

The knowledge pipeline at most SaaS companies was designed for a world where docs were a nice-to-have and updates happened quarterly. That world doesn't exist anymore. Product teams have ditched the usual 2-week sprint and are able to ship multiple times a day.

While great for customers, this pace creates intense pressure on support teams, who simply can't keep up. And the stakes are higher than ever - bots need current data to function, and customers expect self-service to actually work.

And if it doesn’t, they’ll come to your support team, where your agent has to apologize, explain that the docs/bots were wrong because your knowledge is outdated, and walk them through the actual process.

You've just turned a 40 cent self-service win into a trust problem with an escalated ticket that now costs your team $15 to resolve. Multiply that by a few dozen times a week, and now you’re dealing with frustrated users who are getting convinced that your support can't be trusted. 

And here's the kicker: they won't blame the bot. They'll blame your product.

So what can you actually do about it?  

I didn’t drag this on so long to give you nothing in the end. 

Dear leaders, managers, and directors, let me hold your hand when I say this. You cannot overhaul your entire knowledge pipeline tomorrow. But there are a few things we've seen work at the companies that are managing this better than most.

Make the Slack-to-docs gap visible. Most teams don't actually know how far behind their help center is. Select a random week of your release notes channel or your public changelog, if you have one, and check how many of those updates reflect in your docs today. The number will give you a concrete idea of how far you are falling behind. 

Automate. Set up a 2-step automation with tools like n8n or Zapier where you add a reacji to messages like a release note, a question from a co-worker, or feedback from a CSM, and route them into a Google Sheet. You now have an easily accessible repository of updates to apply to your docs!

Dedicate one specific channel. We’ve noticed that the companies that struggle most are the ones where product updates are scattered across a dozen channels and threads. The ones doing better have a single, dedicated channel where every customer-facing change gets posted. 

Get PMs to write the first 80%. The Slack post your PM already writes when a feature ships? That's most of the article. If you can get PMs to post updates in a slightly more structured format. The more detail, the easier it becomes for the knowledge manager. 

Stop treating docs like a separate workflow. At most companies, shipping a feature and documenting a feature are two completely separate processes owned by completely separate people. The teams doing this best have started treating documentation as part of the release itself, and not an afterthought that happens a week later. 

None of this fully solves the problem. The structural reality is that knowledge is created quickly in fast-moving and informal spaces (like Slack) but consumed in longer structured ones (your Help Desks). But the goal isn't perfection right now. Or, and this is what we're seeing more teams explore, you can rethink how knowledge moves between those two spaces in the first place.

In our future posts we’ll dig into systems teams have built to tackle this problem. For now, start with measuring the gap. While we don’t hope for it, you may be more behind than you imagine.




Image Courtesy Art Institute of Chicago