When one robot needs help, any process works. When eleven need help at once and three are blocking traffic, you find out whether you have a triage system or just a list. Robot fleet incident triage is what decides which of those eleven gets a human first.
This guide covers why a queue is not triage, how to define severity by consequence, why escalation should run on a clock rather than on judgement, what belongs in a runbook, and how to keep the whole thing producing usable data.
Triage is not a queue
A queue processes events in the order they arrive. Triage decides which events matter most and handles those first, accepting that some will wait.
Fleet operations teams frequently build a queue and call it triage. It works until the first burst, at which point a robot blocking a fire exit sits behind four robots idling in a car park because they arrived earlier.
Real triage requires a severity model agreed before the incident, not improvised during it.
Severity, defined by consequence
Rank by what happens if nobody acts, not by how alarming the event looks.
| Band | Characteristic | Response |
|---|---|---|
| Safety | Risk to a person, or obstruction of an emergency route | Immediate, senior, and escalate in parallel rather than in sequence |
| Public disruption | Blocking a road, doorway, or crossing | Fast; consequences grow every minute |
| Asset risk | Robot at risk of damage, theft, or tampering | Prompt, and often a field dispatch rather than a remote fix |
| Service | Delivery delayed, no external risk | Standard handling |
| Degraded | Operating but impaired | Batch it; do not interrupt higher bands |
| Informational | Logged anomaly, no action needed | Analysis only |
Two rules make this work in practice. Severity is assigned by rule where possible, not by operator judgement under load. And severity can be raised by elapsed time: a service event that has run for fifteen minutes is no longer a service event.
Escalate on a clock, not on judgement
This is the single most useful mechanism we run. If an event is unresolved within a set window for its severity band, it escalates automatically, without anyone deciding to escalate.
The reason is that discretion fails predictably under pressure. An operator who is nearly finished will keep trying for another two minutes, then another two. Individually reasonable, collectively the cause of most long-running incidents. Removing the decision removes the failure mode.
It also produces a clean signal. Escalation rate per band becomes a direct measure of whether tier one is properly equipped, rather than a judgement about individual performance.
What a runbook entry needs
A runbook that reads like a policy document will not be used at the moment it is needed. Each entry should fit on one screen.
- Recognition. How to identify this situation quickly, including what it is commonly mistaken for.
- Severity band and the clock that applies to it.
- First action, stated as an instruction rather than a principle.
- Stop conditions. What must not be attempted, and when to stop trying.
- Escalation target, named by role, with the fallback if that role is unavailable.
- Required logging, so the record is complete without a second pass.
The stop conditions matter as much as the actions. Most damaging incidents involve someone continuing to attempt a remote fix past the point where a field dispatch was the right call.
Handover is where incidents get lost
Two handovers cause most of the trouble: tier to tier, and shift to shift.
- Overlap shifts. Active incidents transfer with context, which takes minutes. A hard cutover strands whatever is in flight.
- Transfer state, not a summary. The receiving operator needs what has been tried and ruled out, not a one-line description.
- Keep one named owner at all times. Incidents with two owners are incidents with none.
- Log the handover as an event, with its timestamp. Handover delay hides inside total resolution time and is invisible unless recorded separately.
- Never escalate into a void. If the target role is unstaffed at that hour, the runbook must say what happens instead.
Keeping the output usable as data
Triage produces the record that later becomes training signal, so the structure has to survive the pressure of the moment.
- Controlled root-cause vocabulary, chosen at resolution time from a short list. Free text cannot be clustered.
- Separate the trigger from the cause. What prompted the alert and what actually caused it are different fields and frequently different answers.
- Record the resolution type, distinguishing guidance, remote control, field dispatch, and self-resolution.
- Capture the sensor buffer from before the trigger, since causes precede symptoms.
- Flag repeat events at the same location or on the same unit, which are usually one problem rather than several.
Get this right and incident handling stops being pure cost, per from intervention to training data.
What we run
We provide remote monitoring and intervention for an autonomous mobility company operating sidewalk delivery robots and self-driving passenger vehicles. Three things carry most of the weight.
- Rule-assigned severity wherever the system can determine it, so operators are not classifying under load.
- Clock-based escalation with no discretion to extend.
- Root cause captured at resolution by the person who handled it, from a fixed list.
For a programme where sustained work on a specific failure class moved a hard number, our warehouse policy case study tracks deformable-item success from 61 to 84 percent.
Frequently asked questions
How many severity bands should we have?
Few enough that assignment is instant. Four to six works. Beyond that, operators hesitate over the boundary, which is exactly the delay triage exists to remove.
Who decides severity?
The system where it can, from rules on robot state and location. The operator only where genuine judgement is required, and with a default to the higher band when uncertain.
Should escalation timers differ by severity?
Yes, and substantially. A safety event escalates in a fraction of the time a service event does. One universal timer means either safety events wait too long or service events flood the senior tier.
What if an operator disagrees with an automatic escalation?
Let it escalate and record the disagreement. Reviewing those cases weekly is how the rules improve; allowing operators to suppress escalation reintroduces the failure mode it was designed to prevent.
Triage is the difference between an operations team that absorbs a bad hour and one that compounds it. If you want your severity model and escalation clocks reviewed, tell us how your fleet is instrumented, or read more about our remote operations work.
