Overview
Marketing, sales and subject-matter experts were all working with different fragments of the same organisational knowledge.
Rather than attempting an immediate platform replacement, we defined a shared knowledge model and authority layer showing what information existed, where truth lived and how it should be reused.
Who This Is For
Organisations where important commercial knowledge is distributed across:
- CMS
- CRM
- SharePoint or document storage
- Product systems
- Proposal libraries
- Presentations
- Support material
- Individual employees
The Situation
The organisation did not necessarily need "one system".
It needed one coherent way of understanding its knowledge.
Without that, search returned too much, AI retrieved conflicting material, sales recreated assets and marketing could not confidently reuse technical information.
Where the Workflow Breaks
CMS truth ≠ CRM truth ≠ document truth ≠ expert truth.
Every new output requires manual reconciliation.
Our Approach
Inventory knowledge domains
Identify the important entities and information types.
Assign authority
For each field or knowledge class, define:
- Source system
- Owner
- Confidence
- Review cycle
- Permitted reuse
Define shared relationships
Connect:
- Customers and problems
- Products and services
- Industries
- Evidence
- Expertise
- Questions
- Assets
- Opportunities
Keep systems in their proper roles
Do not force every piece of information into a new monolith. Create interoperability through IDs, metadata, APIs, search and retrieval patterns where appropriate.
Design retrieval around use cases
Different users need different views of the same knowledge.
Before → After
Where AI Helps
AI becomes the retrieval and transformation layer over governed knowledge rather than an alternative source of truth.
What Changes
- Better findability
- Less duplication
- Clearer authority
- Stronger cross-team reuse
- Safer AI retrieval
- Reduced pressure for unnecessary platform consolidation
These are the operational changes the work aims for. Any measures are agreed against your own baseline during scoping.
What This Demonstrates
A shared knowledge layer is a logical architecture, not necessarily another giant repository.
Relevant experience
Named projects that show parts of this approach in practice. They evidence the underlying experience; none of them is the scenario above, and each case study says how it was delivered.
- Content Strategy & Information Architecture for a Global Paints & Coatings Manufacturer's New Intranet
Information architecture and editorial operations replacing a fragmented intranet across a complex matrix organisation.
- Intranet Redesign for a National Parliament
Search, navigation and personalisation redesign for a large internal knowledge estate.
- Product-Finding Tools for a Global Paints & Coatings Manufacturer's B2B Website
Structured product data from several systems brought into one model for finding and reuse.
- Intranet Migration & Information Architecture for a Maritime Services Group
Content migration and information architecture for a move to a new Office 365 ecosystem.
At a glance
Client type
Capabilities
- Knowledge architecture
- Taxonomy
- Governance
- Retrieval
- CMS, CRM and document integration
Most relevant to
All solutionsRelated patterns
Making Product Knowledge Machine-Readable
Export-oriented industrial manufacturer
Product truth was distributed across systems, documents and experts. We connected specifications, applications, buyer problems and evidence into a reusable knowledge model that could support web, sales, localisation and AI retrieval.
Building an AI-Ready Content Operating Model
Mid-market or PE-backed B2B organisation
The organisation wanted more AI. The real blockers were unclear ownership, inconsistent sources and undocumented workflows. We made the process explicit first, then identified where AI could safely remove work or improve decisions.
Recognise this problem?
We can start by mapping the workflow, finding the bottleneck and defining a contained first improvement.
Discuss a first project