Repeated help requests need an escalation path

What it is

Help-request escalation changes recipient, priority, diagnostic detail, and robot behaviour when a problem remains unresolved, receives no response, or recurs after recovery. Replaying the same request is not escalation; it creates alarm fatigue while leaving ownership undefined.

Why it happens

The first request assumes a nearby person can respond. Timeout or recurrence is evidence against that assumption, so the event moves to a role with greater authority, tools, or remote diagnostics. Carrying attempt history avoids repeated diagnosis. Without bounds, retries and notifications become a noise loop that masks other incidents.

Studying it

Discrete-event simulation and drills can vary response delay, skill, and concurrent failures while measuring resolution, notification volume, missed alarms, duplicate work, and time in unsafe waiting. Nights, unattended periods, and communication failure matter. Final resolution alone omits collateral interruption.

Where it stops holding

Life-safety events should enter a predefined high-priority path immediately rather than wait through ordinary timeouts. Escalation must not bypass access control. Chronic recurrence requires withdrawal and root-cause work, not an ever-wider notification list.

Applying it

• Define first owner, acknowledgement time, next authority, retry limit, and safe terminal state for each failure class.
• Carry task, location, attempts, outcomes, and current risk with every escalation, supporting deduplication and acknowledgement.
• Drill no response, incorrect closure, and simultaneous multi-robot requests; measure time to the right owner, duplicates, and unresolved events.

Related

• Same group: X3.04.1 A stuck robot should proactively seek help rather than stop silently · X3.04.2 A help request should specify the required assistance
• Adjacent: X4.08 Responsibility allocation · X7.04 Multi-robot supervision
• Search terms: alarm escalation · help-request escalation · incident routing