Robot Field Service Dispatch: First-Time-Fix and the Real Downtime Cost

The Downtime That Dispatch Owns

Total robot downtime decomposes into four intervals, and they are owned by four different parties. Confusing them is why negotiations over service levels stall.

Interval	From → to	Who controls it	Typical order
Detection lag	Fault occurs → fault is known	Telemetry and monitoring design	Minutes
Remote triage	Fault known → diagnosis and dispatch decision	Support desk, access to logs	Minutes to hours
Response and travel	Dispatch → technician on site	Field service network and geography	Hours
Repair time	On site → robot back in service	Parts availability and technician skill	Hours to days

The first two intervals are cheap to compress because they are software and process. The third is geography and is expensive. The fourth is dominated by whether the correct part is in the van.

Most service contracts quote a response time, which covers the third interval only. That is the one interval the customer can least influence and the one that is easiest to meet on paper, because it starts at dispatch, not at fault. A contract that guarantees four-hour response and says nothing about triage lag or first-time-fix allows a robot to sit undispatched for a day and still be perfectly compliant. The measurement boundary matters more than the number quoted.

The practical consequence is that a site should insist on measuring fault-to-restore, not dispatch-to-arrival. Fault-to-restore is the only interval that maps to lost service hours, and it is the only one that aligns the vendor’s incentives with the site’s.

First-Time-Fix Rate and the Second-Visit Penalty

First-time-fix (FTF) rate is the share of service visits that resolve the fault without a return visit for the same cause. It is the most under-reported metric in service robot operations and the most financially consequential.

The penalty is not linear, it is roughly double. A second visit consumes a second response-and-travel interval on top of the first repair, so a fault that would have been a six-hour outage becomes a two-day outage. Worse, the second visit usually happens after the site has re-planned its schedule around the robot’s absence, so the outage length is not the only cost; the re-planning cost lands twice.

Work an indicative example on a fleet of twelve cleaning robots across four sites, each expected to deliver 2,000 productive hours a year:

• Service events per robot per year: 9, giving 108 events across the fleet.
• At an FTF rate of 82 percent, 19 events become repeat visits.
• Average fault-to-restore on a first-visit fix: 7 hours. On a repeat visit: 41 hours, because the second visit lands a day later.
• Lost service hours: (89 × 7) + (19 × 41) = 623 + 779 = 1,402 hours.
• At a delivered-hour value of 22, that is roughly 30,800 in lost service value, of which about 17,100 is attributable to the second visits alone.

Raise FTF from 82 to 94 percent and the repeat-visit count falls from 19 to 6, cutting lost hours by roughly 530 and recovering around 11,700. The hardware did not change. The only thing that changed was whether the technician who arrived had the right part and the right diagnostic information.

That is why FTF belongs in the contract as a measured and credited metric rather than a vendor claim. It is also why the metric must be defined precisely, because there are three ways to inflate it:

• Closing the ticket at departure. A ticket closed when the technician leaves, rather than when the robot returns to service, reports a fix that has not been verified.
• Reclassifying the second visit. A return visit logged as a new fault rather than a recurrence of the same cause resets the clock and hides the failure.
• Excluding the cause. Damage, misuse and site-caused faults are legitimately excluded from vendor FTF, but the exclusion list is frequently drawn wide enough to absorb genuine product failures.

A defensible definition fixes the three points: the ticket closes on verified return to service by the robot itself, a repeat visit for the same root cause within thirty days counts as a failure of the original visit, and the exclusion list is enumerated in the contract rather than referenced to a policy document the vendor can revise.

Remote Triage: The Cheapest Interval to Compress

Every dispatch decision is a bet. Dispatching a technician to a fault that could have been cleared remotely wastes a visit; failing to dispatch to a real fault wastes hours of triage. The quality of the triage decision determines both the response time and the FTF rate, and it is almost entirely a function of what the support desk can see.

The triage inputs that matter, in order of value:

