We design the structure of your internal knowledge base — what areas exist, what lives where, who owns each area, what gets archived, and how it stays usable. We work with the tools your team already uses. This is operational design work, not enterprise knowledge management, intranet implementation, or a Notion template.
Common pain points
Your knowledge base grew organically — every team added its own structure and now nothing matches.
Nobody can answer "where does this kind of doc live?" without checking three places first.
The same topic has three different pages written by three different people, and nobody knows which is current.
Old docs nobody trusts still show up in search — there's no archive discipline.
When someone leaves, their pages stay in the base but nobody knows whether to keep, update, or archive them.
Your team adopted a Notion template six months ago, but it didn't match how the team actually works and got abandoned.
Internal knowledge base design is the operational work that decides what areas your base has, what lives where, who owns each area, what gets archived, and how new content gets placed without breaking the structure. We design the structure with the people who use the base daily, name the areas in language your team already uses, assign a clear owner per area, and set the rules for what gets archived and when. We work with the tools your team already has (Notion, Confluence, Google Docs, whatever fits). This is not enterprise knowledge management. We do not deploy KM platforms, build intranets, or hand you a Notion template and call it design.
What we deliver
Area 1
We start by listing what your team actually knows — by area, not by tool. The output is a one-page map of the areas your base needs (e.g. customer onboarding, billing, internal tools, hiring, post-mortems) named in the language your team already uses. We write this with the people who own each area, not in isolation.
Area 2
We write simple naming and placement rules so people know where a new doc should go and what to call it. No complex taxonomy project, no controlled vocabulary exercise. The rules cover area, doc type, owner, and review date — enough structure that the base stays consistent without needing a librarian.
Area 3
Every area in the map has one named owner who can edit, deprecate, and approve new docs in that area. Ownership is distributed across the people who use the area daily — not a central KM team. Output: an ownership sheet with people, not job titles, and a rule for what happens when an owner leaves or changes role.
Area 4
We define which docs get archived, when, and by whom. Old docs stop showing up in search; deprecated docs get a clear "do not use" header; abandoned docs get a deadline. The policy is short enough that the area owner can apply it in five minutes — no archive committee, no records management project.
Area 5
We write a short "where to find what" page so the next person who joins your team can navigate the base on day one. This is the entry point: it points at the areas, names the owners, and tells the new hire what to read first. Output: one page your team links from your onboarding doc.
Area 6
When someone leaves or changes role, the areas they owned do not disappear. We design lightweight handover hooks — what gets transferred, who picks up ownership, what gets archived if nobody picks it up. This is the structure side; the deeper handover discipline for AI workflow operations is a separate workstream if you need it. Output: a handover checklist your team uses on every role change.
Your team finds the right area without checking three places first.
New docs land in the right place because the placement rules are short and clear.
Old and contradictory docs stop polluting search because the archive policy actually runs.
Every area has a named owner who can update, archive, or hand off — instead of "I think someone owns this".
New hires find their way around the base on day one because the entry-point page tells them where to start.
Your base stays usable in a year because the structure was designed by the people who use it daily.
No. Enterprise KM consulting designs information architecture for 10,000+ employee organisations, deploys CMS platforms, and runs records management programs. This work is operational design for 10–500 person teams: area map, naming rules, named owners, archive policy. We help your team design a base they can actually maintain.
No. Templates are a starting point that rarely matches how your team actually works — your team adopts the template, finds it doesn't fit, and abandons it. We design the structure with your team in whatever tool you already use (Notion, Confluence, Google Docs). The design is yours, not a copy of someone else's template.
No. We don't build intranets, deploy enterprise KM platforms, or migrate content between platforms. We design the structure that should exist in the tool your team already has, with the people who use it daily.
A one-page area map written with your team. A short page of naming and placement rules. An ownership sheet with named people per area. A short archive policy. A "where to find what" entry-point page for new hires. A handover checklist for role changes. No 60-page binder, no platform purchase.
No. For most 10–500 person teams, a well-designed structure inside Notion, Confluence, or Google Docs is enough. If you're considering a tool change for unrelated reasons, the design we deliver carries over — the structure is independent of the tool.
Enterprise KM consulting, intranet implementation, CMS platform deployment, content migration, records management compliance, regulated retention policies, cybersecurity of knowledge systems, or platform selection consulting. We do one thing: practical internal knowledge base design for B2B teams of 10–500 people.
We help your B2B team organise the knowledge you already have, make it findable, assign clear owners, and keep it updated — using the tools your team already…
Read moreRouting logic, not a search platformWe design the routing logic your team uses to find what it already knows: where to look first, when to use AI-assisted search inside existing tools, and when…
Read moreBook a call to scope your internal knowledge base design work. We'll talk through what areas your team needs, what's currently in your base, who owns what, and what would need to change to make it usable. If what you actually need is a Notion template, a KM platform, or an intranet build, we'll tell you and point you to the right specialist.
Book a call