Close the loop with the people who write knowledge
· 1 min read
Authors stop writing when they never hear whether an article was approved, rejected or used.
In brief
Someone on your service desk wrote a knowledge article last month. Do they know if anyone read it? Usually not. They wrote it, submitted it, and heard nothing: no word that it was approved, no word that it was rejected or why, and no word that it saved dozens of tickets. Then organisations wonder why people stop writing. Silence is not neutral. To the person who wrote the article, silence reads as this did not matter.
This article argues that closing the loop is not complicated. Tell authors when their article is approved, and when it is sent back with the reason. Tell them when someone flags it as out of date or wrong so they can fix it. Tell them when it is being used, and roughly how much, because people keep doing the things they can see making a difference. Knowledge does not come from a system. It comes from people who take ten minutes at the end of a busy day to write down what they learned. The least we can do is let them know it landed. Join the conversation on ESM's Exchange.
Silence after writing
Someone on your service desk wrote a knowledge article last month.
Do they know if anyone read it?
Usually not. They wrote it, submitted it, and heard nothing. No word that it was approved. No word that it was rejected, or why. No word that it saved forty tickets last week.
Then we wonder why people stop writing.
Silence is not neutral
Silence is not neutral. To the person who wrote the article, silence reads as this did not matter.
Closing the loop
Closing the loop is not complicated:
- Tell authors when their article is approved, and when it is sent back, with the reason.
- Tell them when someone flags it as out of date or wrong, so they can fix it.
- Tell them when it is being used, and roughly how much.
That last one matters most. People keep doing the things they can see making a difference.
Who knowledge really comes from
Knowledge does not come from a system. It comes from people who take ten minutes at the end of a busy day to write down what they learned. The least we can do is let them know it landed.
Next step
When did you last thank someone for an article they wrote? More on knowledge and self-service in the Knowledge library on ESM's Exchange: 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.
