Once a beacon deployment moves beyond a handful of units in a single room, keeping track of every device becomes an operational task in its own right. Beacons look identical, share the same casing, and broadcast silently. Without a structured approach to inventory and asset management, you will eventually face mismatched records, untraceable hardware, and deployments where nobody can confidently say which beacon is mounted where or whether it is still functioning.
This guide covers the practical mechanics of labelling, registering, tracking, auditing and decommissioning beacons. It assumes you are dealing with real hardware in physical spaces rather than theoretical fleet sizes.
Define responsibilities and service levels
Physical labelling is the first line of defence against confusion. Most beacons ship with a factory-printed MAC address on the casing, but that identifier is rarely the one your platform uses day to day. You need a label that ties the physical device to your own records.
What to put on the label
A practical beacon label should include a short human-readable asset code, the last four characters of the MAC address for cross-reference, and the date of initial deployment. If you use QR codes or barcodes for scanning during audits, print them at a size that remains legible when the beacon is mounted above head height or under shelving.
Label placement
Position the label so it does not cover the antenna area, which on most puck-shaped beacons is the broad face. Placing a metallic or densely printed sticker directly over the radiating surface can attenuate the signal. The side or rear of the casing is usually safe. For beacons mounted inside enclosures or behind panels, make sure the label remains visible without dismantling the fitting, or note the enclosure ID on the label instead.
Common labelling mistakes
- Using paper stickers in humid or high-traffic environments where they degrade within months.
- Writing identifiers in marker pen that fades or rubs off during cleaning.
- Labelling beacons before deciding on a naming convention, then having to relabel the entire batch.
- Omitting the MAC address and later discovering two beacons with the same asset code but different firmware versions.
Resolve the naming convention before applying any labels. Even a simple structure such as SITE-FLOOR-ZONE-SEQUENCE (for example, LON-01-ENT-003) prevents ambiguity when devices move between locations.
How to Create a Beacon Asset Register
The asset register is the single source of truth that connects each physical beacon to its configuration, location and maintenance history. It does not need to be elaborate, but it does need to be complete and consistently maintained.
Essential fields
At minimum, each record should capture:
- Asset code: The human-readable identifier from the physical label.
- MAC address: The factory-assigned hardware address.
- UUID, Major and Minor: The identifiers your platform actually uses to trigger content or zone logic.
- Hardware model and firmware version: Critical when troubleshooting inconsistent behaviour or planning updates.
- Battery type and expected interval: Note the cell specification and the configured advertising interval, since both affect replacement timing. (Detailed battery calculations are covered in the battery life and power management guide.)
- Installed location: Site, floor, zone and a brief description such as "north entrance, left door frame, 2.1 m".
- Install date and installing engineer: Useful when tracing faults back to a specific batch or contractor.
- Last audit date and result: Whether the beacon was confirmed present, broadcasting and correctly mounted.
- Status: Active, under maintenance, spare, decommissioned.
Format and access
A well-structured spreadsheet is sufficient for deployments up to a few hundred beacons. Beyond that, or across multiple sites, a dedicated asset management system or a custom database with controlled access becomes more practical. Whatever the format, restrict write access to the team responsible for deployments and audits. Read-only access for venue managers prevents accidental edits while still letting them check which device is mounted at a given location.
Keeping the register current
The register degrades quickly if updates are treated as optional. Build register updates into the deployment workflow: a beacon cannot be marked as installed until its record shows the location, and a beacon cannot be moved without updating the record first. When an integrator hands over a completed deployment, the asset register should be part of the acceptance criteria, not an afterthought.
Tracking Beacon Locations Across Sites
Organisations running beacons across multiple venues face an added layer of complexity. A beacon removed from a London retail unit for maintenance might end up in a Manchester store by mistake, broadcasting the wrong UUID in the wrong zone.
Site-level naming and segregation
Embed the site identifier into both the asset code and the UUID structure where your platform allows it. If your platform uses a single UUID across all sites with Major and Minor values distinguishing zones, ensure your register clearly maps each Major value to a specific site. When a beacon physically moves between sites, its UUID configuration must change to match, and the register must reflect both the old and new assignments.
Transit and spare pool management
Beacons in transit or held as spares should have a distinct status in the register. "In transit to SITE-X" or "Spare pool — warehouse" prevents a situation where an active zone shows a beacon in the register but the physical device is sitting in a drawer at another location. If you hold a central spare pool, assign temporary asset codes or clearly flag them so they are not confused with deployed units.
Reconciliation after events
Temporary deployments at events or pop-ups are particularly prone to drift. After each event, reconcile the number of beacons returned against the number issued. Any discrepancy should be investigated immediately, not left until the next event. A simple sign-out sheet paired with the asset register provides a basic audit trail without requiring additional software.
Inventory Audits for Large Deployments
Without regular audits, the asset register gradually becomes fiction. Beacons get moved by cleaning staff, knocked loose by equipment, or removed during refurbishment without anyone updating the records. An audit is the process of forcing the register back into alignment with reality.
Audit frequency
For a stable retail or museum environment, a full physical audit every six to twelve months is a reasonable starting point. High-traffic venues with frequent fixture changes may need quarterly checks. Temporary event deployments should be audited at setup and teardown at minimum.
What to check during an audit
- Physical presence: Is the beacon actually there? Check the location described in the register.
- Mounting integrity: Is the beacon secure, or is it hanging loose, rotated, or shifted from its intended position?
- Broadcast verification: Use a scanning app to confirm the beacon is transmitting the correct UUID, Major and Minor at the expected power level.
- Label condition: Is the label still legible? If not, plan a relabel during the next maintenance window.
- Environmental damage: Look for moisture ingress, casing cracks, or tamper evidence that suggests the beacon has been interfered with.
Audit methods
For small deployments, a printed floor plan with beacon positions marked and a clipboard is perfectly adequate. For larger sites, a mobile app that reads each beacon and compares the observed identifiers against the register can significantly speed up the process. Some platforms offer audit modes that flag beacons detected outside their registered zone, which helps catch devices that have been moved without authorisation.
Handling discrepancies
When the audit reveals a mismatch, document it immediately. If a beacon is missing, note the last known audit date and check whether any recent maintenance or construction work might explain its removal. If a beacon is broadcasting the wrong identifiers, it may have been reconfigured for testing and not reverted. Resist the temptation to fix issues on the spot during a large audit; note them, complete the audit, then schedule corrections in a dedicated maintenance pass.
Decommissioning and Reassigning Beacons
Beacons are removed from service for several reasons: end of useful life, a change in technology or platform, venue closure, or simply a reduction in zone coverage. How you handle decommissioning affects both operational clarity and data integrity.
Updating the register
When a beacon is permanently removed, change its status to decommissioned and record the date and reason. Do not delete the record. Deleted records create gaps that make future audits harder to interpret — if an auditor finds a beacon ID in an old floor plan but no record of what happened to it, they have no way to determine whether it was decommissioned, lost or simply never existed.
Reconfiguration before reassignment
If a beacon is being moved to a new zone or site, reconfigure its broadcasting identifiers before installation, not after. A beacon carrying the old UUID into a new location will trigger incorrect content or analytics until someone notices. After reconfiguration, verify the broadcast with a scanner before mounting, then update the register with the new location and identifiers in a single step.
Disposal and WEEE compliance
Beacons contain batteries and circuit boards that fall under the Waste Electrical and Electronic Equipment regulations in the UK. Do not dispose of them in general waste. Remove the battery where possible and route the electronics through your organisation's WEEE-compliant disposal channel. If you are working with an integrator, include disposal of replaced beacons in the contract terms so it does not become an unplanned operational burden for your facilities team.
Security considerations
Before disposing of a beacon, consider whether its identifiers pose any residual risk. In most proximity deployments, the UUID and Major/Minor values are not secret — they are broadcast openly — but if your system uses them as part of an access-control or authentication logic, ensure that decommissioned identifiers are removed from the relevant allowlists. For beacons that have been used in security-sensitive applications, physical destruction of the circuit board is a prudent extra step beyond standard WEEE disposal.
Effective beacon inventory management is unglamorous but essential. The organisations that do it well are not the ones with the most sophisticated software — they are the ones that treat the asset register as a living document, build audit steps into their routine, and refuse to let "we'll update it later" become the default response to a moved or missing device.
