FeverBee – Community Consultancy

Read This Before Your Next Community Migration

Richard Millington — Mon, 27 Apr 2026 14:47:13 +0000

TL;DR: Six processes decide whether your migration succeeds or disappoints: the right team, selecting the right problem, the right migration strategy, the right data decisions, the right field mapping, and early testing. Don’t skip any of them.

Over the past few months, I’ve spoken with several organizations that haven’t been happy with their recent community migration.

The common complaints include:

The platform doesn’t have the features they thought it did.
The platform’s features aren’t working as well as they thought.
They’ve lost data in the process.
It wasn’t the right platform for their use-case.

It’s genuinely painful to hear about organizations that invest hundreds of thousands of dollars, as well as countless hours and emotional labor, for an experience that turns out badly.

Each time I hear this story, I try to dig deeper into what happened. Typically, one of two things happened.

A tiny community team with limited experience in complex platform migrations tried to shepherd the process through themselves. They weren’t given the support or guidance they needed. So they go down the journey alone and tackle each platform as it arises without the experience to avoid common mistakes.
The majority of the process was outsourced to a third party (typically a vendor/implementing partner). This avoids most technical problems but not the strategic ones. Once the migration is complete, they find the platform works – but doesn’t always do what they wanted.

The real problem is almost always a variation of the same problem: poor processes.

Migrations Are Poorly Executed Because They’re Misunderstood

From the outside, a platform migration probably resembles a process of:

Select the vendor we will migrate to.
Migrate all the data across.
Launch it with a good communications program to members.

What it actually looks like in practice is a six-to-twelve-month program involving:

Difficult decisions about data you’d rather not deal with.
Stakeholders who appear late with strong opinions.
Integrations that don’t map cleanly.
Data that doesn’t map at all.
A vendor whose priorities don’t perfectly align with yours.
Content that nobody wants to take responsibility for cleaning up.
And a launch date that keeps moving.

…all while still running the community you’re supposed to be migrating.

How FeverBee Helps Implement Successful Migrations

Our role is to embed the right practices right at the beginning of the project to guide clients to the right outcome.

1) Build and Run The Right Community Migration Team

Two people from the community team shouldn’t be liaising with the vendor and trying to tackle this alone.

We first need to create the right working group (or steering committee).

This group needs to involve the executive sponsor (who is proactively involved), IT representatives, members of the community team, a project manager (if not ourselves), and potentially folks from customer support, marketing, or other interested departments.

If you don’t bring the right people together at the beginning, you’ll regret it for the rest of the project.

Once you have the team, you need to implement best practices for managing it. This means proper:

Project management. An up-to-date timeline with clear milestones and moments when people will need to be involved so they can plan their availability in advance.
Roles and responsibilities. Use a RACI chart. You will need folks for data quality control, integration testers, clear sign-off moments and more.
Regular bi-weekly meetings (weekly tends to be too frequent).
Weekly updates. Keep everyone on the same page.

2) Ensure You’re Solving The Real Problem(s)

Migrating a community incurs a huge opportunity cost.

The time, resources, and goodwill you expend on the migration is time you can’t spend on a dozen other programs that might improve your community.

This is why you should migrate only when it’s the next phase of your community strategy.

You shouldn’t do it just because you’re tired of the platform or it feels outdated — but because it solves a specific challenge that your community needs to overcome to achieve its goals. And you should be able to articulate the challenge clearly.

If you don’t clearly define the problem, it’s easy to get swept up in scope creep, add new features that someone likes, experience delays, and end up with a bloated mess.

The first step then, is to ensure our clients have a clear problem statement to work from. This typically includes:

Deciding which of the five strategies they’re pursuing.
Gathering stakeholder needs through workflow-specific questions.
Evaluating the technology environment to understand key trends for the years ahead.
Deciding which audiences your community will serve in the future (and which it won’t).
Deciding where your community adds unique value, and align the process accordingly.

It helps to use external consultants to work through these problems with you — it eliminates internal bias and ensures best practices are followed.

By the end, you should be able to articulate a very clear, specific problem statement.

A bad problem statement looks like:

“Our current platform feels dated and the new one has better features and a more modern look that the team prefers.”

A good problem statement is specific, member-facing, and tied to a measurable outcome. It names the audience, identifies the friction or gap, and connects it to a business or community goal. For example:

“Our enterprise customers can’t find peer-validated answers to technical implementation questions, which is increasing support ticket volume and reducing product adoption. Our current platform’s search and taxonomy limitations mean we can’t surface the right content to the right people at the right time. We need a platform that can support structured knowledge management at scale.”

Don’t move forward until everyone is aligned on the problem you’re solving.

The critical thing this step achieves is that it forces through most of the critical decisions as early as possible.

3) Select The Right Migration Strategy

Right at the beginning, we need clients to decide which of the four major migration approaches they’ll use. You have four options here:

Hard cutover. This is where you close the old platform and launch the new one on the same date. This is the simplest to manage; it forces adoption, but it also entails a huge risk if something doesn’t work, and it can be tough on search traffic. There’s no fallback if something breaks.
Parallel running. This is where both platforms run simultaneously. If there’s any issue, can you quickly switch back to the old one? You might have an old one running at a different URL or the new one running at a new URL for a short time. The downside of this is that it can create confusion, double the maintenance burden, and take longer. It also simply costs more. This is quite rare in practice.
Phased Migration. This is where you migrate the community in stages. This gives you a way to test out the new community before making the big change. In this case, you might migrate specific content categories, audiences, geographic areas, or use cases first. This reduces the risk but often increases the cost and timeline.
Soft launch/beta migration. This is where you roll out the new platform launches to a small group of members first (often power users or volunteers) before a full rollout, allowing you to test and refine the experience before the wider community transitions across. This tends to happen only when moving to a new platform category (e.g., Slack to forums).

Here’s how to pick. Option 1 (hard cutover) is what most teams default to because it’s simplest — just accept that it carries the most risk if something breaks. Option 3 (phased migration) is what we usually recommend: the added time and cost buy you real protection against a bad outcome. Option 4 (soft launch) is a niche fit when you’re changing platform category — for example, moving from Slack to a forum. Option 2 (parallel running) is rare in practice; reserve it for regulated environments or cases where the ability to roll back has to stay on the table. Whatever you pick, commit to it early. The choice cascades through every other decision in the project plan.

Also, decide what needs to be migrated on day 1 vs. what can be migrated over time.

The common mistake in a migration is trying to get everything perfect and in place on day one. This tends to cause significant stress, delays, and overruns.

A far better approach is to draw a clear line between what’s a “must have” on day one and what can be improved post-migration. It’s incredibly important not to get stuck on the inverse 80/20 rule (i.e., spending 80% of your time on the least important 20% of the project).

You need to separate the critical work that can get done today from the roadmap improvements that can be implemented over the following months. This means planning very clearly what is a must-have and what is a nice-to-have.

4) Force Yourself To Make The Critical Data Decisions

Data is too often considered an IT task. And IT can usually successfully migrate data from one system to another by mapping fields, running scripts, and loading records.

The problem here is that the IT team often makes the critical decisions you should be making in the process.

I know one IT team that recently migrated 1.8m threads from one platform to another and declared the migration a success because the record count matched.

Yet six months later, the community team is seeing that outdated content is surfacing in search results more frequently than ever before.

The IT team can migrate data, but they can’t tell you which discussions are no longer accurate and should be archived, or whether your taxonomy reflects member behaviors, or even whether a piece of content is still relevant.

Your goal isn’t to perform a simple lift-and-shift. It’s time to take this rare moment to decide what data should be part of your community knowledge going forward.

The more you cut at this stage, the better the community will be for everyone.

In practice, this means we usually ensure clients:

