Best Of

You know that beautiful community moment when someone asks a question, another member swoops in with the perfect answer, everyone breathes a sigh of relief, and the whole thing feels wrapped up with a neat little bow?

Amazing. Beautiful. We love to see it.

But then what happens?

Too often, that helpful answer drifts quietly downstream, lost somewhere between a product question, a feedback thread, three announcements, and someone asking where the button went after the last UI update.

So let's talk about the answer after the answer. Because for community managers, an answered question is not just a closed loop. It is a clue. It tells you:

• Someone needed help.
• Someone else will probably need the same help later.
• A member, moderator, or staff expert shared something worth preserving.
• Your next FAQ, article, onboarding link, newsletter blurb, or support resource may have just written itself.

Make the answer easy to find

If a question has a clear answer, mark it as an Accepted Answer to make sure future readers can spot the resolution quickly. Nobody wants to dig through 17 replies like they’re decoding a secret message just to find “click Edit Profile.”

Add a “for anyone finding this later” note

Sometimes the correct answer is there, but it is wrapped in context that made perfect sense in the moment and slightly less sense six months later. A short follow-up can work wonders: “For anyone finding this later, the key takeaway is…”

That tiny bit of cleanup, with a blurb saying it was added by a mod/admin, can turn a good reply into reusable community knowledge.

Link the next breadcrumb

If there is a related KB article, discussion, webinar, guide, release note, or best-practice post, add it. Think of it like leaving a trail of Reese’s Pieces back to the answer, except hopefully with fewer aliens and less government involvement.

Watch for repeats

One question is a question. Two similar questions might be a coincidence. Three similar questions is your community standing outside your window with a boombox saying, “Please make this easier to find.”

Repeated questions are not failures. They are signals. They show you where members need clearer paths, better labels, stronger onboarding, or a more visible resource.

Thank the person who helped

If a member gave a great answer, say so. That recognition does not need to be dramatic. A simple “Great answer — thank you for helping here!” tells members their contributions matter.

And when people feel useful, they are more likely to come back and help again.

The big idea

Not every answered question needs to become a full article. Some questions are one-offs. Some are little gremlins that appear, get answered, and vanish back into the fog where they belong.

But the really useful answers? The ones that could save someone else 20 minutes, prevent a support ticket, or stop a mild keyboard-related meltdown? Those deserve a second life.

A healthy community is not just a place where questions get answered. It is a place where answers get easier to find the next time. So this week, pick one recently answered question and give it the “answer after the answer” treatment.

Mark it. Link it. Reuse it. Thank the person who made it useful.

Because sometimes your best community content is not something you need to create from scratch. Sometimes it is already sitting in your community, wearing a fake mustache and pretending to be just another reply.

If you manage an Ideas program, you probably know the pain: new ideas come in, someone has to search for duplicates, compare wording, review older requests, decide whether anything should be merged, and then somehow keep the whole library current.

That work gets even harder when your community team is doing most of the triage, but your product team does not have time to live in the community every day.

As both a Product Manager and a very enthusiastic advocate for community, I wanted to find a better way to bridge that gap.

So I built an AI-assisted Ideas workflow using:

• A ChatGPT Project
• A lightweight CSV export of our historical Ideas
• The Higher Logic Vanilla MCP
• A weekly duplicate-review workflow
• A monthly dataset refresh workflow
• Human review before anything is changed

The result is not an “AI automatically manages my Ideas portal” setup.

It is a much more useful middle ground: AI does the repetitive discovery and comparison work, while I stay in control of the product decisions.

The Problem I Was Trying to Solve

Our Success Community has a large historical Ideas library.

When a new idea is submitted, duplicate review can involve:

• Searching several versions of the same concept
• Reading old idea bodies
• Comparing scope differences
• Checking whether an older idea is completed, planned, declined, or still collecting insights
• Deciding which idea should be treated as the primary one
• Reviewing votes, comments, and product context

That is valuable work, but it is also time-consuming.

It is especially difficult for community managers who need product-team participation but cannot always get a Product Manager to review every new idea quickly.

My goal was to make that handoff easier.

Instead of asking a Product Manager to start from scratch, the workflow can present:

• The new idea
• The strongest historical matches
• Why they may be duplicates
• Important differences in scope
• The current status of each idea
• A recommended next action

