Robot Trip Logs: What a Pilot Report Should Prove

What should a robot pilot log prove?

A pilot report earns its place only when it gives leadership something to decide on. The log underneath it needs five kinds of record: timestamps for every run, a count of completed tasks, each exception, every staff touch, and the idle time between runs. Without those fields, a pilot is a set of impressions.

The difference between a demonstration and evidence is usually in the detail. A robot that ran for eight hours tells you little until you know how much floor it covered, what stopped it, and what a person had to do to keep it moving.

This guide covers what each field should hold, how to count it without flattering the robot, and how to reduce a few weeks of records into a report a busy executive will read to the end.

Why market growth cannot replace your own log

Industry figures help set context. According to IFR, professional cleaning robots were the third largest professional service robot category in its 2024 data, with sales up 34 percent to more than 25,000 units, and floor cleaning was the main use. Transport and logistics robots sold 14 percent more units in the same year.

IFR also says its figures come from a sample of 294 service robot suppliers and are not projected to the whole industry. That makes the numbers useful for a board deck on the trend, but they say nothing about how one unit behaves on your floor, under your staffing and your traffic. Only your own log answers that.

Timestamps and run records: the skeleton of the log

Start with a run record for each cycle: start time, end time, zone or route identifier, the map version in use, and the reason the run ended. Pull timestamps from the robot's own system where possible, and state the time zone, so the night shift and the morning review line up.

Keep the record at run level, not only as daily totals. A daily total of six hours can hide one clean run or four short runs broken by stops, and those two situations call for very different decisions. A run that ends with no recorded reason is an open question, and the report should list it as one.

Completed tasks, counted as work actually finished

Count finished work, not attempted runs. A pass that stopped halfway through a zone is partial, and the report should say so. Express completed area or zones in the unit your site already uses, and compare it with the zones planned for each shift.

The question a pilot must answer is simple: of the work we asked the robot to do, how much did it finish without someone stepping in? Report that as a ratio with the denominator written out, such as zones finished over zones assigned. A ratio with no denominator invites argument, and an argument over a pilot tends to end in a vague extension.

Exceptions: what stopped the robot and who cleared it

Each exception needs four fields: time, category, what the robot did, and who cleared it and how long that took. Categories might include a blocked path, a sensor fault, low battery, a door or elevator unavailable, or a spill that stopped the route. Keep the list short enough that every shift uses it the same way.

Time to clear matters as much as how often an exception occurs. A stop cleared in two minutes at 2 a.m. is a different problem from one that waits until a technician arrives in the morning. At Service Robot Co., exception records like these feed RoboCare, the service plan that covers every unit we deploy, so our regional service engineers arrive with the detail they need.

Staff touches and the hours they quietly consume

A staff touch is any time a person handles the robot or its environment on its behalf: refilling a tank, clearing a cable, moving a cart from a lane, resetting after a stop, or plugging in a charger. Log each one with time, reason and duration. Ten touches of thirty seconds each look trivial until they add up across a month of night shifts.

Leadership watches this number because a robot that needs constant rescue becomes a labor line in disguise. Measure staff touch time against the hours the robot was meant to replace, not against zero. A pilot that saves crew hours on paper but consumes the supervisor's evenings has not proven much.

Idle time, uptime and definitions that do not match

Idle time is the period a robot was available but not working: charging, waiting at a door, or parked after a fault. Log it apart from downtime, which is time the robot could not work at all. The two tell different stories, and a pilot report that merges them hides where the time went.

Vendor figures show how loosely these terms get used. Tennant and Domus described an Ottawa shopping centre case using the Tennant X6 ROVR, reporting about 20 hours a week of autonomous cleaning, some weeks above 30, and 99.2 percent of runtime in autonomous mode. That is an operator case study published by the vendor, and it has not been independently audited.

Other vendor figures follow the same pattern. A VIGGO SC50 pair in a Beijing shopping mall was reported to have passed 20,000 cumulative operating hours, with each unit running more than 12 hours a day and no robot related safety incidents reported. An older Brain OS announcement reported a median daily usage of 2.58 hours across its fleet. Each of these uses its own definition of hours, and no independent uptime study turned up to set a common one. Read them as examples of what a vendor chose to measure.

Turning the log into a one page leadership report

A one page report that leadership will read in full usually carries six parts, in this order:

Put the recommendation near the top and the exception table near the bottom. Every figure should trace back to a log line someone can open. If a number cannot be traced, leave it out, because one untraceable figure can discredit the rest.

• The decision question, stated in one sentence
• The baseline: manual or prior hours for the same zones and shifts
• Completed work as a ratio, with the denominator written out
• Exceptions by category, with the median time to clear each one
• Staff touch time per shift, set against robot working hours
• A recommendation to expand, extend or stop, with the criteria that drove it

Where a lease decision starts

Service Robot Co. is an OEM neutral integrator for US businesses. We choose robots across manufacturers, lease them through financing on a three year lease, deploy and integrate them, and service every unit under RoboCare, backed by regional service engineers in every state we service. The lease is quoted as one fixed payment after a site assessment, so the pilot record can inform that quote.

A pilot does not have to start with a fleet. Many sites begin with one leased unit, run the logging described here for a defined period, and then decide whether to add units on evidence. The same log serves the vendor conversation, the service plan and the board report, which keeps everyone working from one set of facts.