Set a minimum quality threshold for what gets migrated. Any content that attracts no traffic, is more than two years old, falls into categories of products that are no longer supported, and/or isn’t included in the Google Search Index can be noindexed, archived, or simply deleted entirely. But agree on the rules early. Often, content related to products the company no longer sells is ripe for removal. You might also zero in on unanswered questions — does it make sense to you to migrate questions that never received a response?
Undertake a community data audit. Based on these rules, undertake a community data audit. Begin at the category level and decide which categories of discussion you won’t migrate across. Then filter the remaining discussions into the relevant groups (deleted, archived, noindexed). At this point, you might have saved yourself the effort of migrating a vast amount of content.
Review the remaining discussions. Undertake an audit of the remaining discussions to identify discussions that fail data quality standards. This might include duplicate, contradicting, or decayed answers. It might include answers with missing responses or simply those lacking the right freshness signals. Zero in on the discussions where the community provides the most value. At this stage, you can typically archive/merge/update many discussions and reduce the number being migrated across.
Decide on the new taxonomy. Review the existing taxonomy structure and make sure you’re clear on the category structure, tags, content types, resolution status, and any custom fields you might use.
Decide which members you will migrate across. Don’t migrate dormant accounts. Decide what “dormant” means for you, then send an email asking people to log in if they wish to retain their account access. You might also wish to review your member retention policy going forward with regards to GDPR (how long will you keep member data?).
Assign business owners. Community owners need to be assigned to specific data domains; someone owns content, someone owns member data, and someone owns taxonomy and navigation. They’re the ones who define what “good” looks like: which content is worth migrating, what gets archived, and what gets deleted entirely. They also need to sign off on test migrations, not just confirming that the data moved, but that the content is correct, findable, and still relevant.

This should ideally result in a clear data decision document that IT can use when migrating the data and ensuring no unnecessary data is migrated.

Again, make these decisions as early as possible.

5) Lead The Data-Field Mapping

Generally speaking, community folks should typically take the lead on matching data fields between platforms. And you should be fully aware of what does and doesn’t match.

You might find that some data fields can’t easily carry across. Passwords, for example, are encrypted and never transferred; hence, resetting passwords is always required after a platform change. Private messages also don’t typically migrate well.

Our steps here usually include:

Building a complete data field inventory. Before any mapping begins, we list every data field on the current platform: content, member profiles, roles, permissions, gamification, tags, metadata, and engagement data. Don’t rely on the vendor or IT to produce this list. You’re more likely to know what exists and what matters.
Identifying what maps cleanly to your new platform, what maps loosely, and what doesn’t map at all. Here we go field by field and categorize each one. Clean maps require no decisions. Loose maps require a judgment call about where the data should land on the new platform. Non-maps require a decision about whether to drop the data, transform it, or find a workaround. Pay special attention to gamification data.
Making an explicit decision for every non-mapping field. Don’t let gaps get deferred. For each field that doesn’t map (e.g. private messages, member photos, gamification elements, custom tags, etc.), we decide whether to: migrate with transformation, archive, communicate to members, or drop entirely. Then we document the decision and who made it.
Building a member communications plan around the gaps. Be mindful that members might complain about anything they lose, so we build a communications plan that flags what they will lose and advises them on how to retain/export the data (if possible). Anything related to member photos, gamification, and private messages is worth flagging.
Getting formal sign-off on the mapping document. Before full migration begins, we need a named business owner to sign off on the complete field mapping. This protects you if decisions get questioned later and ensures accountability sits in the right place.

Sometimes tags and labels for discussions don’t easily transfer across either. This is important from both a communication perspective (preparing members) and a knowledge perspective — you need to be aware of what does and doesn’t map.

6) Run Early Data and Integration Testing

If you’re not hands-on with the early data and integration testing, mistakes can easily slip in.

We need to check that all the data fields have been matched accurately and that there are no obvious issues. LLM tools can help here, but nothing beats the human eye and good judgment.

Request a data sample as early as possible. Different platform vendors have different rules about providing you with a full export of your data. Some will be good vendors and help you. Others will give you just one big data dump and charge you excessively for any additional requests. But you need to request a data sample as early as possible. Not all vendors have a good track record of providing you with data access.
Run multiple small test migrations before the full migration. Don’t wait until you’re ready to migrate everything. Transfer batches of data early, review the output, fix any issues, and rerun. Do this as early as you possibly can. Problems caught in a test batch cost a fraction of what they cost post-launch.
Use random sampling to review migrated content. Randomly sample across content categories, member types, and date ranges to catch issues that only appear in specific conditions. LLMs can certainly help with a review here and flag issues, but nothing really beats the human eye for checking that all of this is accurate and as it should be. And don’t rely on the IT team to do this — the IT team can confirm the record counts match, but only the community team can check it looks right, reads correctly, and makes sense in your new platform’s architecture.
Test every integration independently and end-to-end. The same principle from above applies to integrations, too. Test every connection your community has with other systems (e.g., CRM, SSO, ticketing, analytics, email, etc.). These should be tested in isolation and as part of the full system. As with the records, assign a named person to do this and check it.
Log every issue found and track it to resolution. Every single problem identified needs to be logged and tracked with your vendor or implementing partner to resolution. And every problem needs to be retested before going live.

Don’t Go Through This Process Alone

My advice is that if you don’t have migration experience, don’t go through the process alone.

Get help to ensure you select the right platform (we’ll cover this separately), solve the right problems, and achieve the most seamless, beneficial outcome possible.

The result should never be just a lift-and-shift. It should be a community experience that’s set within your modern realities but designed for the future. It should be clearly better than what came before, and a decision you can live with for the next few years.

If you’re about to migrate, or you’re in the middle of one that isn’t going well, drop us a line. We can take on most of the heavy lifting to ensure your migration is a success.

The post Read This Before Your Next Community Migration first appeared on FeverBee - Community Consultancy.

Moving From Slack/Discord To A Forum: Don’t Make The Most Common Mistake

Richard Millington — Mon, 13 Apr 2026 06:29:07 +0000

I can’t stress enough the difference between shifting from a chat platform to a forum (or question-and-answer) platform.

Sometimes the shift is natural. Members were primarily using the chat platform as a question-and-answer platform anyway. In which case, it was the wrong platform to begin with, and the shift to a forum is correcting the initial error.

At other times, though, it’s asking members to change both their behavior and their perception of the community’s value. It’s a little like asking a group of friends, used to a free-flowing nature of discussions, to suddenly have to come up with precise questions and receive precise answers in a facilitated environment.

It can happen, but it’s a very different kind of experience.

And that can be a problem.

Are The Costs of Change Experiences Quicker Than The Benefits?

The worst thing to do is to try to copy the existing Slack/Discord experience.

The most common approach is to replicate the channels on Slack/Discord, send a series of messages asking members to use the new forum experience with a countdown, and then close down the Slack/Discord channels.

This runs into one obvious problem: the costs of the change to members (more friction in the user experience) are recognised much faster than the benefits.

In a chat experience, you skim what people have been saying, type a comment, and hit ‘enter’. That’s it, your comment appears (and it is soon buried by other comments – both part of the charm and cost of chat).

But in a forum, you have to type a subject line, write out a post, categorise it, possibly tag it, and then hit enter. This additional friction may lead to higher-quality debate, but it feels burdensome to members used to a chat experience.

This is often the result of a misalignment between what the organisation wants to offer (gamification, easier-to-follow discussions, better integration with internal systems) and members’ desires (an easy-to-use experience).

As a rule, you risk member backlash and declining engagement.

The solution is to recognise that you can’t offer a forum experience to replace a chat experience. The comparisons members will make will work against you.

Moving from one experience to another isn’t just a technology change; it’s a change in behavior and in the community’s value perception.

Create A New Thing…A Much Better Thing

