RTLS readiness assessment: are you ready to buy this yet?
Most locating programmes that fail were not defeated by the technology. They were bought by an organisation that was not ready for them. This is how to find that out cheaply, before the capital request.
Readiness is not the same as feasibility
A feasibility study asks whether the technology will work in your building. A readiness assessment asks whether your organisation can absorb it.
Both can pass. Both can fail independently. A programme that is technically sound and organisationally premature will still be written off, and it usually gets blamed on the vendor.
The five dimensions
1. Decision readiness. Is there a named owner with budget authority? Has anyone written down what decision the location data will change? If the answer to "what will you do differently once you know where everything is" is vague, the programme has no destination.
2. Data readiness. Is your item master accurate? Do locations have a consistent naming convention? Is there one identifier per physical thing, or several? Locating systems expose master data problems mercilessly — they do not cause them, but they make them visible and expensive.
3. Process readiness. Is the process you are instrumenting stable, or about to change? Instrumenting a process that is mid-redesign means building twice. If a new ERP or warehouse system is landing within a year, that sequencing question outranks every technology choice.
4. Technical readiness. Network coverage, cabling routes, power at anchor positions, IT and OT segmentation policy, cloud posture, and who is allowed to put a device on the network. This is where programmes stall for months, invisibly, after the contract is signed.
5. Organisational readiness. Will the people whose work becomes visible accept it? Worker tracking has a consent and industrial-relations dimension that is not optional and not solvable afterwards. In the EU it also has a legal one: the GDPR applies, and Article 88 lets member states set more specific rules for employee data.
Where programmes actually stall
Three failure points come up again and again in locating programmes, and none of them is radio.
No stated decision. The system was bought to provide visibility rather than to change a specific action. Visibility is not an outcome. Six months after go-live there are dashboards nobody opens.
Master data. The location system says one thing, the ERP says another, and there is no agreement about which is authoritative. Every discrepancy becomes an argument instead of a signal.
Nobody measured the before. The improvement is real but unprovable, so the next phase is not funded. This is the cheapest failure to avoid and the most common.
A quick self-assessment
Answer honestly. Any two no answers is a reason to do preparatory work before going to market.
- Can you name the person who owns this programme and the budget?
- Can you state, in one sentence, what will happen differently once the data exists?
- Is there one identifier per physical item, used consistently across systems?
- Are your location or bin names consistent and current?
- Is the process being instrumented stable for the next twelve months?
- Do you know who authorises a new device class on the network?
- Do you know what you will measure to prove the benefit, and do you have the baseline?
- If people are tracked, has that conversation happened with them or their representatives?
- Do you know which system is authoritative when two disagree?
- Is there a budget line for years two to five, not just the build?
What to do about a low score
Not "wait". Most gaps are fixable in weeks and cheaper to fix before procurement than after.
Missing baseline: specify and start capturing it now. That costs almost nothing and it is the difference between a defensible payback figure and an industry average.
Master data problems: scope them. You rarely need to fix everything — only the identifiers the locating system will touch.
Unstable process: reduce scope to the part that is stable, and design the data model so the rest can be added.
No stated decision: this is the one to resolve before anything else. If nobody can say what changes, the honest recommendation is to stop.
Readiness affects what you buy, not just when
A less mature organisation is usually better served by a narrower first deployment with a clean data layer than by a comprehensive platform. It costs less, proves value faster, and does not commit you to an architecture chosen before you understood the problem.
The corollary matters commercially: vendors sizing a proposal from your ambition rather than your readiness will oversell you. That is not malice. Nobody asked them to assess readiness.
How we run it
A readiness assessment is typically a few days of work and a short written output: the score by dimension, the specific gaps, and what to do about each before going to market. It is deliberately cheap relative to what it protects.
Related: feasibility study, pilot success criteria, vendor selection checklist, how we work.
Sources
This guide sets out a method; it uses no vendor figures or statistics. Its one legal reference is listed below, checked on 25 September 2026.
Last updated: 25 September 2026