How to build the business case for asset visibility — and start small

Asset-tracking proposals often begin with a site, a technology and a large asset count.

"Install readers across the building and tag everything" may describe a deployment, but it is not a business case. It does not explain which operational problem changes, how value will be measured or why the proposed coverage and precision are worth paying for.

A stronger case begins with one expensive visibility failure and works outward.

1. Define the problem in operational terms

Avoid starting with "We need RFID" or "We need real-time tracking".

Describe what happens today:

• Teams repeatedly search for shared tools before work can begin.

• Returnable containers leave the site and cannot be accounted for.

• Inventory records drift, creating disruptive counts and local checks.

• Unexpected movement is discovered too late to investigate efficiently.

• Existing systems show expected locations but lack physical evidence.

Then state the consequence: labour, loss, delay, excess stock, investigation effort, customer impact or risk.

A useful problem statement is specific enough to test:

Maintenance teams lose productive time searching for a defined population of shared tools because the asset register shows assignment, not where each tool was last seen.

2. Bound the asset population and flow

Choose a population rather than a whole site.

Document:

• Number and type of assets.

• Value and operational criticality.

• Where they enter, move, wait and leave.

• The people and systems involved.

• Boundaries where movement becomes important.

• Existing identifiers, labels or records.

• Environmental conditions that may affect detection.

• Exceptions and workarounds in the current process.

This creates the end-to-end context needed to shape a deployment. It also prevents an apparently small hardware trial from ignoring the people, process and integration work required for a usable result.

3. Measure the current cost

Use evidence the organisation already has where possible: purchase records, count schedules, incident logs, operational delays and staff observation.

Labour

For searching, counting or investigation:

Incidents × people involved × average hours × loaded hourly cost

Loss and replacement

Separate routine replacement, emergency purchasing, rental and expedited delivery. Avoid assuming every missing item is permanently lost.

Disruption

Record delayed tasks, orders or production steps. Keep operational impact separate from direct labour so the calculation remains transparent.

Working capital and buffer stock

Identify extra stock held or purchased because the record is not trusted. Use Finance-approved carrying assumptions rather than a generic percentage.

Control effort

Include stocktakes, cycle counts, local checks, reconciliation and audit preparation linked to the population.

The hidden cost of poor asset visibility provides a fuller cost map, while the cost of searching is often the easiest baseline to collect.

4. Define the answer the operation needs

Specify what a user or system must know and do.

Possible answers include:

• The last operational zone in which an asset was detected, with time and evidence.

• Whether an asset crossed a controlled boundary.

• Which assets differ from their expected location.

• Which assets have not been detected within a relevant period.

• The movement history needed to investigate an exception.

• A movement event delivered to an existing workflow.

Then define how fresh, precise and complete the answer must be.

This is where the technology requirement comes from. A last-known zone may be sufficient for a search. A safety process may require a frequently updated precise position. Read last-known location or real-time tracking before buying more precision than the decision needs.

5. Choose success measures before the technology

Select a small set of measures tied to the original problem.

Examples include:

• Search incidents and person-hours.

• Time to locate a requested asset.

• Time between unexpected movement and awareness.

• Investigation hours per incident.

• Inventory discrepancies and reconciliation effort.

• Items in unexpected locations.

• Assets that have gone undetected.

• Emergency replacement spend.

• Delayed work attributable to unavailable assets.

• Percentage of scoped assets reliably associated with the correct tag and record.

Include data-quality measures as well as commercial outcomes. A deployment cannot credibly claim value if the asset associations, coverage or location interpretations are not trusted.

Do not use the number of reads as the headline success measure. Reads are an input.

6. Design the smallest deployment that can prove the answer

A good first deployment is bounded but operationally complete.

It should include:

• A representative asset population.

• The real areas and movement points needed to answer the question.

• Tag selection and association.

• Representative environmental conditions.

• The platform workflow users will actually follow.

• The minimum necessary integration.

• Named owners for exceptions and technical operation.

• A baseline and agreed evaluation method.

Small should not mean a tabletop demonstration that avoids every difficult part of the real process. The deployment needs enough scope to test whether the answer survives contact with the operation.

7. Select technology against the requirement

Compare RFID, BLE, UWB or other approaches using:

• Asset-population economics.

• Required location granularity and freshness.

• Range and coverage pattern.

• Tag power and maintenance.

• Materials and radio environment.

• Installation constraints.

• Full lifecycle cost.

• Ability to feed a consistent operational record.

Use site testing. A datasheet cannot prove performance around your assets, layout and movement.

Read RFID, BLE or UWB for the buyer-level trade-offs.

8. Keep integration proportionate

Identify the systems that own expected locations, commercial records, asset identifiers or operational workflow.

For the first deployment, integrate only what is needed to prove value. This may be an identifier import, an expected-location comparison, an event pushed to an existing alerting process or a last-known location shown in another operational interface.

Avoid creating a standalone record that must later be reconciled manually, but also avoid turning the first use case into an enterprise integration programme.

Asset tracking should not become another disconnected system explains how to define those boundaries.

9. Agree the decision after the first deployment

Before starting, define what happens after evaluation.

Possible outcomes are:

• Expand to more assets or zones because the evidence supports the case.

• Adjust tag, reader or process design and retest a known weakness.

• Keep the deployment bounded because it solves a local problem economically.

• Stop because the operational value does not justify the complexity or cost.

A credible evaluation permits all four outcomes. If expansion is assumed regardless of the evidence, the first deployment is a sales stage rather than a learning stage.

A simple business-case structure

Bring the case together under six headings:

1. Problem: What visibility failure happens today?

2. Population and flow: Which assets, areas, people and systems are involved?

3. Current cost: What labour, loss, disruption, working capital or control effort does it create?

4. Required answer: What must a person or system know and do differently?

5. First deployment: What is the smallest operationally complete scope that can test the answer?

6. Scale decision: Which measures will justify expansion, adjustment or stopping?

This is enough to begin a serious conversation without pretending every implementation detail is already known.

Start with the problem, then earn the right to scale

Waytrail provides the consistent platform layer behind a first deployment: asset and tag identities, sites and zones mapped to the operation, interpreted sightings, last-known locations, movement history, reports, REST APIs and signed webhooks. RFID, BLE, UWB and other approaches can feed that same record when the use case warrants them.

We begin by understanding the assets, environment, workflow and commercial case, then shape a deployment around them. Expansion should follow evidence from the operation — not a commitment to tag everything on day one.