Instead of simply replicating the old thing – i.e., ‘here’s a new place for you to chat’ – you have to create a different value proposition.

And that value proposition has to be immediate and obvious, not something which will only be realised over the long term. “Gamification” and “easier to follow discussions” are examples of value that will only be clearly visible over a longer period of time.

And this value proposition should embrace the unique advantages of a forum over chat. I.e., What kind of activity would make sense to have in a forum that you wouldn’t be able to have in chat?

This might include:

“Solve This Once And For All” Threads. Members collaborate to produce the definitive answers to a recurring issue, then it’s pinned and updated over time.
“Solve My [x].” Members post a full write-up (problem → process → outcome) and receive threaded feedback, not just emoji reactions.
Peer Review Threads. Members upload work (slides, code, docs) and receive threaded, topic-specific feedback.
Ask for a Review” Sections. Members request feedback on a product setup, campaign, or configuration, replies stay tied to the request forever.
Monthly Expert Clinics. One topic per month, members submit questions in advance, expert replies in depth, all stored + indexed forever.
Template / Playbook Exchanges. Members upload files, screenshots, workflows – future members can find, reuse, and iterate.
Research Collaborations. Structured threads where members contribute data, screenshots, survey inputs, etc., and the findings are summarised at the top.
“Show Your Setup” Galleries. Members post photos, configs, dashboards, and code blocks, which are impossible to scroll through and retain in chat.
Multi-Week Challenges (progress tracked per member). e.g. “30-Day Implementation Sprint” — each person replies weekly with screenshots/progress.
Structured Debates. 2–3 side arguments, moderated, with citations and threaded counter-replies, not real-time chaos.
Beta Feature Feedback Hubs. One thread per feature, tagged by status (Planned, In Review, Released), linked to release notes.
Crowdsourced “Glossary of Terms” Thread. Members supply definitions, vote, and refine. Searchable, linkable, not buried like Slack messages.
“Hall of Fame” Knowledge Threads. e.g. “The Best Automation Scripts Ever Written”, curated, updated, forever referenced.
Persona-Based Rooms. Instead of channels, you have structured categories (Developers, Marketers, Admins) with pinned guides and FAQs.
Idea Tournaments. Members submit proposals, others vote & comment, moderator advances the top 8 → final winner.
Post-Event Knowledge Drops. After webinars, conferences, or workshops, slides, takeaways, recordings Q&A captured and archived.
“Lessons Learned” Retrospectives. One thread per major mistake, members add similar experiences – becomes a collective safety net of insights.

You can come up with plenty of your own examples, I’m sure.

But now you’re using a forum in a way you couldn’t (or wouldn’t) use Slack/Discord.

You’re not letting members compare friction levels across community platforms (which is a losing battle).

You’re instead pioneering a new way to build and engage with a community. One that is less about the ephemeral nature of chat and more about building a structured knowledge database, a database that will prove eternally useful.

Run Both (At Least For A While)

Don’t close down chat when the community is launched. Run both – at least for a while. Use the chat to promote community activities.

Set up an automation to post new forum discussions to Slack/Discord channels to drive activity back to the forum. Remind members who post support-related questions in chat that the forum is the best place to continue their support requests.

Over a relatively short period, activity will naturally shift. That’s because member preferences will shift. You won’t be forced to deal with the blowback from members resistant to the forum. They will simply find the activities published in the forum more valuable and engaging than those in chat.

After a few months, you should be able to close down the previous channels and rely solely on the forum (although it’s worth noting that many have both running for a period of time).

Good luck!

The post Moving From Slack/Discord To A Forum: Don’t Make The Most Common Mistake first appeared on FeverBee - Community Consultancy.

It’s Time To Add Friction (And What Happened When We Did)

Richard Millington — Sat, 28 Mar 2026 17:01:13 +0000

What Are We Optimising For Anymore?

For the best part of twenty years, we’ve been optimising enterprise communities for engagement; more posts, more replies, more members, more activity, more deflection.

If the graphs went up – the majority of people didn’t think too deeply beyond that.

There are generally two ways to increase engagement;

Increase people’s motivation to engage.
Reduce the friction to engage.

The former is much harder than the latter, so over the course of twenty years, we’ve been on a relentless mission to lower the friction to engaging.

This meant:

Single sign-on. Removing the separate login so members could access the community with their existing credentials.
Gamification. Giving points and badges for every post, reply, login etc..
One-click reactions. Adding likes, upvotes, and emoji reactions so people could participate without writing anything.
Email notification triggers. Sending digest emails, “you haven’t visited in a while” reminders, and reply notifications to pull people back in.
Removing onboarding steps. Cutting profile completion, interest selection, and community guidelines from the sign-up flow to get people posting faster.
Auto-suggested content. Showing trending topics, recommended threads, and “people also asked” to reduce the effort of finding something to engage with.
Lowering moderation barriers. Pre-approving new members, reducing content review queues, and letting posts go live instantly rather than holding them for approval.

The more members, content, and activity we had, the better. The graphs went up!

There are obvious benefits of more engagement, too. You get a greater diversity of responses, more people to connect with, and a lower response time.

But these are now outweighed by bigger factors

A greater volume of content makes it harder for people to find the answer they’re looking for.
More content confuses the knowledge-retrieval AI and leads to greater cleanup effort later.
More people discourage people from feeling a sense of connection with one another.

None of the five possible futures for enterprise communities depends on driving as much engagement as possible.

Having a big party doesn’t mean everyone had a meaningful conversation. You just have a big cleanup afterwards.

So what if we begin adding friction?

Two Big Changes We Made To A Client’s Community

We’ve been trying exactly this with a mid-tier SaaS community over the past two months.

We made two specific changes:

We began approving members. We asked members to complete a short form to be approved for membership. This asked for some basic details about them and what they could contribute to the community. We also asked them to agree to two specific things. First, to take the effort to respond to the answers they received without disappearing, and two to take the time to construct questions people could answer.
We required people to complete a different process to ask a question. Instead of letting members ask a question in a box, we created a question wizard. Essentially, we would ask THEM questions to describe the issue (product type, what they have already tried, ideal outcome, any constraints, etc.).

(Our first attempt let members bypass the wizard and write a question as normal. Almost everyone did exactly that. So we removed it).

These weren’t random interventions. We spent time analysing this community’s data to understand where the quality breakdown was actually happening.

The question wizard was designed around the five most common reasons questions went unanswered in this particular community: missing product version, no description of what the member had already tried, vague problem descriptions, duplicate questions that had already been answered, and questions posted in the wrong category.

The approval form was shaped by patterns we’ve seen across dozens of client projects about what separates members who contribute long-term from those who post once and disappear.

The two commitments we asked for (respond to your answers, take time to construct your question) weren’t arbitrary. They mirror the behaviours we’ve consistently seen in the most valuable community members.

The bypass lesson was also worth noting. If you offer the easy path alongside the hard path, people will always take the easy path. You have to commit to the friction. Half-measures don’t work.

The Results

We’ve only been running this for two months, but comparing March 2025 to March 2026 gives us the cleanest year-on-year comparison.

The results have been genuinely interesting.

Total post volume dropped by around 20%. Probably due to the following, and the increased difficulty of asking a question.
New member registrations declined, too. The approval filters deterred some people from even trying to get through them, which filter out those who aren’t willing to invest even a small amount of effort.

But here’s what went up:

Average question length increased by 87%. Members were providing more context, more detail about what they’d already tried, and clearer descriptions of their situation. This turned out to be a surprisingly insightful thing to measure.
The answer rate improved by 23%. A higher percentage of threads received at least one response.
The accepted solution rate increased by 73%. More threads ended with a marked solution, meaning the answers given actually resolved the problem (or the new members were simply more inclined to mark them as accepted solutions).
Member retention improved by 60%. A significantly higher percentage of approved members went on to make a second post, with no further increase in email prompts.
Community’s content started being retrieved more frequently in the organisation’s internal RAG search as citations, up roughly 55% compared to the pre-friction* average. The AI tools were pulling from community threads more often.