That gives the Product Manager a focused decision instead of a research assignment.

Why I Used the Higher Logic Vanilla MCP

The Higher Logic Vanilla MCP is what makes the workflow useful rather than static.

The uploaded CSV gives the AI a historical comparison library, but the MCP gives it live community context.

I use the MCP to:

• Retrieve the newest Ideas
• Confirm the live version of a new Idea
• Validate strong historical matches
• Check current statuses
• Check current scores and comment counts
• Confirm tags and other context
• Avoid relying entirely on a stale export

The important design choice was not to ask the MCP to search the full historical Ideas library every time.

That would be slower, noisier, and more likely to produce inconsistent results.

Instead:

• The project files provide the historical memory.
• The MCP fills in the live gap.
• AI compares the two.
• I review the recommendation.

That division of responsibility made the workflow much more reliable.

Step 1: Create a Lightweight Historical Export

I started by exporting the historical Ideas library through the Higher Logic Vanilla API.

The API supports a fields parameter, so I did not need to export every available property.

The core structure was:

/api/v2/discussions.csv
?type=idea
&limit=500
&page=1
&sort=dateInserted
&fields=discussionID,name,body,categoryID,dateInserted,dateUpdated,countComments,score,url,statusID,tags

I selected only the fields needed for comparison and review:

• discussionID
• name
• body
• categoryID
• dateInserted
• dateUpdated
• countComments
• score
• url
• statusID
• tags

I intentionally excluded large or irrelevant fields such as:

• User profile objects
• Photos
• Last-commenter details
• Images
• View counts
• Bookmark state
• Unread state
• Other user-specific properties

The .csv version of the endpoint downloads the results directly as a CSV.

Because the endpoint is paginated, I exported multiple files and used a predictable naming convention:

ideas-baseline-page-001.csv
ideas-baseline-page-002.csv
ideas-baseline-page-003.csv

For a larger community, you would continue increasing the page number until the API returns no more records.

Step 2: Create a ChatGPT Project

I created a dedicated ChatGPT Project and uploaded the CSV files.

I also added a longer Markdown workflow guide and a much shorter project-instructions file.

The shorter file tells the project to read the full workflow before doing any work.

At a high level, the project instructions say:

• Treat Vanilla as the live source of truth.
• Treat the CSV files as the historical comparison library.
• Use discussionID as the unique key.
• Use dateInserted, not recent comment activity, to identify new Ideas.
• Do not search the entire historical Ideas library through MCP on every run.
• Compare only genuinely new Ideas against the uploaded files.
• Validate only strong candidate matches through MCP.
• Never merge, close, edit, or change an Idea automatically.
• Require human review.

This kept the project instructions small while preserving the full logic in a reusable reference file.

Step 3: Use a Weekly MCP Check

The weekly workflow uses the Higher Logic Vanilla MCP to retrieve the newest Ideas from the relevant category.

It sorts by newest dateInserted, then compares the returned discussionID values against the IDs already stored in the project files.

That creates two buckets:

• Already saved
• Genuinely new

Only the genuinely new Ideas are analyzed.

For each new Idea, the workflow:

1. Retrieves the full live discussion through MCP.
2. Cleans the HTML for analysis.
3. Identifies the underlying problem.
4. Identifies the requested outcome.
5. Identifies the product area and workflow.
6. Searches the uploaded CSV files for likely historical matches.
7. Creates a shortlist of no more than five candidates.
8. Validates only the strongest candidates through MCP.
9. Recommends an admin action.

The possible outcomes are:

• Likely duplicate
• Possibly related
• Similar area, different request
• No strong match

The possible admin recommendations are:

• Review for merge
• Keep separate but relate
• No duplicate action
• Needs product review

If there are no meaningful matches, the weekly workflow stays silent.

If there are possible duplicates, it asks me to review them before anything happens.

The Weekly Prompt Pattern

At a high level, the weekly prompt says:

Use the Higher Logic Vanilla MCP to retrieve newly created Ideas.

Use dateInserted, not dateLastComment.

Compare the returned discussionIDs against the uploaded historical CSV files.

Only analyze Ideas missing from the saved dataset.

