Who Will Maintain Your RTLS After Installation? An Operations Handover Checklist

An RTLS maintenance checklist should identify the people, records and tested procedures needed to keep location information useful after the installation team leaves. Start with ownership of device configuration, tag assignment, power, network services and the consuming application. A working demonstration becomes an operating service only when those responsibilities have a clear home.

The handover pack below is a proposed operational framework. It does not imply that every maintenance service, replacement procedure or software feature is included with a GrowSpace kit or site contract.

Walk through the first ordinary change

Imagine a hypothetical site where an asset tag is damaged after the pilot. A spare is available, but nobody knows who may replace it, which configuration to restore or how to preserve the asset’s identity in the application. The hardware problem may be simple; the missing ownership makes recovery difficult.

Use an ordinary replacement as a handover exercise. Ask the receiving team to explain how it would identify the affected device, obtain an approved spare, apply the correct configuration, validate the result and close the record. A procedure that only the installer can interpret needs more work before acceptance.

Build a device inventory that supports action

A device inventory should do more than list a purchase quantity. Use stable identifiers and connect each device to its operating role.

Store credentials in the approved secret-management location, not in the general inventory. Where an exported configuration contains secrets, apply the required access controls before including it in a support or handover package.

Assign routine work to named owners

“IT will maintain it” is incomplete when an operations team moves assets, a contractor changes device settings and an application team controls the screen. Give each task a named owner and a substitute or escalation path.

• Operations: Identify missing, moved or damaged devices and report workflow failures
• Device owner: Maintain configuration records and approve compatible replacements
• Asset-data owner: Verify tag-to-asset assignments and close retired assignments
• IT/OT owner: Maintain the approved network and server services within scope
• Application owner: Maintain parsing, business rules, storage and visible stale-data behavior
• Supplier or integrator: Perform the specific support activities agreed in the contract

These roles can be combined, but the duties should remain visible. Also record who may approve a change and who confirms that the service still meets the operational need afterward.

Match power and maintenance instructions to the model

The Q1 guide separates device setup and device-specific documentation. Use the applicable current instructions for the tag, anchor, Listener or Gateway being operated. Product references were checked on 6 October 2026; confirm the instructions against the actual model and firmware at handover.

Request documented power, charging, replacement and handling requirements where they apply. Do not create a battery schedule from a generic RTLS estimate or assume that every tag has the same power arrangement. Record the observed service need and the manufacturer’s requirements, then assign the recurring checks accordingly.

Similarly, identify which inspections or configuration checks are required after a device is moved, replaced or exposed to a changed environment. Avoid treating a general recommendation as a universal calibration interval.

Keep physical and software changes connected

A warehouse layout change, new metal storage, moved equipment or a changed operating area may affect whether the original acceptance evidence still applies. The change process should ask whether the location deployment needs review, even if no RTLS device has visibly failed.

For a software change, preserve the data-contract version, application release and acceptance results. A parser update can make a healthy device stream unusable without any physical fault.

Use a short change record:

1. What changed, why and who approved it
2. Which devices, areas or application functions are affected
3. The prior and proposed baseline
4. The authorized verification steps
5. The result and any remaining limitation
6. The recovery route if the change is unsuccessful

Keep detailed no-data fault isolation in the support procedure. The handover document should tell the operator when and where to escalate, without becoming an unmaintainable copy of every troubleshooting guide.

Rehearse recovery in a controlled environment

Agree a small set of handover demonstrations appropriate to the system. Examples include replacing a spare tag, restoring an approved configuration and recovering a consuming application after a controlled restart.

For each demonstration, record the expected outcome, authorized participants, observation and evidence. Confirm the business view as well as the device state. A tag that reports again may still be assigned to the wrong asset.

Do not assume automatic backup, gateway buffering, complete historical replay or failover. These are capabilities to verify if the operating requirement depends on them. If a gap in historical data remains, record it rather than describing live recovery as full data restoration.

Close the handover with a service boundary

Before acceptance, the receiving team should be able to locate the inventory, interpret the configuration baseline, identify the responsible owners and reproduce the agreed routine procedures.

The contract should make the support boundary understandable: service hours, included activities, replacement handling, remote or site assistance and any exclusions that matter to the environment. Do not assume that a hardware warranty covers application maintenance, network administration or every industrial operating condition.

Planning an RTLS rollout? Define the operating and support scope with GrowSpace. Bring the proposed owner list, operating schedule, maintenance constraints and the handover demonstrations your team needs to accept the system.