* Community content was being retrieved roughly 55% more frequently in RAG search, though other RAG improvements were happening simultaneously, so this one is harder to isolate.

Your mileage will vary depending on your community model, your audience, and how much friction you can introduce without losing critical mass. There’s a balance to find, and it’s different for every organisation.

But the broader point stands. For twenty years, the default assumption has been that making it easier to participate makes a community better. That assumption is probably wrong, and it’s been wrong for longer than most of us have been willing to admit.

The communities that will matter most over the next five years won’t be the biggest ones. They’ll be the ones where the quality of what’s shared is high enough that both humans and AI systems treat it as a trusted source.

If you’re rethinking what your community should be optimising for, or you want to explore what adding friction could look like in practice, that’s exactly the kind of work we do at FeverBee.

The post It’s Time To Add Friction (And What Happened When We Did) first appeared on FeverBee - Community Consultancy.

Community Migration Projects Are Strategy Projects In Disguise

Richard Millington — Mon, 23 Mar 2026 08:37:28 +0000

The Problem With Community Migrations

We’ve worked on four community migration projects already this year.

In my experience, most organisations have the wrong mindset entirely when it comes to migrations.

Too often, the focus is on replicating what we have on more stable ground vs. building the experience needed for the future.

Or, to be blunt, too often organisations think:

How do we replicate what we have without the baggage of Khoros?

i.e., how do we have a platform that looks and functions exactly the same as what we have today, but without the broken analytics, inconsistent support, and lack of support for our customisations?

Stop doing this.

A Community Migration Is A Rare Trigger Moment

A platform migration (along with renewing your platform) is one of those rare triggers moments that come along every 2 to 3 years to reconsider if your past strategy is fit for the new era.

While organisations shouldn’t make decisions based on sunk costs, they often do.

It’s hard to recommend a drastic change in the community experience one year into a three-year contract – or immediately after a costly migration [with sympathies to the folks who moved from Khoros Classic to Aurora over the past few years].

But the time of renewal (or, better, 18 months before the renewal) is absolutely the time to plan what your strategy should look like for the next few years.

What Is a ‘Strategic Migration’ vs. a Typical Migration?

What’s the difference between a strategic migration and a platform swap?

The answer is simple: one focuses on replacing the experience you have today. The other focuses on developing the experience you want/need to offer for the future.

In a typical migration, you would typically do the following:

Gather the internal stakeholder requirements.
Undertake UX testing with members to ascertain their requirements.
Develop the capability gap analysis.
Put together a requirements specification.
Create a platform selection criteria and review platforms against the specification.
Select a platform and begin migrating the content across

But can you guess the biggest problem with all this? It’s designed for the present state, not the future state.

You’re essentially replicating the strategy of the past instead of using the migration as a golden opportunity to consider what kind of community experience you need to offer in the future.

I tackled this in my last post. Many of the assumptions and edifices upon which we built community in the past no longer apply.

Don’t Migrate A Community Without Updating Your Strategy

By strategy, I mean the three big strategic questions.

What type of strategy do you need?
What type of community are you developing?
What kind of community experience do you need to offer?

Each of these is informed by:

What are the audience needs (and the rate at which they’re evolving).
What are the organisation’s needs?
What’s happening in the broader technological landscape?

If you’re not doing this kind of analysis, it’s very unlikely that your platform migration will be as successful as you want it to be.

It might well be the case that nothing has changed, and you need to keep offering exactly the same experience as before.

But the odds are things have evolved, and if you want to take advantage of these changes rather than be buffeted by them, you need to evolve the experience you offer.

Case Study – How To Get The Migration Right

Last year, we worked with a client on their post-Khoros migration.

Instead of beginning with ‘how do we replace’ our current experience, we started with an (online) workshop to define the community’s future needs.

This involved us (FeverBee) gathering extensive data on audience usage patterns, how the audience(s) choose to use each platform, customer surveys, stakeholder needs, the technology landscape, and the long-term viability of each platform.

With that data, we worked up a set of options to collaborate on during the workshop. This included forcing decisions on things like:

Topic 1: Which audience(s) should we target?
Topic 2: At which phase of the customer lifecycle does the hosted community deliver irreplaceable value?
Topic 3: What are the critical use cases for the hosted community going forward?
Topic 4: What is the role of the hosted community vs. other channels members engaged on (Discord/Reddit/influencer channels).
Topic 5: What would it take to deliver a 10x better community experience?

Each of these sessions began with clear options to discuss (although there was room to refine/edit them – it just helps to have something to begin with!).

It’s these kinds of questions, backed by data, which will guide you not just to replicate an experience but to design a far better community experience for the future you’re entering.

As a result of these sessions, we were able to undertake a migration which:

Targeted a more narrowly focused audience than before and satisfied their needs entirely.
Focused on four specific use cases to solve for the audience.

Based on this alone, we have better copy, cleaner onboarding, and it’s easier to promote the community to the right people at the right time. But this also led to:

Cutting out almost all customisations. Finally deleting all outdated / non-visited content.
A much better search experience (faster content, less sludge to search through).

This is what a strategic migration looks like: it goes beyond simply replicating one experience into the next. Instead, it reviews the critical strategic questions against data and then works with a team to evaluate and prioritise the options.

These, in turn, translate directly into the community experience you need to offer.

Sometimes that might be a more expensive experience than before. However, I’m increasingly finding it’s a more targeted, narrower, efficient experience than before.

Aim For A Nimble, Sleeker, Easier To Manage Experience

Too often, migrations go badly because the organisation hoards too much information instead of being strategic and serious about what it will need in the future.

It’s a lot like moving house. You shouldn’t be moving all your possessions from one home to the next. That just stores up problems for later. Instead, think about which possessions you need as you enter each new phase of your life, and adjust accordingly.

The best migrations go far beyond exporting the data, mapping the categories, and trying to replicate the same structure. Instead, they try to cut the bloat, let go of the things holding them back, and design a better future for the path ahead.

Ultimately, don’t treat a migration as a replacement problem. Treat it like the strategy problem it is. And if you need us to guide you through this process, contact us.

The post Community Migration Projects Are Strategy Projects In Disguise first appeared on FeverBee - Community Consultancy.

Stop Hoarding Community Content: It Does More Harm Than you Think

Richard Millington — Fri, 20 Mar 2026 08:00:17 +0000

Just How Big Of An Axe Should You Take To Your Content?

It wasn’t that long ago when we used to collect as much data as possible from members in the hope that some of it would be useful.

We encouraged members to share real names, gender, phone numbers, email addresses, birthdays, photos, and more.

Then GDPR happened, and data suddenly shifted from a potential asset to a potential liability (or, as the saying goes, data went from the new oil to the new uranium).

Now almost all organisations have strict rules in place to ensure it’s handled with care.

Which means even small organisations like mine, FeverBee, are ISO 27001 certified to work with enterprise clients (and even then, we often still need to complete questionnaires with 100+ questions).

Content is now following a similar path.

What Is Content Hoarding And Why Do Organisations Do It?

Let’s expand the definition of content here to include everything that might appear in a community:

Questions & Answers
Blog posts
Ideas
Knowledge articles
Videos etc…

The largest communities have millions of items of content collected over a decade or more.

And many have done little to archive, merge, or remove any of it.

This is known as content hoarding.

It means conversations from 2008 about products that are no longer supported and that no one has visited in over a decade are still sitting side by side with the discussions created yesterday.

And like any other kind of hoarding, it’s kept around for two reasons:

The hope that one day it will be useful to someone.
A representation of success/ideals (look at all the content we’ve generated!)

