Recording exactly where beacons are placed, how they are fixed, and what was observed during installation is the difference between a system that can be maintained and one that degrades silently. This guide covers what to document, how to photograph and map installations, what as-built records should contain, and what a handover checklist needs to include.
How to Document a Beacon Installation
Every beacon in a deployment should have a corresponding record created at the point of installation, not afterwards from memory. The minimum fields per beacon are:
- Hardware identifier (the MAC address or manufacturer-assigned ID printed on the unit)
- Configured broadcast identifiers (UUID, major, minor, or EID, as applicable)
- Firmware version at time of install
- Battery type and install date (for estimating replacement schedules)
- Precise location description (floor, room, surface, height, and relation to fixed features such as door frames or columns)
- Mounting method (adhesive pad, cable tie, magnetic mount, screw fix)
- Calibration notes (measured RSSI at one metre, any adjustments made to the transmit power or advertised interval)
- Installer name and date
- Any deviations from the planned position and the reason
A common mistake is to rely on a spreadsheet that is only updated at the end of the day. If a beacon is moved during installation because a surface proved unsuitable, that change needs to be logged immediately or it will be forgotten. Some teams use a mobile form tied to the asset register so that each record is timestamped and geotagged on submission.
Documentation also needs to capture the environment as found. Note the presence of metal cladding, reinforced concrete, mirrored surfaces, or heavy racking near the beacon. These observations become essential later when troubleshooting unexpected signal behaviour.
Installation Standards and Best Practices
Manufacturer documentation should always be the first reference for mounting guidance, but several practical principles apply across most deployments.
Mounting height and orientation
Beacons are typically mounted between 2.0 and 3.0 metres above floor level in retail and museum environments. This places them above most obstructions and out of easy reach, while still allowing the signal to reach handheld devices. Ceiling-mounted beacons should have the antenna facing downward. Wall-mounted units should be oriented so the broadcast pattern covers the intended zone rather than being absorbed by the wall behind them.
Surface and fixing choices
Metal surfaces directly behind or adjacent to a beacon will attenuate and distort the signal. If a beacon must be mounted on a metal fixture, a non-conductive spacer of at least a few centimetres is advisable, though the exact distance depends on the beacon's antenna design and the manufacturer's guidance. Plasterboard, timber, and glass are generally unproblematic.
Fixing methods should match the surface and the expected lifespan of the deployment. Adhesive pads are quick but may fail in hot environments or on surfaces with residual dust. Cable ties work well on racking and suspended ceiling grids. Screw fixes are the most secure but require permission from the venue and leave visible marks on removal. Magnetic mounts are convenient for temporary event deployments but are unsuitable where strong vibrations or ferrous interference exist.
Spacing and overlap
Beacons in the same zone should be spaced far enough apart that their signals create distinguishable RSSI gradients rather than a uniform wash. If two beacons with identical transmit power are placed within a metre of each other, a receiving device may struggle to determine which is closer. The exact spacing depends on the required zone geometry and the environment's attenuation characteristics, which is why on-site measurement matters more than any rule of thumb.
Environmental considerations
Check the beacon's IP rating against the installation environment. A unit rated IP54 may tolerate light dust and occasional splashes but will fail if subjected to regular pressure washing or prolonged humidity. Temperature extremes also affect battery chemistry; a beacon rated for operation down to minus 10 degrees Celsius may see significantly reduced battery life if installed in a cold store, even if it continues to broadcast.
Photographing and Mapping Installed Beacons
Photographs serve two purposes: they prove the installation was completed as specified, and they allow a maintenance team to locate and identify a beacon without a site walk with the original installer.
For each beacon, take at least two photographs. The first should be a wide shot showing the beacon in its surroundings, ideally with a recognisable feature such as a doorway, signage, or structural column visible. The second should be a close-up clear enough to read the label or printed identifier on the beacon housing. If the identifier is not legible in a photograph, note this and ensure the record links the photo to the correct beacon by other means.
Photograph naming conventions should follow the beacon identifier rather than generic camera filenames. A format such as MAC-address_context_wide.jpg and MAC-address_context_close.jpg allows records to be matched quickly.
Mapping involves annotating a floor plan with the position of each beacon. The level of precision depends on the use case. For proximity marketing zones, marking the approximate position on a room-level plan is usually sufficient. For indoor navigation, beacon positions may need to be recorded to within a metre and tied to coordinate systems used by the mapping platform. In either case, the map should use the same identifiers as the installation records and photographs so that all three references can be cross-checked.
A practical mistake is annotating a plan that is later superseded by a revised layout without carrying the beacon positions forward. Treat the annotated floor plan as a versioned document, not a one-time output.
As-Built Documentation
As-built documentation records what was actually installed, as opposed to what was planned. In beacon deployments, the two frequently diverge. A wall may turn out to be thicker than expected, a planned mounting point may clash with a fire sensor, or a zone may need an extra beacon because RSSI measurements showed a dead spot.
The as-built record should include:
- The final floor plan with all beacon positions marked, including any additions or moves from the original plan
- A table reconciling planned versus actual positions, with reasons for each deviation
- RSSI measurements taken at defined test points within each zone, recorded at the time of installation
- Any firmware or configuration changes made on-site that differ from the pre-staging configuration
- Notes on signal behaviour that was unexpected, such as reflections from a glass partition or interference from a nearby Wi-Fi access point
- Confirmation of which beacons were not installed and why (for example, hardware fault, access restriction, or redundancy)
This record is the baseline against which future performance is measured. If a zone that calibrated correctly at install begins showing erratic behaviour six months later, the as-built data provides the reference point for comparison. Without it, the team has no way to determine whether the environment has changed, a beacon has drifted, or the original calibration was marginal.
Handover Checklists
When an installation is completed by an integrator or internal project team and passed to the operational staff who will run it day to day, the handover needs to cover more than the hardware. A structured checklist prevents assumptions from becoming gaps.
The handover should include:
- Hardware inventory: A complete list of installed beacons, spare units held on site, and any units returned as faulty, with serial or MAC identifiers matching the asset register
- Documentation package: As-built floor plans, installation records, photographs, and calibration data in a format the operations team can access without special software
- Access credentials: Login details for the beacon management platform, any on-premises gateways or servers, and the process for granting or revoking access as staff change
- Supplier and support contacts: Who to contact for hardware warranty claims, platform support, and any maintenance contracts, with contract reference numbers and response-time expectations
- Known issues and deviations: Anything that did not go to plan, zones where accuracy is known to be marginal, and beacons that may need early attention
- Operational procedures: How to check system status, what to do if a beacon goes offline, and the escalation path for persistent problems
- Training confirmation: Evidence that operational staff have been shown how to use the management platform, interpret status dashboards, and perform basic tasks such as updating broadcast payloads
Both the handing-over party and the receiving party should sign or otherwise formally acknowledge the checklist. This is not bureaucratic overhead; it creates a clear moment at which responsibility transfers and ensures that open questions are raised before the installation team leaves the site.
A frequent failure point is handing over the hardware and platform access but not the contextual knowledge. The operations team may know how to log in but not why a particular beacon was placed two metres from its planned position, or why one zone uses a lower transmit power than the others. That context lives in the installation records and as-built documentation, which is why the checklist must explicitly reference those materials rather than assuming they will be found.
