Decisions to make before implementation
In a proximity technology deployment, as-built documentation is the definitive record of what was actually installed, where, and how it was configured. It differs from the original design plan because real-world conditions almost always force adjustments: a beam blocks a planned beacon position, a wall turns out to be thicker than the floorplan indicated, or a venue operator requests a zone boundary shifted after seeing the first day of a pilot.
The as-built record captures those deviations. For Bluetooth beacons, this means the physical mounting location of each unit, its assigned identifiers (UUID, major, minor), the configured transmit power and advertising interval, the mounting method used, and any cable routing for mains-powered devices. For NFC tags and QR codes, it records the exact placement height, the surface material, the encoded URL or payload, and the tag type or QR generation parameters. For indoor navigation infrastructure, it ties each beacon or sensor to a specific coordinate on the indoor map and notes the calibrated RSSI values at reference points.
This document serves a practical purpose. When a beacon stops appearing in analytics or a zone triggers at the wrong moment, the operations team needs to know exactly which hardware is at that location, what it should be broadcasting, and how to reach it physically. Without an as-built record, technicians waste time cross-referencing spreadsheets against ceiling plans, or worse, pulling down the wrong unit and breaking a working installation.
As-built documentation is not a project closeout formality. It is the working reference that maintenance staff, integrators returning for adjustments, and new operational managers will rely on long after the installation team has left the site.
Pilot, measure and correct
Retail environments
In a multi-storey retail fit-out, beacons are typically mounted above specific product zones, entrance thresholds and queue areas. The as-built record needs to map each beacon to a zone name that matches the retailer's own store layout terminology, not an abstract label. If the plan called for a beacon at "Zone 3, Bay 7" but the fixture layout changed during shopfitting and the beacon ended up above Bay 9, the as-built document must reflect Bay 9. Linking beacon identifiers to the retailer's planogram references makes future zone reconfiguration far simpler.
Museums and galleries
Museum deployments often involve beacons positioned near exhibits, NFC tags on plinths, and QR codes on interpretation panels. Exhibits move frequently. The as-built record should include not just the current position but the mounting method, because a tag screwed into a plasterboard wall requires a different removal and reinstallation process than one adhered to a glass vitrine. Recording the fastener type and whether any surface protection was used prevents damage when exhibits are repositioned.
Events and temporary venues
For short-duration deployments, the temptation is to skip formal documentation. The problem arises when the same event returns to the same venue the following year, or when a dispute arises about whether a beacon was actually deployed in a sponsored zone. Even a minimal as-built record, a marked-up floorplan with beacon IDs and a photograph reference for each position, provides an evidence base that a verbal agreement cannot.
What belongs in the record
- Unique hardware identifier for each device, matched to its assigned broadcast identifiers
- Physical location described in terms a non-technical staff member can follow, such as "north wall, 2.1 m above finished floor level, third light fitting from the east entrance"
- Mounting method and any fixings used
- Configured transmit power, advertising interval and measured RSSI at one-metre reference (for beacons)
- Encoded URL or payload, tag type and lock status (for NFC and QR)
- Deviation notes explaining any difference between the design plan and the installed reality
- Date of installation and the name of the technician who completed it
The format should suit the people who will actually use it. A PDF floorplan with numbered callouts and a corresponding spreadsheet is common because it works on site without specialist software. A cloud-based mapping tool is preferable for large venues with frequent layout changes, provided the operations team has reliable access and the integrator has confirmed long-term data availability.
Exceptions, follow-up and lifecycle control
Treating the design plan as the installed record
The single most frequent error is filing the original deployment plan as the as-built document without updating it. Plans and reality diverge on almost every project of meaningful scale. If the document does not reflect what is physically on the ceiling or the wall, it is worse than useless because it sends maintenance staff to the wrong location with confidence.
Omitting configuration details
Recording where a beacon is mounted but not what it is broadcasting creates a separate problem. When a zone behaves unexpectedly, the operations team needs to verify both the physical position and the configuration. If the as-built record only covers one of those, diagnosis requires returning to the integrator's project files, which may not be readily accessible.
Using identifiers that only the installer understands
Some integrators label beacons with internal project codes or sequential serial numbers that mean nothing to the venue's operations team. The as-built document should bridge that gap by mapping the installer's hardware ID to a location-based label the venue's staff can use in daily conversation.
Format and access limitations
A detailed as-built record locked in a proprietary platform that requires a paid licence to view is of limited value to a venue that will not maintain that licence after the project closes. Before agreeing on a documentation format, confirm who will have access, for how long, and in what circumstances. If the integrator controls the platform, ask what happens to the data if the commercial relationship ends.
Key verification steps
- Walk a sample of recorded positions and confirm the described location matches what is physically installed
- Check that each beacon's broadcast identifiers, as read by a scanning app, match the as-built record
- Verify that NFC tags resolve to the recorded URL and that QR codes scan correctly
- Confirm that deviation notes exist for every known difference between the plan and the installation
- Ensure the document is stored somewhere the operations team can reach it without contacting the installer
As-built documentation does not need to be elaborate, but it does need to be accurate and accessible. A simple, truthful record of what is actually on site will outperform a comprehensive document that silently ignores the adjustments made during installation.
