The Minimum Installation Record
Bluetooth beacons are small, battery-powered devices that get mounted in ceilings, fixed to walls, tucked behind displays or attached to fixtures. Unlike fixed networking equipment, they are frequently moved during refits, redecorations or seasonal changes, and their batteries need periodic replacement. Without a clear record of where each unit sits, what it transmits and how it was configured, even a modest deployment of twenty or thirty beacons becomes difficult to maintain.
Documentation in this context means a reliable, up-to-date reference that connects each physical beacon to its digital identity and operational settings. The minimum a useful record should capture includes: the beacon's hardware identifier (often printed on the casing or a label), its broadcast identifiers (UUID, major and minor values), the configured transmit power and advertising interval, the exact mounting location described in terms a colleague can follow without guessing, the mounting method used, the date of installation, and the name of the person who installed and calibrated it.
This record serves several practical purposes. When a zone stops triggering notifications, the operations team needs to know which beacon is responsible, where it is physically located and what its expected RSSI values were at the time of calibration. When batteries approach the end of their service life, the team needs a list of which beacons to replace and where to find them. When a gallery is rehung or a retail floor is reconfigured, the record shows which beacons need to be moved, reconfigured or removed rather than leaving orphaned devices broadcasting into empty space.
Documentation is not a one-time task completed at handover. It is a living record that must be updated whenever a beacon is moved, reconfigured, replaced or recalibrated. The value of the record depends entirely on whether it reflects the current state of the deployment.
Photographs, Plans and Configuration Evidence
Matching physical labels to digital records
The most robust approach is to apply a physical label to each beacon that carries a short, human-readable code matching an entry in the digital record. Engraved or printed labels survive longer than handwritten stickers. The code on the label should correspond to a row in a spreadsheet or an entry in an asset management system where the full configuration and location details are stored. If a beacon is found detached from its mount or pulled down during a refit, the label allows anyone on site to identify it and check whether it belongs in that position.
Location descriptions and floor plans
Describing a beacon's position as "near the entrance" is not sufficient. A practical location description might read: "Mounted on the ceiling tile, third tile from the north wall, second tile from the east wall, approximately 2.4 metres above floor level, facing downward." Where floor plans are available, marking each beacon's position on a labelled plan provides a quick visual reference. Photographs taken at the time of installation, showing the beacon in situ with nearby fixtures visible for context, are also useful, though they become outdated as soon as the surrounding environment changes.
Recording configuration and calibration data
Alongside the physical location, the record should note the transmit power level, advertising interval and any calibration measurements taken at installation. If the beacon was calibrated by measuring RSSI at one-metre and five-metre points in the actual environment, those readings should be logged. This allows a future fault investigation to determine whether signal behaviour has changed, which might indicate a hardware issue, a new source of interference or a physical obstruction that was not present at installation.
Use case: retail store reconfiguration
In a retail environment, seasonal changes or brand refreshes frequently involve moving fixtures and repositioning product zones. If the documentation clearly maps each beacon to a zone and a fixture, the operations team can quickly identify which beacons need to be moved, which need their broadcast identifiers updated to match the new zone definitions, and which can remain in place. Without this, beacons are often left attached to old fixtures that end up in storage, still broadcasting and causing phantom zone entries in the analytics.
Use case: museum gallery changeover
Museums regularly rotate exhibits, which can mean moving or removing the beacons associated with particular displays. Documentation that links each beacon to a specific exhibit or gallery section allows the curatorial and operations teams to coordinate. When an exhibit is deinstalled, the corresponding beacon can be removed from the wall, its entry in the record updated to reflect that it is in storage, and its broadcast disabled or its identifiers changed to prevent it from triggering content for a display that no longer exists.
Use case: event teardown
Temporary event deployments present a particular challenge because the infrastructure is assembled and dismantled within a short window. Documentation for an event should include not only where each beacon was placed but also a retrieval checklist to ensure all devices are collected at the end. Beacons left behind in venue ceilings or behind temporary walls are a common and costly loss. A simple count of beacons deployed versus beacons returned, checked against the record, provides a basic verification step.
Keeping Documentation Current
Relying on a single person's memory
A frequent failing in small to mid-size deployments is that one team member knows where everything is. When that person leaves or is unavailable, the rest of the team faces a time-consuming process of physical discovery. Documentation should be written so that someone unfamiliar with the installation can locate any beacon and understand its configuration without assistance.
Failing to update the record after changes
Documentation that was accurate at handover but is never updated is worse than no documentation at all, because it creates false confidence. If a beacon is moved during a refit but the record is not amended, a fault investigation will send someone to the wrong location. The process for updating the record should be as straightforward as possible, ideally a single point of entry that does not require specialist software access.
Omitting firmware and hardware version details
When beacons are replaced under warranty or batteries are swapped, the new unit may run a different firmware version with slightly different broadcast behaviour. Recording the hardware model and firmware version at each update allows the team to identify whether a change in behaviour is linked to a hardware or firmware change rather than an environmental factor.
Not recording the mounting method
Beacons are attached in various ways: adhesive pads, cable ties, magnetic mounts, screws into ceiling tiles or custom brackets. If the record does not note the mounting method, a battery replacement or relocation may take longer than necessary, or the replacement may be attached less securely than the original. It also matters for venues with listed building constraints or specific contractor requirements.
Limitations of photographic records
Photographs are helpful but have clear limitations. Lighting conditions change, fixtures are moved, and a photo taken at installation may bear little resemblance to the same spot six months later. Photos should supplement written descriptions and floor-plan markings, not replace them.
Key checks to verify your documentation
- Traceability: Pick any beacon at random from the physical site and check that you can find its entry in the record using only the label on the device. Then reverse the test: pick an entry in the record and see whether a colleague can walk to the correct beacon without prior knowledge of its location.
- Completeness: Review the record for any beacon entries missing configuration data, calibration readings, install dates or location descriptions. Gaps in the record will cause delays during fault-finding or battery replacement.
- Currency: Compare the total number of beacons shown in the record against a physical count on site. Any discrepancy indicates a beacon that was added, removed or moved without the record being updated.
- Retrievability: Check that the record is stored in a location accessible to the people who will actually need it during operations, not only to the person who created it or the original integrator.
Good documentation does not require complex tools. A well-structured spreadsheet, a labelled floor plan and a consistent labelling convention on the devices themselves will serve most deployments adequately. The critical factor is discipline: updating the record every time a change is made, rather than deferring it until a convenient moment that never arrives.