This is perpetuated by a simple third belief that it doesn’t do any harm.

Unlike real-world hoarding, where the downsides (mess, reduced space, etc) are real and visible. Digital hoarding feels harmless.

Unfortunately, the hidden costs are higher than you imagine.

The Incredibly High Hidden Costs Of Digital Hoarding

There are three major problems with content hoarding.

1) It negatively impacts search traffic.

Search engines allocate a certain ‘crawl budget’ to each site.

This is the number of URLs the Google bot will visit in your community and consider for inclusion in its search index (from which it retrieves search results).

Any content that isn’t crawled won’t make it into the index and can’t be retrieved by search results.

The crawl budget isn’t allocated equally across all sites. It’s impacted by ‘crawl demand’ – essentially the popularity, freshness, and usefulness of the site itself.

The more high-quality content it sees (recent, popular, and uniquely useful), the more it will want to crawl the rest of the site.

However, if the Google bot encounters a lot of outdated, unanswered, or simply unpopular content, the crawl budget will shrink drastically (i.e., it won’t want to crawl the rest of the site). This is a big problem for hosted communities with discussions that are 5 to 20+ years old.

Many folks still think having lots of content = a greater chance of attracting search traffic due to the many possible long-tail terms. But today, the opposite is true. Taking the archiving axe to huge swathes of content is how you grow engagement and participation.

Aside – Last year, we helped one client archive 80% of their content and achieved a 32% uplift in search traffic (despite prevailing counter-forces).

2) It Distorts The Results Of LLMs And RAG Search

As I’ve frequently discussed of late, content hoarding is a direct path to confusing LLMs and internal AI tools (watch video).

Most enterprise organisations are currently racing to integrate community data into AI-powered support layers. These systems rely on retrieval-augmented generation (RAG) to fetch community content and synthesize answers for customers.

The fundamental problem is that RAG systems are often ‘timestamp blind.’ They don’t recognize when a 2016 solution has been superseded. They treat a legacy answer with dozens of upvotes with the same, or greater, authority as a modern, correct response from last month.

This means an accepted answer from a decade ago might be entirely wrong today, yet the AI serves this outdated information to your customers with absolute confidence. Often, nobody even realizes the damage is being done until the complaints start flooding in.

It gets worse. When multiple threads cover the same topic across different years, RAG systems often pull fragments from several sources. The result is a Frankenstein answer that blends advice from 2015, 2019, and 2024 into a single, internally contradictory response. The customer is left with no way to discern what is current and what is obsolete.

This is a problem that compounds over time.

The more ‘sludge’ you have, the higher the probability of retrieval error. And unlike search traffic, which can be measured, these bad RAG answers are largely invisible. You don’t get analytics on the erosion of trust occurring in your support channels.

We recently helped a client categorize over 100k threads using AI tagging. We discovered that the most-viewed content was almost exclusively beginner-level queries already covered in official documentation. The unique value of the community, the edge cases and experiential knowledge, was buried under a mountain of duplicated, unstructured noise that no RAG system could reliably parse.

Organisations that proactively clean and structure their community content now will gain a significant competitive advantage. Those that don’t risk seeing their communities excluded from knowledge indexes entirely because AI teams will deem the data too unreliable to use.

3) It Creates A Significantly Worse Experience For Members.

When members search for help, they don’t want a dozen possibilities; they want the single, most up-to-date answer. Or, at the very least, they want to know the answer doesn’t exist so they can ask the question themselves.

Hoarding content makes both of these outcomes unnecessarily difficult.

In our member interviews, landing on outdated discussions is consistently a top grievance. Members arrive via search, follow an ‘accepted solution,’ and discover it no longer works because the product or API has changed. Yet, there is no indication on the page that the information is of a different vintage.

This isn’t just a minor annoyance; it drastically reduces CSAT. It destroys the metrics that matter most: time-to-resolution and perceived quality. If a member wastes 15 minutes on a dead-end solution, they’re unlikely to use your community again.

There is also a decision paralysis effect. Faced with dozens of near-identical threads spread across years, most users won’t dig through the pile. They’ll either guess, and likely fail, or abandon the community entirely to open a costly support ticket instead.

With one client, we found that outdated information was a top-five problem in their satisfaction surveys. After we archived roughly 80% of the content (the same project that saw a 32% search traffic uplift), that issue vanished from the top ten. Members didn’t miss the old content; they were relieved it was gone.

Finally, consider the newcomer problem. Knowing there are 1.3 million articles sounds daunting, not inviting. A community with 10,000 well-maintained discussions says “we have answers.” A community with 1.3 million threads feels like it’ll be far more effort to find what you want.

The Community Knowledge Audit

Over the past year, we’ve helped several organisations tackle this problem. The approach has crystallised into something we’re calling the Community Knowledge Audit, a six-layer process for transforming messy community data into a trusted, AI-ready knowledge asset.

The core idea is simple: you don’t try to fix everything. You progressively filter, prioritise, and improve, so your effort goes where it actually matters.

Here’s how it works.

Layer 1: Archive The Fundamentals. Start with what can be removed with confidence before any manual review. This might include content in non-supported categories, threads with zero views in two years, discussions with no responses after two years, content tied to deprecated products, and anything already answered comprehensively in official documentation. For most large communities, this alone reduces the number of threads from 100k+ to around 50k.

Layer 2: Prioritise by internal value. Map what remains to what actually matters to the business. Filter by strategic priority, not page views. That means focusing on key products, support priorities, target customer segments, revenue-critical topics, and high-risk areas. This typically narrows the field to around 15k threads worth investing effort in.

Layer 3: Classify by knowledge type. Tag every remaining thread into one of five types: canonical, procedural, experiential, contextual, and ephemeral. The community’s unique value lives in the experiential and contextual discussions, the edge cases, and real-world advice that official docs can’t provide. Prioritise those. This focuses your effort on roughly 5k threads that represent the community’s genuinely irreplaceable knowledge.

Layer 4: Resolve duplicates, contradictions, and decay. Now you’re working with a manageable set. Merge duplicate threads. Resolve contradictory answers. Update decayed information. The goal is one clear, current answer per question. This is where quality improves dramatically.

Layer 5: Add authority and freshness signals. Give AI systems (and members) clear trust signals. Mark verified answers. Add version dates. Establish review cadences. Label content as current, outdated, or deprecated. This is what makes your community content reliably retrievable by RAG systems and internal AI tools.

Layer 6: Build the ongoing system. This isn’t a one-time cleanup. It becomes part of your revised community management process. That means scheduled audits and automated decay detection (Clean), daily thread optimisation and tagging on new posts (Run), and ownership per knowledge area with review cadences (Govern).

Most organisations can start seeing results within weeks, not months. The effort compounds. Even five discussions a day, properly targeted, add up to hundreds over a quarter – and thousands over a year or two.

The hardest part isn’t knowing what to do. It’s getting started when you’re staring at six figures worth of threads and no clear entry point.

If your team is stuck at that stage, that’s very much the kind of problem we help organisations solve. Drop me a message, and we can figure out where you are.

The post Stop Hoarding Community Content: It Does More Harm Than you Think first appeared on FeverBee - Community Consultancy.

Five Strategic Options For Enterprise Communities: Which Should You Pick?

Richard Millington — Fri, 06 Mar 2026 16:00:07 +0000

Why Is There So Much Conflicting Advice?

You might have read through a myriad of conflicting opinions to overcome these challenges.

Should you:

Double down on AI and focus on the community being part of the AI tools your organisation is developing?
Focus on building a sense of belonging that AI can’t compete with?
Optimise what you’re already doing and ignore the noise?
Embrace ‘Community Everywhere’ and engage across multiple platforms?

You can see the intuitive logic in each of them – but these lead you down very contrary paths.

