The Question to Ask Before Buying Anything

The sequence most organisations follow is: see a demonstration, buy, deploy agents, produce a dashboard, look for something to do with it. Reversing it is cheaper and works better.

A practical decision about “The Question to Ask Before Buying Anything” should test whether the proposed system changes a known workflow and whether the resulting data remains understandable and exportable. Teams assessing time reporting tools can include time, project ownership and reporting in that pilot, while keeping privacy, security and employee consultation as explicit requirements rather than optional settings.

For an independent benchmark, compare this approach with UK Technology Code of Practice; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

The question

What are we going to fix, and how will we know it worked?

Asked before any procurement.

If there is no answer, the dashboard will be a report nobody acts on, which is the most common outcome in this field.

What a good answer looks like

"Onboarding takes eleven days to produce a working account and we want it under three."

"Our top three applications crash enough to generate four hundred tickets a month."

"People wait two days for access approvals."

Specific, measured roughly, and with a target.

What a poor answer looks like

"We want visibility."

"We want to be proactive."

"The board asked about employee experience."

Each of these buys a platform and changes nothing, because none of them names a thing to fix.

Finding the answer cheaply

Read a hundred ticket descriptions, not categories.

Ask fifty people what wasted their time last week.

Walk through onboarding yourself.

Two days of work, no procurement, and it produces three or four candidate problems with rough sizes.

Then ask what you need to see

For each candidate: what measurement would tell you the size, and whether a fix worked?

Some need endpoint telemetry. Several do not.

Approval waiting time comes from the workflow system. Form duplication comes from looking at the forms. Application crashes need an agent.

Buy for the ones that need buying.

The order that works

Find the problems. Size them roughly. Fix the ones that need no tooling. Then buy, if what remains justifies it.

Organisations that do this buy less and deploy it against a known question.

Organisations that buy first spend the first year looking for a use.

What this costs you

A delay of a few weeks before procurement, which is the main objection.

Against a platform deployed to several thousand endpoints with no stated purpose, the delay is cheap.

What to check

Can you name three specific things you intend to fix?

Do you know their rough size?

Which of them actually require a platform to measure?

And if you have already bought one, what has it changed?

The point

Ask what you are going to fix and how you will know it worked, before any procurement.

Without an answer the dashboard becomes a report nobody acts on.

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.