Scope, constraints and responsible roles

Handover to operations is the point where responsibility for a live beacon or proximity system passes from the deployment and integration team to the people who will keep it running day to day. In practice, this is rarely a single meeting. It is a staged process that starts before the final beacon is fixed to a wall and only concludes when the operations team can independently monitor battery levels, replace a failed unit, update a campaign and know who to call when something breaks.

Two specialists reviewing a venue floor plan and deployment data
Illustrative example of deployment planning and operational coordination.

The core purpose of handover is to prevent the common situation where a system works perfectly on the day the integrator leaves, then degrades silently because nobody on-site knows how the asset register works, what the alert thresholds mean, or which beacons belong to which zone. A proper handover transfers not just hardware, but the operational knowledge needed to sustain it.

What handover actually transfers

  • Asset register and documentation. A complete record of every beacon, its identifier, firmware version, physical location, mounting method and assigned zone. This should match what is physically installed, not what was planned months earlier.
  • Monitoring access. Login credentials, dashboard URLs and an explanation of what each metric means in the context of this specific site. The operations team needs to know the difference between a beacon that has drifted slightly in RSSI and one that has stopped broadcasting entirely.
  • Maintenance schedule. When batteries are expected to need replacement, how to identify which beacons are approaching that point, and where spares are stored.
  • Escalation paths. Who to contact for hardware faults, platform issues, firmware updates and physical damage. This should distinguish between problems the on-site team can resolve and those that require the integrator or platform provider.
  • Change procedures. How to add a beacon, remove one, reassign a zone or adjust transmit power without breaking the wider system.

Handover is not the same as project closure. Project closure is a contractual milestone. Handover is an operational one, and it is only complete when the receiving team can demonstrate competence, not just receive a folder of documents.

Coordinate technology, people and process

Retail environments

In a retail setting, the operations team is often a store manager or regional facilities contact who has other priorities. Handover here needs to be concise and focused on what they will actually do: check a dashboard once a week, swap batteries when alerted, and report physical damage. Detailed RSSI calibration records are useful for the integrator but unhelpful for a store manager who needs to know whether the system is healthy or not. A traffic-light status view on the monitoring platform, with clear instructions on what to do when a beacon turns amber or red, is more practical than raw data dumps.

The handover should also cover what happens during store refits. Beacons mounted on shelving or ceiling tiles will be affected when fixtures change. The operations team needs a procedure for temporarily removing beacons, keeping track of them, and reinstalling them in the correct positions afterwards.

Museums and heritage venues

Museum operations teams often include a mix of front-of-house staff, IT support and conservation officers. Handover needs to address each group's concerns. Conservation staff will want assurance that mounting methods have not damaged surfaces and that future removal will be clean. IT staff need platform access and firmware update procedures. Front-of-house managers need to know how to spot a failing beacon that is affecting the visitor experience, even if they cannot fix it themselves.

Temporary exhibitions create a recurring handover scenario. When a new exhibition installs, beacons may need to be moved, added or re-zoned. If the original handover did not include clear change procedures, each exhibition becomes an ad-hoc deployment with the same risks as a first install.

Events and temporary venues

For events, handover is compressed. There may be only hours between installation going live and the venue opening to attendees. The operations team in this context is usually the event production crew, who need a rapid briefing: where are the beacons, what do the status lights mean, and who do they phone if one goes offline. Detailed documentation is still important, but the immediate priority is a fault-response plan that works under time pressure.

Post-event, handover includes decommissioning: recovering all beacons, reconciling them against the asset register, and returning them to storage in a known state. Events frequently lose beacons because decommissioning is treated as an afterthought rather than a defined step.

Verifying handover completeness

A practical way to confirm that handover has worked is to ask the operations team to perform a controlled task while the integrator is still available. For example, replace a beacon in a non-critical zone using the documented procedure, check that the monitoring platform reflects the change correctly, and confirm that the zone still triggers the expected behaviour. If the team cannot complete this without asking the integrator for information not in the documentation, the handover is incomplete.

Handover, monitoring and improvement

Common mistakes

  • Handover as a document dump. Passing over a USB drive or shared folder of PDFs and calling it complete. Documentation is necessary but not sufficient. The operations team needs to have read, understood and practised with the material.
  • No baseline recorded. The operations team inherits a system but has no record of what "healthy" looks like. When RSSI values drift or battery reports change, they have no reference point to judge whether the change is normal or a fault.
  • Single point of contact. Handover knowledge resides with one person on the operations side. When that person leaves or is on holiday, the rest of the team cannot manage the system.
  • Ignoring physical access. Documentation describes beacon locations as "above entrance 3" but does not record the height, mounting type, whether a ladder or tower is needed, or whether access is restricted outside trading hours. Battery replacement becomes impractical.
  • No acceptance criteria. The operations team signs off handover without a clear, agreed definition of what "working" means. Disputes arise later about whether a problem is a handover defect or a subsequent operational issue.

Limitations of handover

Handover cannot compensate for a poorly documented installation. If the deployment team did not maintain an accurate asset register during installation, the handover phase is not the time to reconstruct it from memory. The operations team will inherit whatever record exists, and gaps will only surface when something needs fixing.

Handover also cannot transfer experience. An operations team that has never managed a beacon system will take time to become confident, regardless of documentation quality. Planning for a support period after formal handover, where the integrator remains available for queries, is more realistic than expecting immediate full independence.

Platform changes can undermine handover. If the monitoring dashboard is updated, rebranded or replaced shortly after handover, the operations team's training becomes outdated. Handover documentation should reference platform features by function rather than by exact interface layout where possible, and should include a note about checking for platform updates that may affect documented procedures.

Key checks before signing off handover

  • Does the asset register match the physical installation? Spot-check at least a representative sample of beacons across different zones and mounting types.
  • Can the operations team log into the monitoring platform and interpret the status of every beacon without assistance?
  • Is there a clear, tested procedure for battery replacement that includes physical access requirements?
  • Are escalation contacts current, with direct phone numbers or ticketing URLs rather than generic email addresses?
  • Has the operations team successfully completed at least one maintenance task using only the handover documentation?
  • Is there a agreed definition of what constitutes a handover defect versus a subsequent operational issue, and a time window for reporting defects?
  • Are spares, tools and any required mounting hardware stored in a known, accessible location on-site?

Handover is the last point at which deployment problems can be corrected without a formal defect process. Treating it as a box-ticking exercise guarantees that those problems will surface later, when fixing them is more disruptive and more expensive. A thorough handover takes time, but it is the most cost-effective stage of any beacon deployment to get right.