The problem is that everyone is extrapolating conclusions from the narrow lens of their own personal experience.

It’s a little like the parable of the blind men and the elephant; it can seem like a tree, a wall, or a snake depending on the feature you touch.

Whether the future of the enterprise community rests in AI, belonging, third-party platforms, or something else entirely depends entirely on how the three major trends impact you today.

The Three Major Trends (and how they impact you)

Over the past few years, three major trends have emerged.

Changing preferences away from forum-centric experiences and towards a plethora of other platforms to satisfy our needs.
The sudden explosion of AI and internal pressure to utilise it.
The sharp decline in search traffic (as Google showcases AI-generated answers/snippets in search results vs. links).

Combine this with enterprise platform instability, rising privacy concerns, and an overall decline in the enterprise community sector, and it can feel your caught in a storm.

A good way of thinking about this is by examining the StackOverflow below:

Notice the two patterns here. There was that spell between 2014 and 2023 when engagement began to decline, and then the spell between 2023 and today when things collapsed.

StackOverflow is more impacted by these trends than most, but we all experience them in our own unique way.

So the first challenge is to answer a simple question: to what extent do each of these trends impact you?

Here’s a simple tool that might help:

Five Clear Options For Navigating The Future

Once we know the impact of the trends, we can evaluate the primary options.

Be mindful that these are only the primary options – not a comprehensive list of options.

These are as follows:

1. Strategic Exit

Save costs and/or eliminate liability by closing the community and focusing engagement on other channels.

Nobody wants to recommend this – because it feels like a failure. However, it’s always on the table and we should be clear why it shouldn’t be the choice.

If your engagement is flat or declining, your community isn’t generating unique knowledge that couldn’t exist elsewhere, and your audience has migrated to LinkedIn, Reddit, or Discord etc… – a strategic exit is the honest answer. You’re spending money to maintain a shrinking ghost town.

Close it, redirect the budget, and focus on channels where your audience actually is.

The missed opportunities and sunk costs are real, but they’re already lost. Keeping a dying community on life support just delays the reckoning while burning resources that could go somewhere useful.

Choose this if: Engagement is static or declining, the community fails to generate unique knowledge, and member preferences have clearly shifted to non-hosted platforms.

2. Optimisation Mode

Reduce costs and optimise current community experience, superuser programs, and escalation pathways.

The most common choice (for now) is to continue doing what you’re doing. You keep optimising the community experience, superuser programs, processes, and more.

This is a great choice if the community is stable/growing, answering a large volume of support questions, and it’s not significantly impacted by the trends reshaping other communities.

The risk here is that you might become a victim of trends you’re ignoring. But the bigger risk is making unnecessary changes to something that’s working just because change feels proactive.

Choose this if: Your community is new or still growing, it answers a large volume of questions, and external trends haven’t meaningfully disrupted it yet.

3. Power The AI

Focus community efforts on facilitating the exchange of experiential, contextual, or ephemeral knowledge to feed your organisation’s AI tools.

This is the option that matters most right now for large enterprise communities where engagement is declining.

It requires a shift from trying to get more people to engage to curating and soliciting unique knowledge.

In this case, you’re trying to solicit unique peer knowledge which isn’t covered in documentation, runbooks, or any existing resources; the workarounds, the edge cases, the “nobody documents this but everyone who’s been doing it for three years knows” knowledge. That’s what your AI tools need. That’s what your community, uniquely, can surface.

This is hard. It requires internal cooperation. It requires accepting that traditional engagement metrics may fall while knowledge quality rises. And yes, the AI hype bubble might burst. But if your organisation is building AI tools and struggling to justify community value, this is your argument.

Choose this if: Engagement is declining in a large, established community, your organisation is developing AI tools, and there’s rising pressure to demonstrate community value.

4. Build Belonging

Create a powerful sense of belonging by developing a unique, engaging, event-centric community experience.

This option returns communities to their roots. It focuses on using events and activities to build authentic, personal connections among members. It works especially well in private and/or exclusive communities.

The goal is to generate advocacy and increase loyalty (or repeat behaviors) by fostering connections among members. The challenge with this approach is that many people don’t want to belong to brands, and you have to accept a smaller, tighter community vs. the current engagement metrics.

If you have internal support for experimentation and a mandate beyond pure support metrics, this is the most rewarding strategic direction.

Choose this if: You’re required to maintain a hosted community experience, the community can legitimately support marketing objectives, and there’s internal appetite to try something genuinely different.

5. Activate The Ecosystem

Develop cross-platform programs to support ecosystem leaders and satisfy member needs wherever they are.

This is the most forward-looking option and, perhaps, the hardest to execute.

It recognises that preferences have changed and audiences now engage with a topic through a myriad of different channels for different reasons. It accepts that assuming you can bring everyone into a platform they’ve left is a fool’s errand and instead aims to add value in the places they have chosen to engage.

It shifts the focus to running cross-platform community programs over solely managing a community platform.

However, the measurement problem is real; you can’t easily attribute business outcomes to activity you don’t control. You’ll need cross-department collaboration that most organisations aren’t set up to provide. And your leadership team will probably ask why you’re investing in platforms you don’t own.

But the answer is simple; it’s where your members are, and meeting them there builds more resilience than trying to drag them back to a platform they’ve already left.

Choose this if: Activity is rising on independent platforms, you want to expand the community’s role beyond support goals, and member preferences are clearly pointing away from your hosted platform.

Make An Active Decision, Don’t Run On Autopilot

These approaches aren’t mutually exclusive or rigid, but more a means of thinking about the right path given the trends taking place right now.

The most important thing is not to continue on autopilot, pretending none of these trends hasn’t (and won’t) have any impact on how you build and develop community.

That’s a surefire path to demise.

A far better approach is to:

Evaluate the impact of each of these trends (using our simple tool here).
Consider the strategic approach recommended above (or create your own).
Develop a strategic plan that aligns with the recommended approach.

(We’re happy to help if you like – feel free to contact us)

The five options above aren’t equally available to every organisation. Your context, budget, and internal politics constrain your real choices. But you should make a conscious choice, not drift.

The big question right now isn’t how to improve the community, it’s which of the five options you’re choosing.

Good Luck!

The post Five Strategic Options For Enterprise Communities: Which Should You Pick? first appeared on FeverBee - Community Consultancy.

“I run a messy community 100k+ questions – how can I clean this up?”

Richard Millington — Mon, 16 Feb 2026 12:20:40 +0000

A variation of the ‘100k+ posts’ question has arisen about five times in the past four weeks.

I suspect it’s one that many organizations with large enterprise communities are struggling with.

It’s one we’re going to tackle in the ‘AI Ready Communities Program, ‘ but I’ll show you how we help clients tackle it here too.

(Aside: There are only 3 places and 2 weeks remaining to join our AI Ready Communities program. Once all places are taken, we won’t be enrolling any other organisation.)

The Worst Thing You Can Do Is Nothing

It’s best to present the ‘100k+ threads’ problem as a continuum with two ends.

At one extreme, you can do nothing. You simply leave them as they are and hope AI tools gradually learn how and when to utilise them.

At the other extreme, you manually check each and every thread to ensure it’s accurate and up to date.

I think we can both agree that neither is acceptable, so the answer lies somewhere between the two extremes.

The 101 Guide To Cleaning Up Community Data

The basic steps to clean up community data for LLMs (e.g., Claude, ChatGPT, Gemini) aren’t much different from those for internal AI tools.

You essentially need to dive into discussions and ensure:

The question title is clean and specific.
The question has an accepted, up-to-date answer.
The answer date is clearly labelled.
Long paragraphs are broken up into bullet points or paragraphs of 150 to 200 words.
The question is properly tagged and categorised.
Terminology used in the question and answer is aligned with the rest of the organisation.
The question is placed in a lifecycle queue, indicating whether and when it will be reviewed.

