Do you have Best Practices for Structuring Knowledge Bases at Scale in Large, Complex Organizations

[ramonaheitk]

Hi everyone,

I'm looking for best practices on structuring Knowledge Bases in ServiceNow in a very large and complex enterprise environment.

Context:

• We use ServiceNow as our central IT4IT platform
• We want to harmonize multiple existing knowledge sources into ServiceNow
• Knowledge consumers range from End Users (Self Service) to Service Desk, Operations Centers, and 2nd/3rd Level Support

Challenge:
We are currently struggling with the right number and structure of Knowledge Bases.

On the one hand, we want clear ownership and transparency for service owners (e.g.
Which knowledge exists for my service? How is it used? What is missing?).

On the other hand, we are operating at very large scale (10,000+ applications/services), making a “one KB per service/application” approach unrealistic.

Key questions:

• How do you structure Knowledge Bases at scale (by role, usage, service, or a mix)?
• How do you enable service ownership and transparency without creating thousands of KBs?
• Which principles or patterns have proven successful in large enterprises using ServiceNow Knowledge?

Any insights or lessons learned would be highly appreciated.

[Mark Manders]

Make sure you have the correct user criteria and put some real effort in the design.  And within your Knowledge Bases, use the correct categories. That will help a lot. Remember that you can put categories in categories! The question we can't answer is what knowledge you put in there. If you don't want an article per application/service, what is it that you are going to document? You can make a group of service owners that is (combined) responsible for the articles, but if I own several communication services and I get notifications on payroll applications, I will be annoyed. 

And be aware that you can link articles to config items. That can help in filtering for the owners (kb_knowledge.cmdb_ci.owner is dynamic me)

[MaryG]

Great question and a challenge I've worked through across several large enterprise engagements. Here's what has actually worked at scale.

**The core principle: KBs by audience, not by service**

At 10,000+ applications, a service-per-KB model is unmanageable. The proven pattern is a small number of KBs structured by consumer audience and access pattern:

- Employee Self-Service KB — public-facing, plain language, deflection-focused
- Agent/Service Desk KB — L1 resolution content, structured for speed
- Specialized/Domain KB(s) — L2/L3, operations, technical runbooks (one per major domain, not per service)

Three to five KBs total covers most large enterprises. User Criteria handles access, not KB proliferation.

**Service ownership without thousands of KBs**

This is the real design challenge. The answer is taxonomy and metadata, not KB structure:

- Build a shared Category/Subcategory taxonomy aligned to your service tower or CMDB CI Class hierarchy — not individual applications
- Use the kb_knowledge.cmdb_ci field (as Mark noted) to associate articles to specific CIs — this is your service-level linkage
- Add a mandatory Ownership Group field (map to your service owner groups) so ownership is at the article level, not the KB level
- Service owners then filter their view using PA dashboards or a saved list filter on kb_knowledge where cmdb_ci.owned_by = me (or ownership_group = my group)

This gives each service owner visibility into their articles across the platform without requiring their own KB.

**Taxonomy design at scale**

With 10,000+ services, your category structure needs to be tier-based, not flat:
- Tier 1: Major service domains (Infrastructure, End User Computing, Business Applications, Security, etc.) — 8 to 12 max
- Tier 2: Service families within each domain
- Tier 3 (optional): Specific services or CI classes

Avoid letting Tier 3 grow unbounded. If a category has fewer than 5 articles, it probably shouldn't exist yet.

**AI Search and Now Assist readiness**

At this scale, content quality across a unified taxonomy matters more than KB structure for search and AI performance. Standardized titles, mandatory short descriptions, and consistent metadata (especially Business Service and CI linkage) are what make AI Search return useful results across 10,000+ service contexts. KB structure alone won't solve findability.

**What I'd avoid**

- KB per business unit or department — ownership fights and taxonomy fragmentation
- KB per application — unmanageable at your scale
- Relying on KB structure alone to enforce ownership — metadata and governance processes do that job better