Approvals that do not become bottlenecks
· 1 min read
Knowledge approvals protect quality only when approvers are notified, named and timed.
In brief
Most knowledge approval steps were designed to protect quality. Many of them end up protecting nothing except the queue. An article is written, it waits for review, and the approver is busy, on leave, or never saw the request. Meanwhile the people who needed that answer raise tickets instead. An approval that nobody knows is waiting is not a control. It is a delay with a nice name.
This article argues that the fix starts with telling the approver, clearly and at the right moment, that something needs them. Three plain rules help: one named approver per area with a named deputy; a time limit after which it escalates or the deputy steps in; and a short shared definition of what the approver is checking for. Not every article needs the same gate. A printer driver fix and guidance on personal data do not carry the same risk and should not wait in the same line. Approval is meant to put a person's judgement on the work. If it only puts a person's name on the delay, change the design, not the people. Join the conversation on ESM's Exchange.
When a control becomes a queue
Most knowledge approval steps were designed to protect quality. Many of them end up protecting nothing except the queue.
The pattern is familiar. An article is written. It waits for review. The approver is busy, on leave, or never saw the request. Meanwhile the people who needed that answer raise tickets instead.
An approval that nobody knows is waiting is not a control. It is a delay with a nice name. The fix starts with telling the approver, clearly and at the right moment, that something needs them.
Three plain rules
- One named approver per area, with a named deputy.
- A time limit, after which it escalates or the deputy steps in.
- A short, shared definition of what the approver is checking for.
Not every article needs the same gate
Ask honestly which articles need approval at all. A fix for a printer driver and guidance on handling personal data do not carry the same risk. They should not wait in the same line.
Change the design, not the people
Approval is meant to put a person's judgement on the work. If it only puts a person's name on the delay, change the design, not the people.
Next step
How long does an article wait for approval where you work? Join the conversation 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.