RTLS Provider Evaluation: Pilots, Proofs, and POCs

The sales demo is almost always dazzling. A tag moves across a floor plan on a tablet, dots glide, alerts fire on cue. Then the pilot starts, and the gulf between demo and deployed reality shows up quickly. An elevator turns into a location blind spot. A nurse returns tagged equipment to a closet without walking past a beacon, so the asset never updates. Batteries sag in week six. IT discovers that multicast traffic floods a closet switch. None of this means real time location services do not work. It means you need a structured, honest evaluation that separates proof of technology from proof of value, and a vendor who understands that a pilot is an engineering and change management exercise, not a theater production.

I have run or audited more than a dozen RTLS evaluations across hospitals, manufacturing plants, and distribution centers. The organizations that succeeded treated pilots as a chance to learn, not just to confirm a preselected answer. The ones that stumbled either tested too little or tried to boil the ocean. The following playbook focuses on how to design, run, and judge pilots, proofs, and POCs for a real time location system with realism and rigor.

A clear problem statement anchors scope, technology choices, and measures. If you cannot write the business objective in two sentences a frontline manager would recognize, you are not ready to pilot. “Reduce lost infusion pumps so rental spend drops by 30 percent within 6 months” is better than “Evaluate RTLS for asset tracking.” So is “Cut changeover search time on Line 3 from a 12 minute median to under 4 minutes” rather than “Test location for SMED.”

Tie each objective to a measurable outcome and a budget owner who cares. RTLS management succeeds when the people paying for it have skin in the game. During one hospital pilot, the biomedical engineering director sat on the steering committee and approved success criteria. That single decision made more difference than any antenna mount.

These terms get used interchangeably. They should not. Each serves a different purpose and carries different bar for success.

A POC is a narrow, often lab-style test to answer a specific question. Will the vendor’s tags pair with your existing Wi‑Fi? Can the event engine push JSON to your CMMS? A proof of technology widens the lens to production-like conditions. Can the technology maintain 3 to 5 meter accuracy across the emergency department while elevators, carts, and phones add RF noise? Proof of value is where you prove ROI in a real workflow, with enough volume and time to generate credible numbers.

You do not need to run all three in sequence every time. If you already know BLE beacons work in your building from a past project, skip the POC and head to a short pilot that proves value. If the use case requires 30 centimeter accuracy to segregate side-by-side work cells, do not pretend a BLE-only POC will tell you anything about an ultra-wideband deployment. Match the proof to the problem.

Real time location services arrive through several common modalities, often in hybrid. What matters is the trade space among accuracy, density of infrastructure, battery life, and total cost.

| Technology | Typical accuracy | Infrastructure density | Tag battery life | Notes | |-----------|-------------------|------------------------|------------------|-------| | BLE RSSI trilateration | 3 to 10 m, depends on calibration | Medium, beacons every 8 to 15 m for room-level | 6 to 36 months | Low cost, sensitive to multipath, benefits from zone logic | | BLE AoA | 1 to 3 m with good antenna arrays | Medium to high, arrays per zone | 6 to 18 months | Better accuracy, more complex install and calibration | | Wi‑Fi RSSI/RTT | 5 to 15 m for RSSI, 1 to 2 m for RTT-capable APs | Uses existing Wi‑Fi for RSSI, dense for RTT | Months to years | Leverages network, but client support varies | | UWB TDoA | 10 to 30 cm line-of-sight | Medium, anchors every 20 to 30 m | 6 to 24 months | Excellent precision, higher cost, needs careful sync | | IR/Ultrasound zoning | Room-level presence | Emitters per room | Multi-year | Works well for room certainty, blocked by line-of-sight or noise | | LF exciters + BLE | Doorway or chokepoint certainty | Exciters at portals | 12 to 36 months | Good for entrances, complements BLE/UWB |

If a vendor insists a single technology fits every use case, that is a red flag. Asset tracking, staff safety, contact tracing, and work-in-process each stress the system differently. For example, staff safety demands near-instant event latency and coverage in stairwells and bathrooms, not just general accuracy. A real time location system for rental reduction can tolerate a few minutes of location staleness if it reduces tag cost by 40 percent.

You want small enough to learn quickly, large enough to stress the edges. Two nursing units with different layouts, one med-surg and one ICU, can reveal more than a hospital-wide proof that spreads too thin. In a plant, pick one high-mix line with frequent changeovers and one steady line with big batches. Select environments that include likely pain points such as elevators, mezzanines, cinderblock rooms, and equipment cribs.

Decide scope in terms of users, tags, and locations. Five to ten superusers per area is a useful target. Tags should cover at least 1.5 to 2 times the concurrent assets you expect to observe, to allow for maintenance float. If a unit runs 140 pumps at peak, issue 220 tags and plan to tag 80 percent of the fleet. Subscale pilots are notorious for hiding circulation issues that show up only when tags saturate closets and chargers.

Turn the problem statement into operating metrics. Accuracy by itself rarely moves the needle. Reliable location update rate, end-to-end event latency, and findability do. Measure the percentage of searches that succeed within a target time, measured from the moment a user enters a query to the moment they put hands on the item. Track false positives, false negatives, and dropouts by zone. Watch the noise ratio on alerts, because noisy alerts train users to ignore the system.

