Robot deployment checklist: from site survey to handover

A robot deployment is complete when the organisation can run, supervise, stop, recover and support the agreed workflow—not when the machine first moves. The robot is one part of a system that includes the route or cell, people, tooling, power, network, operating rules, documentation and supplier support.

Use this checklist after you have defined the task with the business robot selection guide. It is a project-control framework, not an application-specific risk assessment or legal sign-off. The exact model manual, supplier instructions and competent site review remain controlling.

Gate 1: approve the deployment brief

Do not schedule delivery until one accountable owner has approved a short brief containing:

• the task in observable terms;
• start and end points of the workflow;
• intended operating hours and frequency;
• objects, loads, people and systems involved;
• acceptable human interventions;
• conditions that count as success, failure or a stop;
• commercial scope: trial, managed hire, RaaS or purchase;
• named project, operational, technical and supplier owners.

Keep optional future tasks outside the acceptance test. They can become a second phase after the first workflow is stable. This prevents a supplier demonstration from expanding into an undefined automation programme.

Gate output: signed deployment brief and change owner.

Gate 2: survey the real site

Walk the route or work area while normal operations are happening. Photograph or draw relevant dimensions without collecting unnecessary personal data. Record:

Physical conditions

• door, aisle, lift and turning dimensions;
• floor, thresholds, slopes, steps, edges and drains;
• workbench or machine geometry;
• lighting, glass, reflective surfaces, dust, moisture and temperature;
• charging, water, drainage or compressed-air points;
• storage, staging and maintenance space;
• emergency routes and access for responders.

Operational conditions

• people, vehicles and equipment sharing the area;
• busy periods, shift changes and temporary obstructions;
• cleaning, deliveries and maintenance that change the route;
• manual doors, lifts, barriers and access-control points;
• noise and interaction constraints;
• supervision and out-of-hours arrangements.

Digital conditions

• Wi-Fi or mobile coverage on the whole route;
• network ownership, segmentation and account approval;
• local functions versus cloud dependencies;
• remote-support access and logging;
• systems, APIs and data fields required by the workflow;
• offline, degraded and recovery behaviour.

Use the survey to reject unsuitable models early. Do not treat a maximum specification as a site approval. The manufacturer’s documentation for the exact model and configuration should be checked beside the survey—for example the Universal Robots documentation library for a UR application or the PUDU manual library for a service robot.

Gate output: marked site plan, issues list and model constraints.

Gate 3: define the complete system

Create a bill of scope, not only a bill of materials. It should identify:

• robot, variant, serial or asset record and controller;
• batteries, charger or dock;
• end effector, trays, payload fixtures or sensors;
• guards, barriers, signs and other controls;
• software versions, licences and administrator accounts;
• integrations, mapping and programmed workflows;
• delivery, lifting, setup and removal responsibilities;
• training, manuals and language requirements;
• spares, consumables and maintenance plan;
• support hours, response path and remote-access terms.

For a purchase, the UK robot buyer’s guide helps expose exclusions in the commercial quote. For temporary use, the UK hire guide covers operator, transport and handover questions.

Gate output: approved configuration and responsibility matrix.

Gate 4: review risks and controls

The organisation controlling the work should arrange a competent, task-specific review. Start with hazards created by the robot, its payload or tool, the environment, foreseeable misuse, maintenance and the interaction with people. Include startup, normal operation, recovery, charging, cleaning and decommissioning.

The Health and Safety Executive’s risk-assessment guidance explains the general identify-assess-control-record-review process. Robotysys does not decide which regulations, standards or conformity route apply to a particular deployment.

Make controls observable. “Staff will be careful” is weak. A defined exclusion zone, speed mode, locked configuration, trained-role permission or physical separation can be inspected. Record who verifies each control and what happens if it is unavailable.

Gate output: site-approved controls, emergency arrangements and unresolved actions.

Gate 5: prove the workflow

Write acceptance tests before commissioning. Each test needs a setup, action, expected result and evidence record.

Include:

• normal task with representative load or interaction;
• route or cycle at a realistic operating time;
• start, pause, stop and restart;
• low battery or service requirement;
• network or integration loss;
• blocked route or unexpected object;
• bad input, dropped item or rejected workpiece where relevant;
• human handover and support escalation;
• safe shutdown and manual recovery;
• data, logs or reports required by the business process.

A product video is not an acceptance test. Neither is a supplier completing the task while the future operator watches. The intended team should demonstrate the parts they will own.

Record configuration changes during testing. A pass on one software version, map, tool or speed does not automatically apply after a change.

Gate output: acceptance record, defect list and go/no-go decision.

Gate 6: train by role

Separate the people who use, supervise, maintain and administer the system. Give each group only the actions and configuration access it needs. Training should cover the actual work, risks, precautions and fault responses, using the manufacturer instructions and site procedure.

HSE’s training and competence guidance for work equipment notes that adequacy depends on the activity, existing competence, circumstances and supervision. Attendance alone does not demonstrate competence. Use an observed task and recovery scenario before authorisation.

Keep a list of authorised roles, trainer, date, configuration and refresher trigger. Changes to equipment, task or system of work may require new instruction or assessment.

Gate output: role matrix, competency record and escalation card.

Gate 7: hand over an operable service

The handover pack should be usable during a fault, not only archived for procurement. Include:

• approved deployment brief and site plan;
• exact configuration and software versions;
• current manuals and supplier contacts;
• daily start and end checks;
• normal operating procedure;
• stop, isolation and recovery procedure;
• charging, cleaning and maintenance instructions;
• known limitations and prohibited uses;
• account ownership and remote-access record;
• incident, fault and change logs;
• acceptance results and open defects;
• review date and owner.

Label temporary controls and unresolved work. Do not call a pilot “business as usual” while a supplier engineer is still compensating for faults that site staff cannot handle.

Gate output: signed handover with named operational owner.

Gate 8: review after real operation

Set an early review after representative cycles. Compare the agreed measures, interventions, safety observations, support demand and staff feedback with the deployment brief. Separate robot faults from route, process, integration and training issues. They lead to different actions.

Use a change process for new routes, payloads, tools, speeds, software or interactions. Re-run the relevant survey, review, test and training gates rather than assuming the original approval covers the change.

The Robotysys pilot scorecard provides a structured scale/change/stop decision. If you want help finding relevant research, share the site, workflow and intended commercial route.