Rollouts rarely stall on the plan. They stall in the gaps between teams: devices that arrive unconfigured, a first shift that loses its morning to enrollment, a failed unit with no agreed return path, a handover that never quite hands over.
Deployment and support is where those gaps get closed in writing. We define staging, enrollment, commissioning, training, handover, spare-pool planning, and the return-material authorization (RMA) path that apply to your project and location.
What gets defined
- staging and enrollment, so devices arrive ready instead of being configured by hand on the floor;
- commissioning and the acceptance criteria the system is signed off against;
- training and handover, so the system ends up with the people who run it;
- spare-pool planning sized to the fleet and the site; and
- the return path for failed units.
Boundaries, stated plainly
Support scope is agreed per project and location. Delivery countries, local partners or depots, and support terms are confirmed during commercial review — written into the proposal, not implied by it.
Where this sits
Deployment draws on the written scope from technical planning, the fleet and lifecycle decisions from equipment supply, and the interface map from systems integration. The full delivery sequence is on Services.
FAQ
Is support included in the deployment?
The support scope is written into your proposal and agreed per project and location. Where support begins and ends is visible before you commit.
What happens to a failed device?
The return path is defined during scoping: the return-material authorization (RMA) route and the spare-pool plan that apply to your site.