• Fault code with component granularity. “Bumper fault” is not actionable. “Left bumper sensor intermittent, 14 events in the last hour, correlated with the aisle-7 threshold transition” is a diagnosis.
• Recent event history. A first occurrence and a fourteenth occurrence of the same code are different calls, and the correct response differs: monitor versus dispatch versus escalate to engineering.
• Site and configuration context. Map version, recent site changes, firmware version, and whether other robots on the same site are reporting the same signature. A fleet-wide signature is a software issue; a single-robot signature is hardware.
• Consumable and wear state. Brush wear, squeegee wear, filter loading and battery state of health. A meaningful share of reported “performance” faults are wear items, resolved by a consumable rather than a repair.

The decision rule that follows is worth writing down explicitly, because it converts an experienced engineer’s judgement into something a desk can apply consistently:

Signature	Action	Target interval
Known fault code with documented remote remedy	Remote clear, monitor 30 minutes	Under 30 minutes
Same signature on two or more robots on one site	Escalate to engineering, hold dispatch	Under 30 minutes
Wear item at or past threshold	Schedule consumable visit in normal hours	Same working day
Single-robot hardware fault, robot out of service	Dispatch with parts kit for the top three causes	Under 4 hours
Safety-related fault	Immobilise, dispatch, notify site	Immediate

The largest single gain in most programmes is the second row. A fleet-wide signature that gets dispatched to site as three separate hardware calls produces three wasted visits and a delayed real diagnosis; recognising it as a software or configuration problem at the desk removes all three visits at once.

Parts Carriage: Which Parts Travel in the Van

First-time-fix is decided in the van, not on site. The parts carriage decision is a straightforward value problem: the expected cost of a wasted visit against the cost of carrying the part.

The expected cost of not carrying a part is the probability that a visit needs it, multiplied by the cost of the resulting second visit. The cost of carrying it is the item value, the van space it occupies, and the risk of it being consumed elsewhere or going obsolete. For most robot fleets the arithmetic strongly favours carrying broadly, because the second-visit cost is large and the part values are small relative to it.

A defensible carriage list is built from the site’s own service history rather than from a generic kit list. The method:

• Extract the last twelve months of service events, tagged by root cause and by part consumed.
• Rank causes by frequency multiplied by second-visit cost, not by frequency alone. A rare cause with a two-day recovery time can outrank a common cause with a thirty-minute fix.
• Take the causes that cumulatively account for eighty percent of that weighted total. That set is the carriage list.
• Re-run the ranking quarterly. The set changes as the fleet ages: early-life fleets carry sensors and control boards, mid-life fleets carry drive and cleaning components, late-life fleets carry structural and interface parts.

Two additions sit outside the frequency ranking. The first is any part whose failure immobilises a robot in a public area, because that carries a safety and reputational cost that frequency alone does not capture. The second is any part with a lead time longer than the response commitment, because a part on back-order converts a resolved fault into an open-ended outage regardless of how rare the cause is.

The carriage list should be a contract annex, reviewed at the same interval as the service level, and it should be the vendor’s obligation to keep the van stocked against it. A carriage list agreed at signature and never revisited is the single most common reason FTF degrades in year two.

Geographic Coverage and the Response-Time Illusion

Response time is a function of distance, and distance is a function of where the technician network actually sits. A four-hour commitment across a national estate is achievable in metropolitan areas and structurally impossible in remote ones, which means the headline number is either met on average and missed where it matters, or quietly excluded for a list of postcodes.

Three questions expose the real coverage:

• What is the drive time to the site, at the time of day the fault is likely? A four-hour target measured from a network average disagrees with a four-hour target measured from the nearest technician to this postcode at 14:00 on a Tuesday. The second is the one that gets met or missed.
• Is the commitment calendar or business hours? A business-hours response commitment effectively doubles the outage for any fault reported on Friday afternoon. Sites running weekend or night operations need the commitment to match the operating window, not the vendor’s working week.
• What happens when the first technician is wrong? If the response commitment restarts at the second dispatch, the site bears the entire cost of a misdiagnosis. It should not: the fault-to-restore clock should run continuously.

For sites outside dense coverage, the more honest structure is a hybrid: a longer contractual response time combined with an on-site cold spare or a swap pool. If the site holds a spare robot, a hardware fault becomes a swap in the time it takes to move a unit, and the response time stops being the dominant term in the outage. The economics usually work better than paying for a coverage guarantee that the vendor cannot physically meet, and they are far more reliable in practice.

