Which knowledge should the outside world see?
· 2 min read
Decide who the outside world is and what they need before opening knowledge, with clear rules and a named owner.
In brief
Opening knowledge to people who are not signed in, such as customers, students, suppliers or the public, is one of the cheapest ways to reduce contact, and one of the easiest ways to embarrass an organisation, because internal articles carry workarounds, known faults and system names. This article argues that most organisations decide what is public by accident, article by article. It suggests starting from the audience instead: decide who the outside world is and what they need, then write knowledge for them in their language. It sets out simple rules: public by decision, never by default; one named owner for public knowledge; no internal detail in public articles; and more frequent reviews, because the cost of being wrong is higher. It notes that AI assistants and search tools now read public knowledge too and repeat it with confidence. It closes with three questions to settle first, including Ian Hughes's test from What Stays the Same, "What would this person feel misled to discover later?"
Somewhere in your knowledge base is an article written for colleagues that a customer would find very useful. Somewhere else is one that a customer should never see.
Most organisations decide which is which by accident.
Opening knowledge to people who are not signed in, such as customers, students, suppliers or the public, is one of the cheapest ways to reduce contact. People help themselves. Search engines find your answers. Fewer calls, fewer emails. It is also one of the easiest ways to embarrass yourself, because internal articles are written with an internal honesty: workarounds, known faults, names of systems, the occasional blunt comment about a supplier.
Start from the audience, not the article
The instinct is to go through articles one by one and ask "can this be public?". With hundreds of articles that becomes a slog, and the answer drifts depending on who is doing the checking.
It works better the other way round. Decide first who the outside world is and what they come to you for. A student wants to reset a password and find the opening hours. A customer wants to track an order and understand a charge. Then write or adapt knowledge for those needs, in their language.
Keep a clear line
A few rules help:
- Public by decision, never by default. New articles start internal until someone chooses otherwise.
- One named owner for public knowledge, who answers for what the world sees.
- No internal detail in public articles: no system names, no staff names, no workarounds that rely on inside access.
- Review public articles more often, because the cost of being wrong is higher.
Remember who else is reading
Public knowledge is no longer read only by people. AI assistants and search tools read it too, and repeat it with confidence. An unclear public article does not just confuse one reader. It can be summarised, quoted and passed on.
Questions to settle before you open the doors
- Who, outside the organisation, do we most want to help themselves?
- Who decides that an article goes public?
- What would a customer feel misled to discover in an article we left open?
That last question borrows Ian Hughes's test from What Stays the Same, "What would this person feel misled to discover later?" It is a good one to ask of anything you publish.
Next step:
Join the Knowledge and self-service conversation on ESM's Exchange and share how you draw the line: https://exchange.esm.institute
Tags: knowledge management, service management, self-service, ESM
Join the Exchange free
Join free to unlock the complete knowledge library.
Founder membership is free for life
More from Esm
How should the service desk handle a Microsoft 365 outage it cannot fix?
4 min read
Deploying AI is the easy part: who runs it once it goes live?
5 min read
How do I compare help desk tool pricing before rolling it out across several departments?
4 min read
Turning 'not helpful' into a fix
1 min read
When the author leaves, who owns the article?
2 min read
Test after every change, or find out from users
1 min read
Related articles
How should the service desk handle a Microsoft 365 outage it cannot fix?
Treat a supplier cloud outage as your own major incident: log it once, tell people early on a channel that still works, update on a rhythm and review your dependency afterwards.

Deploying AI is the easy part: who runs it once it goes live?
Only a third of large enterprises have met the business case for their main AI programme. New research points to a gap in who runs AI after launch, and what leaders can do.
How do I compare help desk tool pricing before rolling it out across several departments?
Compare help desk tools on a full year's cost for your real agents, approvers and requesters in every department, not on the headline monthly price.
Turning 'not helpful' into a fix
'Not helpful' is free, honest feedback, and most of it goes nowhere. Turn that click into a fix.
When the author leaves, who owns the article?
Articles keep being read after their authors move on. Make sure the care for them does not leave too.
Test after every change, or find out from users
Knowledge changes fail quietly. A short, repeatable test after every change finds the problem before your users do.
