Use what you already pay for
· 1 min read
Most service teams pay for features they have never switched on, then buy something new to do the same job.
In brief
Most service teams are paying for features they have never switched on. Then they go and buy something new to do the same job. It usually starts with a fair complaint: we cannot see what is going on in knowledge. So someone builds a spreadsheet, then a custom dashboard, then a business case for a new reporting tool. Meanwhile the platform already has an overview page that shows most of it. Nobody turned it on, because nobody knew it was there. New tools feel like progress. Configuring the old one feels like admin. That is the trap. Novelty gets a budget. Housekeeping gets a shrug. Every extra tool has a cost that does not show on the invoice: another login, another place for the numbers to disagree, and another thing to keep alive when the person who built it moves on. This article argues for asking three plain questions before you buy or build. What does the platform already do here? Have we actually tried it, properly, for a few weeks? What would we still be missing if we did? Often the honest answer to the last one is not much. The gap was never the software. It was the time to look.
Most service teams are paying for features they have never switched on. Then they go and buy something new to do the same job.
It usually starts with a fair complaint. "We can't see what's going on in knowledge." So someone builds a spreadsheet. Then a custom dashboard. Then a business case for a new reporting tool.
Meanwhile the platform already has an overview page that shows most of it. Nobody turned it on, because nobody knew it was there.
New tools feel like progress. Configuring the old one feels like admin. That is the trap. Novelty gets a budget. Housekeeping gets a shrug.
And every extra tool has a cost that does not show on the invoice. Another login. Another place for the numbers to disagree. Another thing to keep alive when the person who built it moves on.
Before you buy or build, three plain questions
- What does the platform already do here?
- Have we actually tried it, properly, for a few weeks?
- What would we still be missing if we did?
Often the honest answer to the last one is "not much". The gap was never the software. It was the time to look.
Next step
What have you found already sitting in your platform, unused? Join the conversation on ESM's Exchange: https://exchange.esm.institute
Tags: knowledge management, service management, reporting, 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.