Robot Site Survey Checklist: Workflow, Environment, Network and Safety

A robot site survey should produce evidence for a design and acceptance decision. Photographs of an empty facility and a floor plan are useful inputs, but they do not explain how the route behaves at peak demand, who controls an interface or how a stopped robot can be recovered. Survey the work while it is happening and record the conditions the proposed application must handle.

Use this checklist after defining the task and before committing to a final configuration. It supports an engineering assessment; it does not replace the site’s risk assessment or authorize changes to machinery, electrical systems, networks or emergency routes.

Start with a survey boundary and site owner

Record the task, proposed operating area, included shifts and excluded conditions. Name the person who can authorize observation and the owners of operations, facilities, IT, safety and affected interfaces. Agree which photographs and records may be collected and how sensitive information will be handled.

Give each observation a location identifier and timestamp. Link it to the requirement it informs, the measurement method and any condition that could change it. A doorway measurement without the load orientation or door-open state can be misleading.

The workflow-first robotics assessment provides a broader structure for deciding what the survey needs to answer.

Observe the mission from request to completion

Follow representative work through release, preparation, pickup, travel, waiting, delivery, receipt and return or repositioning. Record queues, exceptions and human coordination. Include periods when the nominal process changes, such as shift handovers or scheduled replenishment.

Ask who performs work that is currently invisible: clearing a path, finding a receiver, opening a door, correcting a load or re-entering a request. If the proposed robot depends on that work continuing, include it in the operating design and cost boundary.

Do not infer demand from the number of trips observed during a quiet survey. Obtain a suitable demand record and identify what the observation period does and does not represent.

Measure the complete route and payload envelope

Record clear widths, turns, thresholds, slopes, floor transitions, surface condition, doors, waiting areas and recovery space. Include the configured robot, payload and required maneuvering envelope. Compare measured conditions with the selected supplier’s application limits; this checklist supplies no universal clearance or slope threshold.

Inspect the payload interface separately. Record mass, dimensions, center-of-gravity information where required, containment, loading orientation and retention method. For a carrier, show the actual lift, tow, fork or fixed-mount interface. A load that fits on a deck is not automatically an accepted payload.

Observe mixed traffic and temporary obstructions. Keep access and egress decisions with the site authority. A route that works only when other users yield informally needs a different operating arrangement or a clearly qualified scope.

Treat building and software interfaces as owned systems

Create an interface register for doors, elevators, access control, machines, dispatch systems and reporting destinations. Record the equipment owner, supplier, supported interface, available documentation, change process and test authority.

For each interface, ask what happens during timeout, unavailable state, duplicate request and recovery. Identify who can reproduce a fault in a controlled environment. Do not assume that an available API or shared protocol completes the integration.

Keep proposed work distinct from approved work. The survey may identify a need for wiring, a door controller or a network change; it does not authorize implementation.

Survey network behavior with the intended application

Ask IT and the robot supplier to define the relevant measurements: coverage, roaming, authentication, latency, loss and application behavior during disruption. Assess the actual travel path, including building transitions and any lift journey. A strong signal indication at one point does not prove a complete mission will communicate reliably.

NIST SP 800-82 Revision 3 frames operational technology security around the physical system’s reliability, performance and safety needs. Use that context to document remote access, accounts, segmentation, update control and logging with the site’s IT owners. Do not present a survey as a cybersecurity certification.

Capture recovery, service and change constraints

Identify safe waiting locations, authorized recovery roles, manual fallback and access for maintenance. Verify that service staff can reach the equipment without disrupting another controlled process. Record charging location, electrical review requirements, cleaning responsibilities and parts storage where relevant.

Observe who owns changes after deployment. A moved cabinet, revised door schedule or new traffic pattern can alter the accepted application. The site needs a way to report and assess those changes, rather than discovering them through repeated mission failures.

Close the survey with decisions and evidence

For each finding, record evidence, affected requirement, consequence, owner and next action. Use categories such as acceptable for design, requires verification, requires site change and outside scope. Do not turn an unmeasured condition into an assumed pass.

Review the findings with operations and technical owners, then feed them into the requirements and pilot plan. Use the deployment checklist to coordinate the remaining work.

Bring the survey record, demand baseline and interface register to a workflow assessment. The output should explain which application can be tested, under what conditions and with which unresolved dependencies.

Explore Warpify's robotics solutions to connect these requirements with workflow assessment and deployment planning.

Sources and scope

• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security — OT security must account for performance, reliability and safety constraints; not site-specific compliance approval.