How do you structure Knowledge Base categories when tools span multiple products? | Community
Skip to main content
Answered

How do you structure Knowledge Base categories when tools span multiple products?

  • October 27, 2025
  • 3 replies
  • 123 views

Forum|alt.badge.img

Hey everyone 👋
 

We’ve been reworking our Knowledge Base structure as our platform has expanded, and I’d love to hear how others have approached this.
 

We’ve recently rolled out several new core products, so it made sense to create a category (mini hub) for each one.

However, we also have tools that span all products - for example, an email tool that’s used across multiple product types.
 

My current idea is to move these shared tools into a separate category like “Platform Tools and Features.”
 

The tricky part is that while the email tool touches most of the products, its functionality has small nuances depending on the product.
 

I’m torn between:

  • Keeping all email content centralised in one place nested under a tools section e.g. having an email section (simpler to maintain, easier to find)
    vs.

  • Referencing it within each product section for context (but risking duplication and confusion - for example, users searching for email help might find multiple references across different categories).

How have you managed this balance in your own Help Center?

  • Do you centralise shared tools or duplicate content for context?

  • What’s worked best for keeping navigation intuitive for users while maintaining structure behind the scenes?

Would love to hear what’s worked well (and what hasn’t) for other teams managing multi-product Knowledge Bases!

Best answer by Paul Byrne

Hi ​@Harry Gardner Paul here from support engineering to help you out 🤝 

I like the thought and prep that went into this.

You want one source of truth for shared tools, plus the context customers need when that tool behaves slightly differently per product. The best-practice pattern I see is hub-and-spoke: keep a canonical, central article for the email tool, then surface short product-specific context pages or snippets that link back to the canonical page and call out product differences. That keeps maintenance low, search results tight, and the product context obvious to users.

 

3 replies

Paul Byrne
Intercom Team
Forum|alt.badge.img+7
  • Intercom Team
  • Answer
  • October 30, 2025

Hi ​@Harry Gardner Paul here from support engineering to help you out 🤝 

I like the thought and prep that went into this.

You want one source of truth for shared tools, plus the context customers need when that tool behaves slightly differently per product. The best-practice pattern I see is hub-and-spoke: keep a canonical, central article for the email tool, then surface short product-specific context pages or snippets that link back to the canonical page and call out product differences. That keeps maintenance low, search results tight, and the product context obvious to users.

 


Forum|alt.badge.img
  • Author
  • New Participant
  • October 31, 2025

Thank you ​@Paul Byrne , this is really helpful. 


Paul Byrne
Intercom Team
Forum|alt.badge.img+7
  • Intercom Team
  • November 1, 2025

@Harry Gardner Delighted to hear that :) Enjoy your weekend.