Timebound your metrics. A pilot that performs well in week two but craters in week five after batteries dip to 2.8 volts will not survive production. If you plan to run for eight weeks, expect week seven data to be the most honest.

RF behaves like a stubborn coworker who does not like to be told what to do. Metal racks, liquid-filled equipment, fire doors with steel frames, and even daylight patterns can distort expectations. Do an RF site survey ahead of installation. Look for multipath hotspots and dead zones. In one distribution center, tags vanished in a narrow aisle every afternoon because sun heated a steel wall, which changed the BLE signal behavior enough to drop below the zone threshold. A 3 meter beacon move https://jaidennyop179.huicopper.com/real-time-location-services-in-data-centers solved it, but only after we logged temperature and correlated with signal-to-noise.

Ceilings matter. Twenty feet with exposed ductwork is friendlier to UWB anchors than a 9 foot drop ceiling that hides fire sprinklers and forces odd mounts. If ceiling access is limited, design for wall mounting and test sightlines, especially for angle of arrival arrays that need clean lobes. For ultrasound or IR zoning, walk every doorway with a tag to see how door positions, curtains, and people block line-of-sight.

RTLS only earns its place when it feeds the systems where people already live. For healthcare that is often the CMMS, EHR, and nurse call. For manufacturing it is the MES, WMS, or maintenance system. Inventory your integration points early and decide where the truth should reside. The best rtls provider will have a clean event API and a push model, not just a pollable database. Ask to see webhook retries, backoff logic, and dead letter handling. If the event engine rests behind a message queue, you should know which one and who owns it. Cloud to on-prem flows will demand firewall rules, certificates, and monitoring. Assign owners in IT and document ports and protocols. The day before go-live is not when you want to discover that your outbound TLS inspection breaks MQTT over WebSockets.

On the network side, size the traffic. BLE beacons are chatty by design. AoA arrays can generate more than 2 Mbps per array in dense scenes. UWB anchors need precise time sync and clean channel plans. Wi‑Fi based systems have to respect your airtime budget. Run a pre-pilot lab to see how many packets per second you are adding per zone and who will watch those counters in production.

You will be tracking devices associated with people and rooms. That creates privacy obligations that vary by industry and jurisdiction. A hospital must align with HIPAA interpretations for location as PHI when linked to patients. A manufacturing site with union labor may need a memorandum of understanding that forbids personal performance monitoring. The policy work is real, and it shapes the technical design. One hospital I worked with chose not to store historical staff paths longer than 7 days except when a staff safety alarm occurred. Another site used pseudonymous tag IDs in the core database and linked names only in a separate identity service with tight audit controls.

On the security side, require signed firmware on tags, role-based access control in the platform, and evidence of regular penetration testing. If tags support over-the-air updates, ask the vendor to show the update process end to end, including what happens if a tag powers off mid-flash. Validate that the vendor’s cloud meets your baseline for data residency, encryption at rest and in transit, and incident response. If you are running on-prem, agree on patching cadence and who monitors CVEs.

The difference between a pilot users love and one they quietly ignore often comes down to tag ergonomics and attachment. In a hospital, a tag that adds 60 grams to a handheld device will end up in a drawer. In a plant, a tag with a proud profile will shear off on the first pass through a tight jig. Test attachment methods. Zip ties look cheap but can survive solvents better than some adhesives. For pumps and ventilators, adhesive backed plates plus a mechanical tether reduce loss. For carts, drill-and-rivet wins, if your policy allows it.

Battery management is a program, not a task. Decide whether you will do hot-swap at point-of-use, return-to-cradle overnight, or field replace alkaline cells. Build a dashboard that shows batteries by percentile, not just average, so you can catch the long tail that dies first. Budget for spares as if you will lose 3 to 7 percent of tags per year to damage or misplacement. If a vendor claims near zero loss, ask to speak with a customer who has run longer than 18 months at scale.

Calibration is not a one-time ritual during week one of a pilot. People move furniture, open new walls, and change shelving. Run daily or weekly sanity checks. Place a small number of sentinel tags in fixed positions, and alert if their perceived location drifts. For systems that use machine learning for fingerprinting, watch for concept drift and retrain on a schedule. Track the ratio of unknown to known locations by zone. If that creeps up, dig in before users lose trust.

Truth sets matter. If your measure of success is room-level findability, you need independent ground truth. Do time studies with two observers and a stopwatch. When a user reports a miss, capture it in a structured way. What item, what search query, what time, what room, and whether the RTLS said it was elsewhere. Honest misses teach more than pretty averages.

You can keep this simple without cutting corners if you sequence decisions and learning. Here is a compact plan many teams have used effectively.

This is a guideline, not a straitjacket. Large or regulated environments may need more time for approvals. What matters is that you measure in the middle weeks when reality bites, not just at the shiny bookends.

Most rtls providers can produce a fine slide deck. Fewer perform well when the pilot gets messy. Watch how the team responds when you find a blind spot or an integration hiccup. Do they instrument and diagnose, or do they hand-wave?

