RTLS Pilot Project: What Your Proof of Concept Should Verify
2026-09-15
Most real-time location system deployment plans end with the same sentence: "We will run an RTLS pilot project in one zone first and then expand company-wide." The order is right. For a technology whose results depend on site conditions, verifying in a small area before scaling is safer than building everything at once.
Yet when you open the actual PoC (proof of concept) plan, the "what to verify" part is often empty. Equipment is installed, someone confirms that dots move on the screen, and a few weeks later everything is taken down. Checking that the equipment powers on and verifying that it works at your site are two different things. A PoC that stops at the former runs into problems it has never seen before at the scale-up stage.
This article covers how to design the proof of concept for an RTLS pilot. We walk through, in order, where to place the pilot zone, what to measure and what to use as pass criteria, and what else besides the technology should be verified at the same time.
I. An RTLS proof of concept verifies conditions, not specifications
The RTLS accuracy figure in a catalog is a number with conditions attached. It was measured in open space, with anchors placed in clear line of sight, and with tags attached at appropriate positions. Your site has metal equipment packed tightly together, ceilings that are high or low, and forklifts that block the view all the time. We covered why accuracy differs between a demo environment and a real site in detail in Why location tracking becomes unstable in the field.
So the question a PoC asks is not "Is this product good?" It is "What works and what does not under our site conditions?" Finding in advance the points where results diverge by condition, such as a factory full of metal, a warehouse with high ceilings, or a temporary work area with no power, and putting them on the verification list is, without exaggeration, the whole of PoC design.
II. Verification items differ from site to site
Even with the same real-time location system, the top-priority verification item changes completely depending on the site type.
| Site type | What to verify first |
|---|---|
| Metal material yards and warehouses | Position stability amid reflection and shielding, telling upper from lower levels in multi-tier stacking |
| Construction and plant sites | Continuous operation in areas without power or network, relocating equipment as work progresses |
| Office and laboratory asset management | Tag adhesion durability, removal detection behavior |
| Hospitals and care facilities | Radio interference with medical devices, low-light conditions at night |
| Outdoor vehicles and gates | Recognition rate at night and in bad weather, rainy season and extreme cold |
There is one rule in common: verify site conditions, not technical specifications. Write down the conditions you find most doubtful at your site first, and the items to check in the PoC follow naturally.
III. Choose RTLS pilot zones that include the hardest spot, not the best one
The pilot zone should be a scaled-down version of the full deployment. If you verify only in open areas that are easy to install in, the results come out clean, but they do not represent the sites you will face at the scale-up stage.
When selecting zones, it is best to include three things. First, an area dense with metal equipment or stacked materials. This is where the radio environment is worst. Second, corridors and intersections with frequent movement of people and equipment. This is where occlusion (NLOS) occurs constantly. Third, the representative ceiling height of the space you intend to operate in. A different ceiling height changes the anchor layout and the conditions for indoor positioning accuracy.
Set up this way, the PoC results contain both "performance in a good zone" and "performance in a bad zone." The gap between the two becomes the supporting data for designing the full deployment.
IV. Agree on RTLS accuracy metrics before you start
The most wasteful ending to a PoC is when, after everything is finished, interpretations differ on whether it was a success. The only way to prevent this is to agree on the measurement items and criteria in writing before starting.
Agreeing on a single number such as "accuracy of X cm" is not enough. There are four values to look at together.
- Average and worst case: A system that averages 30 cm but occasionally jumps by 3 m, and a system that averages 50 cm but never jumps, can be rated the opposite way depending on the use case.
- Availability: The share of total operating time during which positions were captured normally.
- Dropouts and recovery: How long it takes for the signal to come back after it drops.
- Update rate: Whether it is the rate your use case needs. Faster is not better; it is a trade-off against battery life.
Also define the measurement method together. If you write down at which points, and how many times each in a stationary state and in a moving state, measurements will be taken, the report after the PoC becomes a verdict rather than an interpretation.
V. Do not verify only the technology and skip operations
What collapses at the scale-up stage is usually not the technology but operations. During the PoC period, it is worth rehearsing operations alongside the technical verification.
Who attaches the tags and when, and who collects them when the tagged person or asset leaves. How often batteries are checked, and whether they are replaced or recharged. Who receives alerts, and what the recipient does. These questions have nothing to do with equipment performance, but at the point of company-wide rollout, they are hit before performance is.
It is also safer to include integration with existing systems in the PoC scope. If there is a system that will receive location data (MES, WMS, time and attendance, security), passing even a single record in advance to see which fields can actually be sent and at what interval speeds up the integration design in the full deployment.
Finally, the indoor positioning method itself can be a subject of PoC verification. This means separating the zones that need precision from the zones where zone-level aggregation is sufficient. The differences between methods are summarized in our guide to choosing between UWB and BLE.
VI. Deployment considerations: design backward from the scale-up
The last checklist item of an RTLS pilot is the scale-up path. Confirm whether the anchor, tag, and server configuration used in the pilot zone is a structure that simply grows at company-wide rollout, or whether the configuration has to change midway. If equipment has to be replaced at expansion time, a large part of the pilot investment becomes a sunk cost.
After the verification is complete, record the results in numbers: measured values by zone, items that passed and items that fell short, and the conditions to be addressed when scaling. With this document, the scale-up decision is made on data rather than on someone's impression.
In closing
An RTLS pilot is not a period for trying out equipment in advance. It is a period for turning your site's conditions into numbers. Include the hardest conditions in the zone selection, agree on the measurement criteria before starting, and verify operations together with the technology, and a single PoC becomes the design document for the company-wide deployment.
ORBRO works with you from the PoC stage, starting with zone selection and the design of verification items. The screens used during the verification period are the very monitoring screens of the full deployment. Because the configuration and data accumulated in the pilot zone scale up as they are on ORBRO OS, verification and deployment continue without a break. If you are considering a pilot deployment, please contact us with your site conditions.