Whichever structure is chosen, the site should measure its own fault-to-restore independently, from robot telemetry rather than from the vendor’s ticket system. The telemetry record is the only version of the truth the site controls, and it is the evidence base for any service credit claim.

Writing Dispatch Into the Service Contract

The clauses that decide whether the service level has teeth are short and specific. Each of the following closes a gap that is routinely exploited, usually without any intent to exploit it.

• Clock start on fault detection, not dispatch. State that the measured interval begins at the first telemetry fault event or the site’s report, whichever is earlier.
• Notification deadline. Bind the vendor to notify the site within a defined period of a detected fault even if no dispatch is required. Silence is the most expensive failure mode for the site.
• First-time-fix definition. Include the verified-return-to-service closing rule, the thirty-day recurrence rule, and an enumerated exclusion list.
• Parts carriage annex. Attach the list, bind the vendor to stock against it, and make failure to stock a service-level breach rather than a commercial discussion.
• Escalation ladder. Define what happens at 1.5 times the committed response time, including who is called and what authority they have. An escalation path that ends at a support queue is not an escalation path.
• Telemetry access. Guarantee the site read access to fault logs for the life of the contract plus a defined tail period after exit. Without it, the site cannot verify any of the above.

The credit mechanism should be tied to fault-to-restore and to FTF, not to response time alone. A credit schedule that pays out only for missed response time will almost never pay out, because response time is the metric the vendor controls most directly and monitors most closely. FTF and fault-to-restore are the metrics that reflect the site’s actual experience.

The service credit and availability clause guide works through how credits are calculated and which exclusions quietly void them, and the warranty claims and RMA process guide covers the boundary between a warranty repair and a chargeable service visit, which is where FTF disputes usually originate.

A Worked Fleet Example

Put the pieces together on a fleet of twenty robots across six sites, running a two-shift operation with weekend coverage, and compare two service structures over a year.

Measure	Structure A: four-hour response, no FTF term, generic kit	Structure B: six-hour response, 92% FTF term, history-based kit, cold spares at two sites
Service events per year	180	180
First-time-fix rate	81%	92%
Repeat visits	34	14
Average fault-to-restore, first visit	8 hours	9 hours
Average fault-to-restore, repeat visit	44 hours	30 hours
Total lost service hours	1,168 + 1,496 = 2,664	1,494 + 420 = 1,914
Lost service value at 22/hour	~58,600	~42,100

Structure B concedes two hours of headline response time and recovers roughly 750 service hours, worth about 16,500 a year. The recovery comes entirely from the reduction in repeat visits and the availability of a swap at two sites. The apparent concession is not a concession at all: a longer committed response that is actually met outperforms a shorter one that is met on average and missed at the sites that matter.

The example also shows why the headline response number is such poor procurement currency. Structure A looks stronger on the only figure most tender documents ask for, and is materially worse on the figure that determines how many hours the robots actually deliver.

The Bottom Line

Downtime is a dispatch problem disguised as a reliability problem. The intervals that a site can compress cheaply are detection and remote triage, both of which are software and process. The interval that dominates the outage is the second visit, and it is decided by triage quality and parts carriage long before a technician arrives.

Four things carry most of the value: a fault-to-restore clock that starts at detection, a first-time-fix definition with verified closure and a thirty-day recurrence rule, a parts carriage list rebuilt from the site’s own service history each quarter, and telemetry read access the site controls independently of the vendor’s ticket system. With those in place, the service level describes the site’s experience rather than the vendor’s process.

If you are building the service requirement alongside a fleet decision, the uptime SLA contract guide covers the availability definition and measurement method, the preventive maintenance schedule guide sets the visit intervals that feed the parts plan, and the spares and consumables planning guide builds the stocking budget. The AOMAN product range documents the telemetry fields each model exposes, which is the input the whole dispatch model depends on.

Send us your sites, shift pattern and current service history and we will build the fault-to-restore model against your actual event rate rather than a generic fleet assumption.