An RFID site survey measures the real environment before hardware is bought: RF noise, metal and liquid near the tags, read points, cabling and power. A proof of concept then instruments one gate or zone for two to six weeks and tests candidate tags and readers against written success criteria — read rate, false reads, direction accuracy — with a ground-truth count and a defined exit decision.
Swedish Technology runs surveys and POCs against numbers agreed in writing beforehand, and reports the result even when it says the design must change.
What problem does this solve?
RFID fails on sites, not on paper. A supplier demo uses clean cardboard boxes, one tag model and an empty room; your dock door has a steel roller shutter, a forklift with a metal mast, pallets of bottled liquid and a neighbouring aisle whose tags the antenna can also hear. The gap between the demo and the site is where most disappointed RFID projects are created, and it is only visible if someone measures it before purchase.
The second failure is a proof of concept with no definition of success. A POC runs for a month, everyone agrees it was "quite good", and then the argument starts: good enough to scale, or not? Without a written read-rate target, an agreed method of counting, a defined sample size and a stated exit decision, the POC produces opinions instead of evidence, and the decision defaults to whoever is most senior in the room.
The third failure is scope. POCs quietly grow to include the full ERP interface, mobile apps and dashboards, so they cost as much as a small rollout and take four months. A POC should test the risky parts — can we read these tags reliably at this point, and can the events reach the receiving system correctly — and deliberately leave the rest for the project.
How the solution works
Split the work into two short, cheap phases with a decision between them. The site survey establishes physical reality: RF noise, materials, read points, distances, power and cabling, and which tag families are even candidates. The POC then tests one or two representative read points against numeric criteria agreed in advance, with a ground truth counted by hand, and ends in a written decision to scale, redesign or stop.
The checklists below are the ones Swedish Technology uses on UAE and GCC sites. They are deliberately unglamorous: most of the value comes from measuring the right things once, in the right place, and writing down the exit criteria before anyone has an emotional investment in the result. If a survey shows that RFID is the wrong tool for a given asset family, that is a successful survey.
- 1Input — scope the question Define which asset families and which process steps the POC must prove (receiving, dispatch, cycle count, tool issue), the volume per hour, and who owns the decision at the end.
- 2Capture — survey the RF environment Measure the noise floor in the UHF band at each candidate read point, log existing radio systems, motors and variable-speed drives, and record materials, pallet density, ceiling height, shutter type, floor markings and power/network availability. Photograph every point.
- 3Capture — trial the tags Test three to five tag models per asset family on the actual material and in the real orientation: read distance, orientation sensitivity, on-metal behaviour, and survival of the mounting method (adhesive, rivet, cable tie, embedded).
- 4Processing — trial the readers Test antenna type, height, angle, polarisation and transmit power at the read point; establish where the read zone ends, so tags in the adjacent aisle or the next dock door are not counted.
- 5Criteria — write the numbers down Agree read rate per asset family, acceptable false/stray reads, direction accuracy at gates, maximum latency to the receiving system, and the sample sizes and counting method that will be used to prove them.
- 6Integration — prove one path end to end Send filtered events from the POC read point into a test instance of SAP, Oracle, Odoo, Maximo or the WMS, and confirm the document or status change is correct and not duplicated on a repeated read.
- 7Action — run the POC and record everything Two to six weeks on the real process with real operators, a daily log of exceptions, and a manually counted ground truth on agreed sample days.
- 8Reporting — decide at the exit gate A short report with measured results against each criterion, the causes of every miss, the rollout design implications, a five-year cost model and one of three recommendations: scale, redesign, or stop.
Reference architecture
A POC deployment is a small version of the production architecture, with the same layers, so what you learn transfers to the rollout.
| Layer | What it contains |
|---|---|
| Tags and application method | Candidate tag models per asset family, the mounting method, the label/encode process, and the identifier scheme (GS1/EPC or an internal key mapped to the ERP asset number). |
| Read points | Fixed reader with two to four antennas at one gate or zone, plus one handheld for exception handling and for cycle-count testing. Portable power and temporary cabling are acceptable in a POC. |
| Edge filtering | De-duplication window, RSSI threshold, direction logic (antenna sequence or sensor triggers), and a raw-read log that is kept for the whole POC so any anomaly can be re-analysed. |
| POC data store and dashboard | A local database with every raw read and every derived event, and a simple screen showing reads, events, exceptions and the running read-rate calculation. |
| Integration test path | One interface to a test instance of the receiving system, with idempotency keys, so that the movement or status logic can be validated without touching production. |
Deployment options: The POC runs entirely on-site on a laptop or small server with a temporary network segment. No data leaves the site unless the customer explicitly approves it; for classified environments the POC is fully air-gapped and results are exported as a report.
Key capabilities
RF environment measurement
You know the noise floor and interference sources before choosing readers, instead of after commissioning.
availableTag selection matrix per asset family
Each asset type has a tested tag with recorded read distance and orientation behaviour on its own material.
availableAntenna and power tuning at read points
Read zones stop where you want them to, which removes most stray reads before they reach the software.
availableWritten success criteria and test method
The POC ends with a fact-based decision instead of an opinion.
availableGround-truth counting procedure
Read rates are provable at audit because they were compared with a manual count on agreed sample days.
availableEnd-to-end integration test
You see the real goods movement or asset update in a test system, including duplicate handling.
custom developmentRollout design and five-year cost model
The POC report converts directly into a costed rollout plan and a tender specification.
availableIntegrations
A POC should test exactly one integration path, deeply, rather than several superficially.
| System | Integration point & data exchanged | Direction |
|---|---|---|
| SAP MM / EWM (test client) | One goods movement type posted from filtered gate events, with duplicate suppression proven on a repeated read. → RFID Integration with SAP, Oracle, Odoo & IBM Maximo | outbound |
| IBM Maximo (test environment) | Asset last-seen location and custody update, and a work-order trigger for one exception scenario. → RFID Integration with SAP, Oracle, Odoo & IBM Maximo | bi-directional |
| Odoo (staging database) | Stock move or inventory adjustment created through the external API from POC events. | outbound |
| Warehouse management (Octopus WMS) | Receiving or dispatch confirmation compared against the handheld-scanned baseline for the same shipments. → Octopus WMS | bi-directional |
| RTLS platform (MOWQIE) | Where the POC also covers zone or real-time location, tag events and zone rules are exercised in the same trial area. → MOWQIE ÔÇô RTLS Tracking | inbound |
Industry use cases
Distribution centre
One dock door instrumented for four weeks: every outbound pallet read automatically and compared with the handheld-scanned dispatch list, per SKU family.
Government IT asset register
Two floors tagged and counted with a handheld against a manual inventory, to measure the read rate inside metal cabinets and behind desks before tagging 20,000 items.
Tool crib / heavy industry
One issue point with on-metal tags on 300 tools, testing read reliability at issue and return and the exception process for damaged tags.
Cold store or liquid stock
A deliberately hostile POC on the worst material in the catalogue, because that is where the read-rate target either holds or fails.
Yard and vehicle gate
One vehicle gate with speed and direction testing, checking that a vehicle in the adjacent lane is not recorded as passing.
UAE & GCC considerations
UHF RFID equipment in the UAE must operate within the frequency band and power limits published by the national regulator (TDRA), which follows the European allocation; readers imported and configured for the North American band will underperform and may not be approved. Plan for equipment approval and, on government or port sites, for security clearance and permits before any temporary installation — this often takes longer than the technical work. Site access windows in the GCC are frequently limited to specific shifts, and summer conditions in outdoor yards affect both adhesive tag mounting and reader enclosures. POC data usually cannot leave the site, so the analysis environment should be local, and the POC report is normally required in English with an Arabic executive summary for procurement.
Implementation approach
- 1Kick-off and scope (2–3 days) Confirm asset families, process steps, read points, volumes, the decision owner and the date the decision must be made.
- 2Document review Site plans, existing radio systems, network and power drawings, current SOPs for counting and dispatch, and the ERP master-data key that will identify each asset.
- 3Survey visit (1–2 days per site) RF noise measurement, materials and layout survey, read-point photographs, cable and power route check, and an interference log.
- 4Bench and on-site tag trials (3–5 days) Tag models per asset family tested on real items, at real orientations, with recorded read distances and failures.
- 5Criteria workshop (half a day) Agree targets, sample sizes, counting method, exception handling and the exit criteria — signed by the decision owner before installation.
- 6POC installation (2–4 days) Temporary reader, antennas, edge filtering, local database and dashboard, plus the single integration path to a test system.
- 7POC run (2–6 weeks) Real operations, daily exception log, agreed ground-truth counting days, and weekly result reviews with the operations team.
- 8Report and decision gate (1 week) Measured results per criterion, root cause for each miss, rollout design, five-year cost model, and a scale / redesign / stop recommendation.
Security & deployment
POC equipment is treated as temporary infrastructure on the operational network and is approved accordingly: a dedicated VLAN or isolated switch, no inbound internet access, and a named owner for removal at the end. Raw read data can reveal stock levels, shipment patterns and asset locations, so it stays on site, is retained only for the duration of the POC plus an agreed analysis period, and is handed over or destroyed on request. The integration path points at a test instance with a least-privilege service account, never at production. On government and defence sites the POC laptop, database and dashboard run air-gapped, and results leave as a signed PDF report.
Limitations & prerequisites
- A survey and POC reduce risk; they do not eliminate it. Conditions change with season, stock mix and process changes, and the rollout should re-verify a sample of read points.
- Results from one read point do not transfer automatically to a different door, material or forklift; representative points must be chosen deliberately, including the worst case.
- A POC cannot prove throughput at full scale — reader density, network load and ERP interface volume behave differently with hundreds of read points.
- Read-rate figures are only meaningful with a counted ground truth; automated self-comparison measures the system against itself.
- Short POCs miss rare failure modes such as tag damage over months, adhesive failure in summer heat, or seasonal stock that behaves differently.
- Tag pricing and lead times quoted during a POC change; the five-year model should be revalidated at tender.
- If master data is inconsistent (duplicate or missing asset numbers), the POC will measure that problem rather than the RFID system — data cleaning has to come first.
Survey only vs POC vs pilot vs full rollout
Each stage answers a different question and costs an order of magnitude more than the previous one. Skipping a stage transfers its risk into the next.
| Stage | Question it answers | Typical duration | What it cannot tell you |
|---|---|---|---|
| Desk study | Is RFID plausible for these assets and processes? | 2–5 days | Anything about your actual RF environment |
| Site survey | What is the environment, and which tags and read points are feasible? | 1–2 weeks | Whether the process and people will work with it |
| Proof of concept | Does one read point meet numeric criteria on real operations? | 2–6 weeks | Behaviour at scale, seasonal variation, full integration load |
| Pilot | Does one complete area work end to end with the ERP and real users? | 2–3 months | Cross-site variation and long-term tag durability |
| Full rollout | Does the whole site perform to the agreed service level? | 3–12 months | n/a — this is the operational system |
For most organisations the honest minimum before a large purchase is survey plus POC; a pilot is added when the process change, not the radio, is the main risk.
FAQ
For a well-designed gate with suitable tags, 98–99.5 % per item is a normal target; for a handheld cycle count in an office environment, 97–99 % is realistic; for liquids and dense metal, targets must be set after the tag trial and may be lower with a defined manual exception process. Any target should specify the asset family, the read point and how it will be counted.
Enough that a single miss does not move the number by more than the tolerance. In practice we count a minimum of several hundred items per asset family per read point, spread across at least five operating days and different shifts, and we count every item on the agreed sample days rather than sampling within a shipment.
Two weeks is the minimum to see normal operational variation; four to six weeks is typical where shipment patterns or shift behaviour vary. Longer POCs rarely add information — if the answer is not clear after six weeks, the criteria were not specific enough.
Full ERP integration across all document types, mobile apps, dashboards, printing infrastructure and change management. Prove one integration path deeply, and leave breadth for the project. A POC that includes everything is a rollout with a smaller budget.
Number of sites and read points, number of asset families to trial, whether temporary cabling and permits are needed, POC duration, and how much integration is included. The cost is usually a small fraction of the tag spend it protects.
Yes, and normally it should. The reader, edge filtering, database and dashboard run on a local machine on an isolated network segment; the report is the only artefact that leaves the site.
An asset or SKU list with materials and quantities, a site plan with the candidate read points, current process documentation for the steps being tested, the ERP identifier for each asset, and access to a test instance of the receiving system.
The report states which criterion failed, the measured cause (tag, antenna placement, material, process or master data) and whether a redesign is likely to fix it. Sometimes the recommendation is a different technology at that point — a handheld process, a barcode verification step or BLE zoning — and that outcome still saves the budget it was meant to protect.
The measurements, logs, configuration and report are yours. POC hardware is either rented for the trial or purchased and reused in the rollout; that choice is made at kick-off so there is no surprise at the end.
Prove it on your site before you buy 20,000 tags
Send a site plan, the asset or SKU list and the read points you have in mind. We reply with a survey plan, the tags we would trial, the success criteria we would propose, and what the POC would cost and prove.
Request a Site SurveyRFID Asset Management System
Swedish Technology supplies the complete RFID stack — UHF tags, handheld and fixed readers, gates, antennas, printers and the asset management platform — with the integration and RF engineering behind it.
Request RFID Solution PricingSources & evidence
- GS1 — EPC UHF Gen2 air interface protocol — the air interface behaviour a survey is measuring
- GS1 — RFID / EPC standards overview
- ETSI — EN 302 208 (UHF RFID equipment, 865–868 MHz) — the European allocation followed in the UAE
- TDRA (UAE) — Telecommunications and Digital Government Regulatory Authority — national spectrum and equipment approval rules
- GS1 — EPC Tag Data Standard — identifier encoding used during tag trials
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.