Common Deployment Mistakes
Most proximity deployments that fail or underperform do not fail because of the technology itself. They fail because the organisation treated hardware installation as the finish line rather than one step in an operational process. The pattern is consistent: a retailer, museum or venue orders beacons or prints QR codes, fixes them to surfaces, switches them on and then discovers that signal behaviour does not match the floor plan, that nobody is monitoring battery levels, or that the facilities team removed several units during a routine repaint.
The mistakes that cause the most damage tend to cluster around five areas: skipping the site survey, underestimating maintenance, ignoring internal stakeholders, treating batteries as an afterthought and assuming that a successful pilot automatically scales. Each of these has practical warning signs and, importantly, straightforward mitigations that need to be built into the project plan before any hardware is unboxed.
Skipping the Site Survey
A site survey for a proximity deployment is not a casual walkaround. It is a structured assessment of the physical and radio-frequency environment that will determine where devices can realistically be placed and what performance to expect. Skipping it, or compressing it into a single afternoon visit, is the single most common cause of post-installation disappointment.
What the survey needs to cover
The radio environment matters more than most people assume. Bluetooth Low Energy operates in the 2.4 GHz band, which is shared with Wi-Fi, microwaves, some legacy handsets and a growing number of industrial devices. A survey should identify existing access points, any sources of continuous interference and areas where signal is likely to be attenuated by building materials. Metal racking in a retail stockroom, reinforced concrete lift shafts in a museum and glass-partitioned meeting pods in a conference venue all behave differently.
Physical access is equally important. A beacon placed on a ceiling three metres up may read well during testing, but if the only way to reach it involves a specialist access platform that the venue does not own, every future battery replacement or repositioning becomes a planned maintenance job rather than a five-minute task. The survey should document mounting options, cable routes if powered gateways are involved and any restrictions from building management or heritage conservation officers.
Consequences of skipping it
Without a survey, placement decisions are based on the floor plan rather than the actual environment. The result is typically a pattern of dead zones, overlapping signals that confuse zone logic and beacons mounted in locations that look neat on a diagram but are unreachable in practice. Fixing these problems after installation means paying for a second round of labour, re-calibrating zones and re-testing campaigns — costs that were not in the original budget.
Underestimating Ongoing Maintenance
Proximity hardware is not fit-and-forget. Beacons drift from their configured transmit power over time, NFC tags get scratched or detached, QR codes become obscured by new signage and firmware updates may change broadcast behaviour in ways that break existing zone logic. A deployment that works on day one will not necessarily work on day ninety without active maintenance.
What maintenance actually involves
At a minimum, an operational deployment needs a regular schedule for checking that each device is still broadcasting, that signal strength at key test points has not shifted and that physical mounting is intact. For beacons, this means periodic RSSI readings at reference points and comparison against the baseline recorded during calibration. For NFC and QR, it means visual inspections and functional tests with a range of devices — not just the tester's own phone.
Content maintenance is often overlooked. If a QR code points to a dynamic URL, the destination page still needs to be kept current, the server needs to stay online and the redirect logic needs to be checked after any CMS changes. An NFC tag that opens a stale product page or a removed exhibition piece damages visitor trust more than a broken tag does, because the user has made the effort to tap and received something misleading rather than nothing at all.
Who does the work
One of the most frequent mistakes is assuming that the IT team will absorb proximity maintenance into existing routines. In practice, facilities teams may not have the tools to read BLE signals, and IT teams may not have physical access to ceiling-mounted hardware. The deployment plan needs to name who is responsible, what tools they need, how often they carry out checks and what escalation path they follow when something is wrong. Without that clarity, maintenance simply does not happen.
Deploying Without Stakeholder Buy-In
A proximity project typically touches marketing, IT, facilities, operations and sometimes security or customer service. If the project is driven by one department without briefing the others, the deployment will encounter friction that could have been prevented. The most visible form this takes is hardware being removed or relocated by staff who were not told what the devices were or why they were installed.
Common friction points
Facilities teams may repaint walls and remove mounted QR codes or NFC tags without realising they are part of a live system. Cleaning contractors may move beacons that are fixed with temporary adhesive. Security staff may raise concerns about devices that appear to be unauthorised tracking hardware if they were not briefed. IT departments may block the network ports or cloud services the system relies on if they were not consulted on architecture.
In a museum or heritage venue, conservation staff need to be involved early if any device will be fixed near or on sensitive surfaces. In retail, store managers need to understand why a device has been placed in a particular aisle and what to do if a customer asks about it. In each case, the stakeholder does not need to understand the technical details of BLE broadcasting, but they do need to understand the purpose, the fact that it is an authorised installation and the correct contact if there is a problem.
Practical steps
A short stakeholder brief — not a lengthy technical document — distributed before installation solves most of these problems. It should cover what is being installed, where, why, who owns the project and what to do if a device appears damaged, displaced or suspicious. For larger venues, a walk-through with the facilities or operations lead before the first device goes up is time well spent.
Failing to Plan for Battery Replacement
Battery replacement is often treated as a minor operational detail during procurement and then becomes a significant burden once the deployment is live. The mistake is not failing to recognise that batteries run out — everyone knows that — but failing to translate that knowledge into a concrete replacement plan that accounts for the specific realities of the site.
Why it becomes a problem
Battery life in BLE beacons depends on the advertising interval, transmit power, temperature and the specific battery chemistry used. A beacon configured for frequent broadcasts in a warm environment will deplete its cell faster than the same model set to a longer interval in an air-conditioned space. Because different zones in a venue may use different settings, batteries will not expire in a neat rotation. Some beacons will need replacement months before others, even within the same deployment.
If the deployment was installed without recording which beacon is mounted where, what its configured settings are and when it was activated, the operations team faces a choice between replacing all batteries on a conservative schedule — which wastes money and labour — or waiting for beacons to fail and reacting to gaps in coverage as they appear. Neither approach is efficient.
What a replacement plan needs
An asset register that ties each beacon's identifier to its physical location, configured settings and activation date is the foundation. Without it, battery planning is guesswork. On top of that, the plan needs a predicted replacement window for each device or group of devices, a procurement lead time for replacement cells, a documented access method for each mounting location and a named person responsible for carrying out the work.
For deployments with more than a handful of beacons, staggering the initial installation by a few weeks per zone creates a staggered replacement cycle that spreads the workload. If all beacons are activated on the same day with the same settings, they will all reach end-of-life within a narrow window, creating a spike in maintenance demand that could have been avoided.