You can see a good example of this from the HP community here:

Now that we know what to do, we need to determine when to do it.

And this is where things become difficult.

“Just Focus On The Top 10% of Discussions!”

You hear this advice a lot, and it’s not bad. But it misses the key reason we’re doing this in the first place.

Many people currently identify the top 5%-20% of discussions by views and focus on optimising them using the principles above.

That’s better than doing nothing (and something you should already be doing), but it’s not the best thing you can do.

The problem with this advice is that the most-viewed questions in most communities are beginner-level, where the OP (original poster) didn’t want to invest the effort to find the information in official sources.

This means a better answer exists in official sources, and any self-respecting AI system will retrieve it from official sources when a user asks.

You can see a breakdown of question types and best source below:

So optimising these discussions isn’t a bad idea, but it’s not the best use of time either.

Remember, the unique value of a community lies in generating knowledge that isn’t available elsewhere.

That means edge cases, contextual discussions, and ephemeral discussions.

By definition, these won’t be the most viewed questions in your community. But they will be the ones who collectively offer the most unique value to your community.

Remember, the community’s new goal is to provide a comprehensive knowledge index to support every customer channel.

The Idea Approach: Extract, Tag, Prioritise

We’ll continue to target the top 5%-25% of discussions, but we won’t use views alone as the metric. We’re going to target the views + knowledge type.

This means we’re going to categorise our discussions by knowledge type and then update them.

In practice, this means the following:

Export questions to an Excel spreadsheet or a JSON file.
Use AI to tag questions into the five categories from here (canonical, procedural, experiential/edge cases, contextual, ephemeral). Ensure the knowledge types is tightly defined, and a confidence score is assigned.
Filter out those that are canonical, procedural, and ephemeral (what’s happening right now is less likely to be relevant in the future).
Rank the remaining discussions by the number of views in the past three months.
Update 5+ discussions per day (vs. setting an arbitrary fixed target).

Of course, 5+ discussions is an arbitrary metric that depends entirely on the resources you have available. In practice, it might be much higher or much lower than that. You can adjust.

The key thing is you create momentum, avoid vanity metrics, and scale with your team size.

You’ll notice none of this is a perfect system. It never will be. But it’s an excellent starting point for determining which items require human review and which don’t, based on the data provided.

(Also, note that we have a confidence level assigned to tags, which we can review as needed.)

This isn’t a one-time program you complete; it’s now part of your revised community management process.

Note: How to use AI to tag discussion types is covered in our AI Ready Communities Program.

Don’t Try to Be Perfect

The best advice I can give to anyone facing the 100k+ threads problem is stop trying to be perfect.

Doing anything will put you in a better place than you are today.

The great thing here is that effort compounds over time. Doing just a small number of posts each day, or even each week, will soon build up to a huge number of posts.

Better yet, you’re targeting the most important discussions first.

As you begin working your way down, the work is still important, but you’re getting the biggest bang for your effort buck just by getting started.

And if you want help, join our ‘AI Ready Communities’ Program.

Learn How To Overcome The Support Search Problem

Our AI Ready Communities program will teach you how to overcome the critical challenges preventing community from being included in your knowledge index.

In my opinion, this is the biggest single win for most community professionals today.

The program combines:

Live working sessions
Structured frameworks and templates
Guided analysis of your own community
Peer discussion and comparison
Direct input from FeverBee
Guest experts

What’s Included?

3 months of guided cohort sessions
12 personal guidance sessions
Access to FeverBee’s AI readiness frameworks and tools
Peer learning with a small group of comparable organisations
Direct feedback and facilitation from FeverBee
Applied work focused on your community

Investment: $4,000 per organisation (and you can enrol unlimited staff members)

The post “I run a messy community 100k+ questions – how can I clean this up?” first appeared on FeverBee - Community Consultancy.

Your Community Needs To Appear in Support Search Results

Richard Millington — Wed, 11 Feb 2026 14:46:48 +0000

Does Your Community Appear in Support Search Results?

TL:DR: Not appearing in support search is critically undermining the value of your community (especially in an AI world)

I’ve spent a lot of time this past week reviewing the support sites of plenty of organisations and seeing if and where community links appears.

The sad answer is, most of the time, they don’t.

This raises three key questions.

How should community appear in support search results?
Why doesn’t community appear in support search results?
How can we make community appear in support search results?

How Should Your Community Appear In Support Search?

You can find a good example of how a community should appear in communities like Zuora or Jama.

In both examples, when you type a question into the support bar (not just community support), it generates results from both community and non-community sources.

In this case, five sources are used, two of which (including the one deemed most relevant) are community.

This is where support communities need to be in the future. It’s the best of community combined with AI and the organisation’s knowledge base(s).

What’s frustrating is that most organisations aren’t anywhere close to this right now.

And it’s important to understand why.

Why Doesn’t Community Appear in Support Search?

To understand this, we need to understand how support search, especially RAG (retrieval augmented generation) search, works.

I’m not talking about the neural-network level or how model weights are trained. That’s far beyond my expertise.

I’m talking about the simple mechanics of how your organisation’s AI tools actually retrieve information and generate answers from company docs and, ideally, your community.

How Support Search Works (for most organisations)

Here’s the briefest possible explanation of how AI likely works in your organisation today.

In most organisations, a separate (often vendor-managed) knowledge index (database) is created.

This index ingests help centre articles, documentation, knowledge base content, and often support tickets (this is very similar to how search engines function).

Now, when a question is entered in a support search box, chatbot or any other channel, the system classifies the question type using simple rules and decides which sources to retrieve information from in the index (and how to prioritize each source).

This information is then passed to a large language model (GPT, Gemini, Claude, etc.) to generate a human-sounding answer.

This is simple enough – so why is community often excluded?

The Annoying Technical Problem With Including Community

There are two reasons. One is technical, the other is perceptual.

The technical problem is that these databases (from where the information is retrieved) aren’t typically designed to support discussion threads.

They’re designed for help centre articles, documentation, knowledge base content, and, often, support tickets. There typically isn’t a standard format to accept discussion threads.

This alone means many organisations don’t try to include community.

But even if they did, they face a new problem.

For community content to be ingested, it often has to be either:

Crawled like a web page.
Exported and reshaped into something that looks like a help centre article.
Stripped down into a question + answer format.

The problem is that converting a discussion thread into this format strips it of important data.

You lose metadata, which makes it harder to trust responses; you struggle to handle competing answers to a solution or multi-turn reasoning, which can lead to an answer.

The Perceptual Problem With Including Community

A more common challenge is many support staff don’t want community included in search results.

They think including community data is risky and might lead to their RAG search giving bad advice and incorrect information.

The problem with this is if they don’t include community you will certainly give people bad and incomplete advice.

Here’s a real world example, but in case you hate videos, here’s a theoretical example.

Imagine a customer asks:

→ “Why does SSO fail when using Okta with more than 50,000 users?”

[It doesn’t, but this is just an example!]

In your community, you might have a discussion post where:

One member shares a failed attempt.
Another shares a partial workaround.
A staff member explains an undocumented limitation.
Several others confirm the same issue in large environments.
Someone notes that the docs don’t mention this.

This thread contains experiential, contextual, and emerging knowledge.

But the AI system doesn’t see the thread because it’s not included in the retrieval database, so it might generate an answer like

→ “SSO failures with Okta are typically caused by configuration issues such as incorrect redirect URLs, certificate mismatches, or timeout settings. Please ensure that your Okta configuration matches the steps outlined in our SSO setup documentation. You may also want to verify token expiry settings and confirm that your integration follows the supported parameters. If the issue persists, contact support for further assistance”

The answer sounds right and plausible, but it’s completely wrong.

