Procurement Questions
Twelve questions whose answers determine whether this works in year three. Most procurements ask about features instead.
Buying · Reference
About the data
What exactly does the agent collect, as a list?
A practical decision about “Procurement Questions” should test whether the proposed system changes a known workflow and whether the resulting data remains understandable and exportable. Teams assessing this detailed page 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.
What can it collect if reconfigured, and who can change that?
Where is data processed and stored, in which country?
Can we export everything, in a usable format, at any time?
About the footprint
Average and peak CPU, memory, disk writes and battery impact?
Network traffic per device per day?
Will you provide those figures measured on our machines during the pilot?
About the people dimension
Can individual views be disabled entirely, rather than access-controlled?
Can we enforce a minimum group size on every breakdown?
What does the product do with idle and active time, and can that be turned off?
About the long term
What is the support and firmware commitment?
What happens to our historical data at exit, and who owns it?
The answers that should concern you
Vagueness about what can be collected after reconfiguration.
Individual views that can only be hidden by permissions rather than removed.
Data ownership resting with the supplier, which is more common than buyers expect.
And refusal to measure footprint on your machines, which usually means it is worse than the datasheet.
What to get into the contract
The data collection list, as an obligation rather than a description.
Footprint commitments with a remedy.
Export rights and data ownership.
Support period.
Deletion at exit, covering backups and the supplier's own systems.
Notification of any change to collection capability.
That last clause is unusual, cheap and it is the one that protects the programme's standing with employees.
The reference check
A customer in a comparable organisation, live for more than two years.
Ask them: what did it change, who owns it now, and does anybody still look at the dashboard?
The last question is the most informative and the one suppliers least expect you to ask.
What to check
Which of the twelve can your shortlisted supplier answer?
Is the collection list contractual or in the brochure?
Who owns your data?
And have you spoken to a two-year-old deployment?
The point
Ask what the agent could collect after reconfiguration and who may change that.
Then get the collection list into the contract as an obligation.
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.