A robot pilot intervention log should explain what a person had to do, when they did it, and whether that work was a planned handoff or an exception. A task success percentage alone cannot answer how much human time the workflow used. Keep interventions and completed task outcomes in separate fields.
Download the intervention log worksheet. It contains an original six-cycle example plus a blank record. The figures are synthetic planning data, not OpenDroids performance observations. Use them to understand the accounting before collecting approved measurements in your own pilot.
Define the cycle before recording exceptions
Write a start condition, an end condition and a task boundary for each attempted cycle. Name the manual comparison task. A robot transporting an item to a handoff point is not the same task as a person transporting, unloading and returning it unless those steps are included explicitly.
Decide which planned actions remain human work. Loading, unloading or confirming a destination may be part of a normal successful cycle. Record their time even when the robot completes its assigned movement. Calling all planned work an intervention can exaggerate the exception rate; excluding it from human time can exaggerate savings.
Use the acceptance test template to establish pass conditions and the site survey to identify routes and constraints. This log supports measurement; it does not establish operating safety or certify a deployment.
Keep three human-time categories distinct
Planned handoff time is human work in a successful cycle. Manual fallback is the original task performed by a person after an unsuccessful attempt. Extra recovery is additional human work caused by the exception, such as safely resetting the workflow under the pilot's approved procedure.
Those categories can happen in different orders. Record elapsed observations rather than inventing a fixed sequence. If two workers act simultaneously, specify whether you are measuring elapsed workflow time or the sum of their active labor minutes. Do not switch between those measures inside a comparison.
Leave an unmeasured interval marked unknown. A blank timer field does not mean no work occurred. Record why timing was unavailable and whether that cycle belongs in the current calculation.
Reconcile the six-cycle example
The synthetic comparison assumes a two-minute manual task. Four attempts succeed and each needs 0.5 human handoff minutes. Two attempts fail; each requires the original two-minute manual task plus two extra recovery minutes. The robot's own elapsed time is outside this human-time example.
- Manual comparison for all six tasks: 6 × 2 = 12 human minutes.
- Successful-cycle handoffs: 4 × 0.5 = 2 human minutes.
- Failed-cycle fallback: 2 × 2 = 4 human minutes.
- Extra recovery: 2 × 2 = 4 human minutes.
- Human time during the pilot: 2 + 4 + 4 = 10 minutes.
- Difference from the manual comparison: 12 − 10 = 2 minutes saved in this example.
The task success rate is 4 ÷ 6, or approximately 66.67%. The failure-associated recovery occurs on two cycles, but planned handoff work also occurs on all four successes. Reporting “two interventions” without the category definitions would hide part of the workload.
Translate observations into the planning calculator
The robot pilot time calculator uses these same categories. Enter six attempts, two manual minutes, the success rate as 4/6 expressed in percent, 0.5 handoff minutes and two recovery minutes. A rounded percentage can produce a small rounding difference; the cycle-level record is the reconciliation reference.
If failed attempts have different recovery times, calculate the average only over the failed cycles included in the model and retain the individual records. A zero-failure sample does not measure recovery time. Leave that parameter explicitly assumed until an applicable observation exists.
The calculator omits queueing, robot throughput, simultaneous tasks and costs. A positive human-time result does not establish a faster service, a financial return or an ability to reduce staffing. Review the total cost worksheet separately.
Review exceptions without hiding the hard cases
Give each exception a descriptive category and an observed outcome. Keep aborted attempts and excluded observations visible. Explain exclusions, including a test that stopped under the approved safety process; do not silently delete it to improve a success percentage.
Compare pilots only when their cycle definitions, task mix, measurement basis and observation periods are sufficiently alike. Peak service, different loads and changed staffing can alter the result. The log helps expose those differences instead of assigning a universal target.
Sources and next action
Prepared by OpenDroids as an original human-time accounting example, checked October 6, 2026. No customer or product performance data is represented. Review category definitions whenever the workflow changes. Use anonymous cycle identifiers and follow the site's approved recording rules.
Sirius deployment research discusses human intervention in robot deployment; it does not validate this example or predict OpenDroids performance. Bring your task boundary and reviewed measurements to OpenDroids when discussing an appropriate pilot.
Prepared with AI assistance using the current public product and linked references. Practical checklists and illustrative examples are original planning aids. They do not establish product guarantees or replace a situation-specific review.