The issue wasn’t configuration; it was an undocumented scalability limit that only appears at very large user volumes. That’s experiential, edge-case, and contextual knowledge. The exact kind that exists in the community – but only when the context is included!

This leads to greater dissatisfaction with the brand as its own tool gives the wrong answer.

And yet, the answer is sitting right there in the community.

Now multiply this by hundreds and thousands of questions…you see the problem.

In short, when community isn’t included, everyone loses.

Learn How To Overcome The Support Search Problem

Our AI Ready Communities program will teach you how to overcome the critical challenges preventing community from being included in your knowledge index.

In my opinion, this is the biggest single win for most community professionals today.

The program combines:

Live working sessions
Structured frameworks and templates
Guided analysis of your own community
Peer discussion and comparison
Direct input from FeverBee
Guest experts

What’s Included?

3 months of guided cohort sessions
12 personal guidance sessions
Access to FeverBee’s AI readiness frameworks and tools
Peer learning with a small group of comparable organisations
Direct feedback and facilitation from FeverBee
Applied work focused on your community

Investment: $4,000 per organisation (and you can enrol unlimited staff members)

The post Your Community Needs To Appear in Support Search Results first appeared on FeverBee - Community Consultancy.

The Unique Value of Communities Is Changing

Richard Millington — Thu, 05 Feb 2026 18:43:04 +0000

Reminder: Sign Up For ‘AI Ready Communities’

You have just under a month to sign up for our AI Ready Communities Program.

This peer-group, cohort-based program helps your organisation maximise the value of AI within and from communities.

We have 6 places remaining. Click the button below to learn more and sign up.

“What is the point of a community now we’ve implemented AI?”

Over the next few weeks, I’ll outline some of the program’s critical principles to give you a sense of what we’ll cover.

(You can also check out my recent webinar: The Evolution of Enterprise Communities)

On a client stakeholder call recently, I was asked what the value of an enterprise community is when the organisation has launched a new customer support portal that uses RAG (retrieval-augmented generation) to pull data from a variety of official sources and generate a near-perfect answer most of the time.

It’s a great question – and one you will probably also get.

So here’s how to think about the answer (I’ll provide the exact answer at the end of the post).

The Unique Value of Enterprise Communities Has Narrowed (but not diminished)

Three years ago, I wrote that the main purpose of many enterprise communities had narrowed to answering the in-between questions.

These were questions that were too complex to be covered by an FAQ/documentation (an edge case) but didn’t require a member to share private details/personal data (and thus a support rep) to resolve the issue.

This was somewhat due to the introduction of Federated Search.

New tools like Coveo and SearchUnify could retrieve information from a wide variety of sources and display them in a single list.

Community answers weren’t going to rank above official docs (nor should they in many cases).

This didn’t mean communities didn’t still get a lot of questions whose answers were in the docs. They did (and still do – for the time being).

But it does mean it was getting fewer of them and wasn’t providing unique value in the answers.

The introduction of RAG (retrieval augmented generation – essentially creating a complete answer based on the information retrieved) further erodes the need for community to answer these kinds of questions.

Where federated search retrieved a prioritised list of relevant links, RAG creates the complete answer from this information.

A major factor in the decline in engagement in hosted communities is the rapid drop in members asking questions when the answer is already in the organisation’s documentation.

However, it’s worth noting, the community wasn’t providing unique value here anyway – so it’s not a big loss.

But it does change how we think about community value.

Communities Provide Fantastic Value….To Specific Questions!

Here’s the critical question going forward:

→ What is the value organisations can get from community that they can’t get through any other channel?

The answer isn’t generating as many responses as possible.

The answer depends more on the types of knowledge that only the community can answer.

You can see this in the graphic below.

It’s worth going through what each of these things is:

Canonical Knowledge

(what must be true)

This is simply the type of knowledge that must be true. AI must not contradict this kind of knowledge. It’s official information based on facts that shouldn’t vary.

This kind of knowledge should be surfaced in questions such as:

“Is this supported?”
“Does your product allow…?”
“What are the limits for…?”
“Is this compliant with…?”
“Which plan includes…?”
“When does this version go end-of-life?”
“What is your official policy on…?”

AI should rely almost entirely on documentation and policies here. The community should not generally feature in these kinds of answers.

The best use of community here is to flag when this knowledge isn’t accurate or clear, so it can be updated. But that’s usually better enabled by allowing feedback/ratings on the docs themselves.

Procedural/Operational Knowledge

(how things are done)

Procedural knowledge that explains how to do something correctly. This kind of knowledge shows up in response to questions like:

“How do I set up…?”
“What are the steps to configure…?”
“How do I troubleshoot…?”
“How do I migrate from X to Y?”
“What should I check when this fails?”
“How do I integrate with…?”

These questions require a step-by-step execution plan. AI should rely primarily on knowledge bases, runbooks, and support articles here.

Community can play a supporting role when official steps are incomplete, unclear, or lack edge-case details. But, again, enabling feedback on the docs themselves is usually a bigger win.

Experiential Knowledge

(what works in reality)

Now we get to the places where community can deliver far more unique value.

Experiential knowledge is knowledge derived from people who have actually tried the task. It reflects the point at which official guidance is insufficient, and more support is needed. Sometimes this might be a gap in documentation, other times it might simply be unique people trying to do unique things.

This kind of knowledge surfaces in questions like:

“This isn’t working even though I followed the docs”
“Has anyone got this working with…?”
“Does this behave differently when…?”
“What worked for you when…?”
“Is there a workaround for…?”
“Why does this fail only in large environments?”

AI should lean heavily on community answers here, because this is where practical workarounds, hidden constraints, and real-world behaviour are captured.

It’s not uncommon for customer support and success professionals to also rely on community solutions for these edge cases.

Contextual Knowledge

(why things fail or succeed)

This kind of knowledge is where a community really shines.

It’s where this isn’t a single correct answer, but people can understand the trade-offs, constraints, and different approaches to an issue. It’s the knowledge that explains the situation around a problem.

This kind of knowledge shows up in response to questions like:

“What’s the best approach for…?”
“Should I use X or Y?”
“What are the trade-offs between…?”
“Why does this design cause problems at scale?”
“How are others solving…?”
“What should I consider before…?”

These questions require judgment rather than instructions. You can’t write them down because it’s so contextual. There isn’t a single definitive answer – and AI can surface the multiple perspectives and ideas here.

Ephemeral Knowledge

(what’s changing right now)

Now we get to the point where community really outshines other channels in by some margin

Ephemeral knowledge is essentially what’s changing right now. It’s an early warning system. It captures what’s happening right now – even before the docs or the knowledge base has been updated.

This kind of knowledge shows up in response to questions like:

“Is anyone else seeing this issue today?”
“This worked last week – what changed?”
“Did the latest release break…?”
“Is there a known issue with…?”
“Why is this suddenly failing?”

These questions are time-sensitive and require a different approach than any other knowledge type.

Often, they can surface workarounds, solutions, or simply confirmation.

Treat Different Knowledge Types Differently

One principle we will cover in the AI Ready Communities Program is to treat different types of knowledge differently.

At the moment, we separate discussions largely by popularity. The most-viewed discussions receive extra care, but they are typically those that can be answered by existing documentation.

Once we view discussions from the perspective of knowledge completeness, we can begin labelling and improving their hygiene from a unique value perspective.

If you want to learn how to do this, join the program.

A Single Sentence To Explain Unique Community Value

Now reflecting on the original question, a good way of explaining the unique value of community is:

→ “Community is the only place where organisations can see how their product truly behaves in the wild. It exposes edge cases, reveals what actually works, and surfaces what’s changing before the rest of the business even knows.”

Adapt and change as you like – just focus on unique value!

The post The Unique Value of Communities Is Changing first appeared on FeverBee - Community Consultancy.