For each new Idea:
- retrieve the live discussion
- identify the underlying problem and requested outcome
- shortlist historical candidates from the CSV files
- validate only strong candidates through MCP
- classify the relationship
- recommend an admin action

Do not merge, edit, close, comment on, or change the status of any Idea.

If there are no likely duplicates or meaningful ambiguous matches, do not notify me.

If there are possible duplicates, ask me to review them.

Step 4: Refresh the Historical Dataset Monthly

The weekly MCP run handles the gap between exports, but the historical data can still become stale.

Older Ideas may receive:

• Status changes
• Title edits
• Body edits
• New tags
• More votes
• More comments

So I also created a monthly workflow.

The monthly workflow does not download the file automatically.

Instead, it:

• Reads the latest stored checkpoint
• Generates the exact encoded CSV API URL
• Suggests a filename
• Prompts me to download the file
• Reminds me to rename it
• Reminds me to upload it to the project

A suggested filename pattern is:

ideas-incremental-2026-08-01-page-001.csv

The monthly API request can use an inclusive RFC3339 date filter such as:

dateInserted>=2026-07-15T18:22:20+00:00

The encoded query value would look like:

dateInserted=%3E%3D2026-07-15T18%3A22%3A20%2B00%3A00

The workflow uses an inclusive checkpoint and deduplicates by discussionID.

That small overlap is intentional. It reduces the risk of missing records that share a timestamp or were caught in a partial run.

Why I Did Not Let AI Merge Anything Automatically

This was an important line for me.

Two Ideas can sound similar while still representing different:

• User types
• Product surfaces
• Workflows
• Permissions
• Reporting needs
• API needs
• Scope boundaries

AI is very good at finding candidates.

It is not the Product Manager.

The workflow helps me make a decision. It does not make the decision for me.

That also makes it easier for community managers to involve product teams.

Instead of sending:

Can you please review the Ideas category?

They can send:

These two new Ideas may overlap with these three existing requests. Here is the comparison, the scope difference, and the recommended action.

That is a much easier request for a busy Product Manager to act on.

Other Ways This Project Could Be Used

Duplicate detection is only one possible workflow.

The same project structure could also help with:

• Identifying older Ideas that may have been delivered but never updated
• Comparing completed work against release notes
• Finding Ideas that should move to a new status
• Grouping related requests into broader product themes
• Identifying high-interest Ideas with no recent product response
• Creating product-area digests for different Product Managers
• Finding Ideas that are similar but should remain separate
• Preparing a backlog review before roadmap planning
• Identifying Ideas that need a clearer staff response

One flow I am especially interested in next is using release notes to identify Ideas that may now be completed or partially addressed.

There are some interesting questions there:

• Was the entire request delivered, or only part of it?
• Should the Idea be marked completed or linked to a related release?
• Does the release solve the original problem in a different way?
• Should the original author receive an update?

If people are interested, I may share that part of the workflow in a future post.

What I Learned

A few things made this work much better:

Give AI a stable historical dataset

Do not make the agent rediscover thousands of old Ideas every week.

Use the MCP for live context

The MCP is excellent for filling in the newest records and validating the strongest matches.

Keep the data export focused

More data is not always better. Export only what the workflow actually needs.

Use a stable unique key

For this workflow, discussionID is essential.

Sort by creation date

Recent comments should not move historical records into the “new Ideas” window.

Keep humans in control

AI should surface decisions, not quietly make product-governance decisions.

Document the workflow while building it

I kept the instructions, data choices, date logic, tests, and known limitations in the project itself.

That makes the setup easier to improve and easier to explain later.

Final Thoughts

I built this for our own Success Community because I care deeply about Ideas programs, product feedback, and making community participation easier for product teams.

It also turned into one of my favorite practical examples of the Higher Logic Vanilla MCP.

The MCP is not replacing the historical dataset, the Product Manager, or the community manager.

It is connecting them.

The community manager gets a more manageable workflow.

The Product Manager gets a focused review instead of a pile of research.

The historical Ideas library becomes more useful.

And the final decision still stays with a human.

That is exactly the kind of AI workflow I want more of.

Questions? Want More?

Have questions about how I set this up? Let me know in the comments! I’m happy to share more specific prompts, project instruction examples, or additional AI and MCP workflows like this in future posts. 😊