When you narrow the field, use a short, pointed checklist to separate talk from substance.

A provider who cannot meet this bar probably will not carry you through the hard parts of a rollout.

RTLS costs hide in places that spreadsheets often miss. Infrastructure is obvious. So are tags. Less obvious are mounts, labor to run power, overtime for off-hours ceiling work, extended warranties, and the service motion to keep tags alive and honest.

Run the math with a simple scenario. Suppose you tag 3,000 assets across two hospitals. Tags cost 35 to 70 dollars each depending on radio and sensors. At 3,000 tags, that is 105,000 to 210,000 dollars up front. If expected loss and damage runs 5 percent per year, set aside 5,250 to 10,500 dollars for replacements annually. Batteries at 2 to 4 dollars each changed yearly could be 6,000 to 12,000 dollars if you own the swap program. Infrastructure might be 180 to 400 dollars per monitored room or zone including beacons, mounts, and labor. If you cover 600 rooms and zones, that is 108,000 to 240,000 dollars. Platform subscriptions vary widely, but a realistic range for enterprise features sits between 60,000 and 180,000 dollars per year for this scale, often priced per tag or per site.

Now layer ROI. If you spend 500,000 dollars a year renting specialty equipment and cut that by 30 percent, you just freed 150,000 dollars. If nurse search time drops by 6 minutes per shift and you have 700 nurses, that is millions of minutes a year, some of which converts to staffing flexibility or reduced overtime. Be conservative. Do not count soft savings twice. Focus on 2 or 3 hard lines that a CFO will recognize. The proof of value should generate those lines during the pilot or make a credible forecast grounded in measured deltas.

RTLS touches people’s habits. If you ask technicians to tag every device that leaves the shop, build that into their daily rhythm. In one manufacturing plant, the pilot failed until we added a simple rule at shipping: no item passes the door until the screen shows green for tag present. That change required a one-time training and a small UI tweak, not another antenna. In a hospital, charge nurses became the local champions when we gave them a live list of “idle for more than 2 hours” assets at change of shift. They created a habit of rounding for assets the way they already rounded for patients.

Plan for what happens when the system is down. Who do users call, what is the fallback, and how do you prevent learned helplessness. The best rtls management programs formalize an adoption plan with named champions, daily checks, and monthly reviews, just like any other operational tool.

The most painful failures share patterns. A pilot with too few tags gives a false sense of success because contention never happens. A vendor who disables features to improve pilot performance sets you up for surprises at scale. Battery plans that rely on goodwill instead of a schedule die within a quarter. Privacy policies that leave room for surveillance fears trigger pushback that no amount of technical tuning will fix. All of these are avoidable with upfront clarity and a sober scope.

Avoid anchoring to accuracy as the only virtue. I have seen UWB pilots that could place a cart on the correct side of a doorway within 20 centimeters, and yet failed because the tags were too bulky and the event engine delivered alerts 25 seconds late over a congested backhaul. A BLE pilot with 3 to 5 meter accuracy but excellent chokepoint certainty and sub 3 second events saved more money and earned more trust.

Not every situation needs a six to eight week pilot. If your primary uncertainty is technical compatibility, a 2 to 3 day POC in a lab or a single hallway can answer that question cheaply. Good candidates include confirming that your Cisco APs support the Wi‑Fi location API the vendor needs, that your CMMS webhook can ingest an event and create a work order, or that your high-noise stamping area does not knock ultrasound sensors off their game. Keep POCs tight, write down the specific question, and do not generalize their outcome to ROI. A POC cannot tell you whether users will adopt the system.

By the time the pilot ends, you should be able to produce a narrative and a few charts that tell a simple story. Did users find assets faster, and by how much. Did rental spend bend. Did the maintenance backlog for preventive checks drop because the system found idle time windows. What did not work and what you changed. Show a short list of defects you will fix before scale, with owners and dates. Include a go or no-go recommendation and an alternative. A red team review helps, especially if you have a second rtls provider in contention. Let them critique the results and propose how they would have done it differently, then judge if those claims are credible.

The scale plan should look like any other rollout plan for enterprise technology. Sequence by building or line, align with planned outages if ceiling work is needed, and stage tags and chargers ahead of time. Train champions before general users. Prove integrations in a pre-prod environment first, and cut over with a backout plan. Decide who owns the RTLS network day to day and who pays for the pieces. A good provider will hand you their standard playbook and adapt to your constraints.

RTLS is neither magic nor a commodity. It is an applied engineering tool that must fit your space, your workflows, and your appetite for change. The best evaluations are honest about what matters. They embrace small failures in weeks 3 to 6 and learn from them. They respect privacy and security as foundational. They choose the rtls provider who behaves like a partner in the messy middle, not just a performer in the demo.

If you take that posture, the pilot becomes a springboard. Your team will know why they chose a specific real time location system, what it costs to run, how it connects to the work, and how it will earn its keep. That is what separates a proof of value from an expensive science project.

TrueSpot
5601 Executive Dr suite 280, Irving, TX 75038
(866) 756-6656