Most organisations already store far more than they can find. Knowledge management is the discipline of deciding what is worth keeping, who decides that, and how it reaches the next person who needs it. We do that work in the Microsoft 365 you already pay for, and we build only where SharePoint genuinely cannot do it.
Microsoft 365 specialists since 2005. The practice is led by someone who ran knowledge management in-house before founding the firm.
What it is
Microsoft 365 knowledge management is the practice of capturing what an organisation knows, deciding which of it is good enough to reuse, and making it findable to the next person who needs it. It covers expertise location, capture at the end of a project or matter, model documents, and the review and curation model that keeps the whole thing trustworthy.
How long
Four to eight weeks for strategy and design, depending on how many knowledge domains are in scope. Build timescales depend on how much of the requirement SharePoint already meets.
What you get
A knowledge management strategy with a named owner for each knowledge domain, a curation and review model, and a specification for what gets configured natively versus what needs building.
Who does it
Knowledge management consultants who have delivered this for professional services and pharmaceutical clients, working with the same user experience team that scopes the structural work.
None of these are storage problems. Every one of them is a decision that was never made about who owns knowledge and what is good enough to reuse.
Everything produced gets saved, so nothing produced gets found. What we see most often is a document estate with no distinction between a first draft, a client-specific deliverable and the one version that has been checked and is safe to reuse. Without that distinction, searching returns everything and answers nothing.
Someone has done this before, in a different office, for a different client. There is no way to find them except asking around, which only works if you already know who to ask. New joiners and lateral hires have no route in at all.
Knowledge capture is scheduled for the end of a project or matter, which is exactly when the team has moved on to the next one. If contributing is voluntary and unrewarded, it does not happen, and no amount of platform will change that.
The work exists but it is full of client names, commercial terms and confidential detail. Without a redaction step and someone accountable for it, reuse is a risk nobody is willing to take, so people start again instead.
A knowledge library was built, populated once, and never reviewed. People try it, find something from four years ago, and stop trying. Trust is quick to lose and slow to rebuild.
Knowledge management sits between IT, operations and the business, which in practice means it sits nowhere. Without a named owner per knowledge domain, quality drifts and the initiative quietly stops.
Six disciplines. An organisation needs all six eventually – what varies is how many you already have covered and how many you want us to do.
Knowledge management rarely arrives on its own. It settles what is worth keeping, who owns it and what standard it has to meet – and it leans on somebody having already worked out where things live and how people get to them. That structural layer is a discipline in its own right, with its own consultants and its own research, and we run it as a separate piece of work priced separately, so you can see what each half is costing rather than being handed one number.
It is also worth separating from records management, which is frequently sold alongside it and occasionally as the same thing. Records management is about retention – what has to be kept, for how long, and how it is disposed of when the period ends. Knowledge management is about reuse. The two share infrastructure and almost none of their purpose, and a programme scoped as one while the business expected the other is a common and expensive way to lose eighteen months.
A rule of thumb worth applying before you brief anybody. If your people cannot find things at all, the bottleneck is structural and that is where to start. If they find far too much and trust none of it, the bottleneck is curation, and that is this page. Most firms need both eventually, and knowing which order to take them in is a good part of the value of asking.
For internal knowledge, usually not. Most organisations already on Microsoft 365 own more knowledge management capability than they are using, and the gap is almost always design rather than software. Dedicated knowledge management software earns its licence in a narrow set of cases, and it is worth being sceptical of anyone answering this question who happens to sell it. Four scenarios, in the order they actually occur.
More than most buyers realise. Document libraries with managed metadata, content approval workflow, version history, retention and expiry rules, permissions down to item level, and search that respects all of it. A curated knowledge library with a review cycle, a collection surfaced through the intranet, a model document library with controlled publishing – all of that is configuration rather than development. If someone has quoted you for a product to do this, a fair question is what their product does that SharePoint does not.
This is where most requirements land, and where most of the value is. The platform is perfectly capable but the decisions were never taken – what qualifies as reusable, who reviews it, how capture fits into the way people already close work, who owns each knowledge domain, when something gets retired. Buying software at this point does not fix it. It reproduces the same undecided problem in a new interface, with a licence attached. This tier is consultancy and configuration: no new licence, no code.
It happens, and we will say so when it does. The honest cases are an external or customer-facing knowledge base where the audience sits outside your tenant, very high-volume service desk knowledge with workflow and deflection requirements that a support platform is purpose-built for, and organisations whose knowledge genuinely lives across many non-Microsoft systems that are not going anywhere. In those situations a specialist product may well be the cheaper answer over five years.
Sometimes the requirement is specific to how your firm works and no product covers it either. Browsing a knowledge collection in a way SharePoint does not support natively, a submission and redaction workflow carrying logic particular to how you handle client confidentiality, recommendation behaviour tuned to your own knowledge domains. We build these as SharePoint Framework components inside your own tenant, and where the requirement is a process rather than an interface, Power Platform is usually the cheaper route.
Two things we will always tell you before you commit to anything custom. It has to be maintained as the platform moves underneath it, and we will be explicit about what that commitment looks like before you sign anything. And some gaps are worth simply waiting out, because Microsoft is actively closing them – we will tell you which ones we think those are.
Then this work is the prerequisite rather than an alternative to it. Copilot draws its answers from the same content everything else does, so consistent metadata, a document set somebody has vetted and clear rules about what is in scope are what determine whether it returns anything useful. Organisations that do the knowledge work first get noticeably more out of an AI rollout than those that switch it on and hope. The detail of that sits on our Microsoft AI and Copilot page.
Common in law firms and regulated organisations, and usually for reasons that have nothing to do with scepticism about the technology – outside counsel guidelines restricting what can be processed, client confidentiality obligations, or a partnership that simply has not reached a position yet. Every argument on this page holds without it. Reuse, faster onboarding, less duplicated work and expertise that survives people leaving are the return on knowledge management, and none of them depends on an AI licence. Nothing we design will assume one is coming.
These are the firms where knowledge is the product, and where reuse is measurable against billable time.
Precedent and know-how libraries, model documents and clause banks, matter knowledge captured at close, and expertise location across practice areas and offices. The recurring problems are that maintaining precedents falls to knowledge lawyers who are not billable, and that reuse across matters needs a redaction position somebody senior has signed off. Both are design problems before they are platform problems.
Methodology libraries, proposal and bid content, project and case knowledge, and finding the partner who has done this sector before. Reuse is the direct route to margin here, which makes the business case easier to write and the curation standard harder to agree.
Where knowledge has to be traceable as well as findable, and where retention and approval are not optional. The curation model has to satisfy compliance without becoming so heavy that people work around it.
A knowledge management strategy is worthless as a conversation. It has to exist as something a named owner can apply in eighteen months when the consultants have gone.
Every category of knowledge in scope, with a named owner, a review frequency and a retirement rule against each one
Who checks, who approves, who redacts, and what the accountability is when something goes out wrong
Written definitions of what qualifies as reusable, what does not, and who holds the deciding vote when it is arguable
What gets configured natively, what needs building, and what we recommend you wait for Microsoft to close
Where in your existing process capture is triggered, what gets captured, and what deliberately does not
The reuse and time-to-answer figures agreed before the work starts, because most of them cannot be reconstructed afterwards
What drives the cost is the number of knowledge domains in scope and whether anybody has ever audited what you hold. A single practice area with a willing owner is materially smaller work than a firm-wide programme across offices that have never agreed a standard between them.
A single knowledge area with a sponsor already in place and a clear reuse problem - a precedent library, a bid content library, one practice group's know-how. Audit, curation standard, capture design and a build specification. Often run deliberately as a pilot, so the standard can be argued out once at small scale before it is applied across the firm.
A department, practice group or region with several categories of knowledge and competing views on what good looks like. Adds stakeholder research across the contributing groups, a domain register with owners negotiated rather than assigned, and the governance structure that holds it together once we leave.
Multiple functions or offices, existing systems to rationalise, and usually a previous attempt that did not hold. Adds an audit of what already exists and why it stalled, a sequencing plan so the whole thing does not launch at once, and the business case for whoever signs it off. Build timescales sit on top and depend on how much falls outside native SharePoint.
We work two ways on knowledge management, and we are equally happy with either. We design it and build it, or we design it and your team builds from the specification. The strategy is written the same way regardless – as a deliverable you own outright rather than a commitment to us – which is also how we run discovery. Four routes it usually leads to.
1
Frequently the real next step. You have a costed, evidenced argument with named owners and a measurement baseline, and you need it approved before anything happens. The strategy is written to be lifted into that paper rather than summarised for it.
2
If most of the requirement sits in native SharePoint, which it usually does, an in-house team can implement against the specification - and we write it to be built from by someone who was not in the room. We stay available for design reviews at the points where it matters, which is a handful of days rather than a project. This is the most common route for organisations with capable internal SharePoint teams, and we would rather you took it than paid us to do something you can already do.
3
Take the specification to market and let people bid against it, including us. Requirements written by someone with no stake in winning the build tend to produce more comparable bids, and you will at least be able to tell which suppliers have read them.
4
Where there is a genuine gap, or where your team has the appetite but not the capacity. The consultants who wrote the strategy stay on the engagement rather than handing over, the development and user experience people join from the same building, and everything ships into your own tenant. This is the fastest route from strategy to something people are actually using, and for most firms it is the one that gets chosen.
Dan Hawtrey, CEO and Founder of Content Formula, spent six years as knowledge management manager at Johnson & Johnson before founding Content Formula in 2005. The practice is led from the client side of this problem rather than the supplier side, which is a different starting point from most Microsoft partners who arrived at knowledge management through the platform.
Content Formula has worked on SharePoint and Microsoft 365 since 2005, from London, for clients operating globally. Knowledge management has been part of that from the first year, because the organisations that care most about findability are the ones whose knowledge is the thing they sell.
Two things follow from starting in-house rather than in a partner channel. Knowledge management is scoped here as an ownership and curation problem before a platform problem, which is why the questions in a first conversation are about who decides rather than what you have licensed. And the consultants who scope an engagement are the ones who run it – where structural user experience work or custom development is needed, those people are in the same building rather than a delivery team you meet afterwards.
“They took the time to understand our organization and its needs… Our new intranet has been very well received with engagement at 80%+ in the first few weeks.”
Susan Inman, Director
L.E.K. Consulting
L.E.K. needed consultants anywhere in the world to find the firm’s own prior work rather than recreating it. We built the Solution Center on SharePoint Online, with expertise location surfaced alongside document results, case pages that summarised each engagement and pointed to the underlying files, and curated collections consultants could browse by theme.
The part that made it work was not the interface. It was the enterprise taxonomy underneath it, and a review step where the knowledge management team approved or corrected the tagging on every submission and redacted whatever could not travel to another client. Automated suggestion sped that process up. It did not replace the judgement, and it still does not – deciding whether a piece of work is safe to reuse elsewhere is not a task a platform can own.
Custom SharePoint Framework components covered the parts the platform could not do natively at the time, including the browsing experience and personal collections consultants could build and share.
BlogDigital workplaceIntranetIntranet strategy
Create an effective knowledge management strategy in 8 steps to align efforts, optimise sharing, and boost organisational success
12 August 2024
BlogIntranet strategySharePoint Intranet
Explore best practices for using SharePoint in knowledge management (KM) to enhance efficiency and collaboration.
30 April 2024
If people cannot find things at all, the issue is probably structural. Our findability calculator gives you a rough figure for what searching is currently costing you.
Bring us the thing your people keep recreating and we will tell you whether it is a curation problem, a structural problem, or already solvable with what you own. No charge for that conversation.
A knowledge management consultant establishes what an organisation should capture and reuse, who owns each category of it, and what standard something has to meet before it is trusted. In practice that means defining knowledge domains and their owners, designing how knowledge gets captured at the point work finishes, setting the review and approval model, and specifying the system that supports all of it. The technical build is usually the smaller half of the work. The larger half is getting agreement on what qualifies as worth keeping, because a standard nobody accepts is a standard nobody applies.
Yes, and for most organisations already on Microsoft 365 it is the sensible default. SharePoint provides document libraries with managed metadata, content approval workflow, version history, retention and expiry rules, item-level permissions and search that respects all of it – which covers the majority of what a knowledge management system needs to do. What SharePoint does not provide is the decisions: which knowledge is worth curating, who reviews it, and how capture fits into how people actually work. Those are the reason knowledge management projects succeed or fail, and no platform supplies them.
Usually not, though you should be sceptical of anyone answering that question who sells the software. The genuine case for a dedicated product is narrower than the market suggests – typically external or customer-facing knowledge bases, very high-volume service desk knowledge with specific workflow requirements, or an organisation whose knowledge is spread across many non-Microsoft systems. For internal knowledge inside an organisation already using Microsoft 365, the more common finding is that the platform can do it and the design work was never done. A product bought to avoid that design work generally reproduces the same problem in a new interface, with a licence attached.
The business, with IT supporting it. Knowledge management requires judgements about what is accurate, current and safe to reuse, and those judgements can only be made by people who understand the work. IT cannot decide whether a document is good enough to reuse with another client. What works in practice is a named owner for each knowledge domain who sits in that part of the business, a defined review frequency, and a retirement rule – with IT responsible for the platform, permissions and integration. Initiatives that fail almost always fail on this point rather than on technology: nobody was accountable for quality, so quality drifted and people stopped trusting the system.
Measure reuse and time-to-answer rather than volume. The count of documents in a library tells you nothing, and a rising count is often a warning. Useful measures include how often curated material is reused on new work, how long it takes a new joiner to become productive, how frequently the same question is asked more than once, and how much of the library has been reviewed within its own review period. In professional services, reuse per matter or per engagement is usually the figure that carries a business case, because it converts directly into recoverable time. Agree the measures before the project starts, because most of them need a baseline you cannot reconstruct afterwards.
