Urgent Help Escalation Call

Urgent Help Escalation Call

Use this skill when software has learned that someone needs a human, and a notification is not good enough.

An in-app alert is only as good as somebody looking at a screen. The moments when that assumption fails are exactly the moments the alert exists for: the middle of the night, a shower, a meeting, a commute. A ringing phone is the one channel that reliably interrupts.

This skill is the bridge. One trigger, one call, one clear answer about whether it landed.

The two people

Getting this wrong is the failure mode that matters most, so name them separately in your own code:

Dialling the subject instead of the recipient means telling a frightened person that a frightened person needs help. Keep the two numbers in separate fields, label them unambiguously in any UI, and validate them separately.

When To Use

• panic buttons and help buttons in apps used by vulnerable people
• lone-worker duress alarms
• fall detection, inactivity timeouts, or bed-exit alerts
• care-home call bells that need to reach staff who are not at a station
• post-discharge deterioration flags
• any in-app urgent signal where "they will see the notification" is a bad bet

When Not To Use

Do not use this skill to:

• replace emergency services — see Emergencies
• call the subject themselves, for any reason
• deliver clinical detail, triage, or advice by phone
• send routine or digest notifications; this is for urgent signals only
• escalate something the subject did not actually ask for, without saying so
• call a responder who has not agreed to be called

Required Fields

Ask for anything missing. Never infer these:

Core Workflow

1. Confirm the trigger is genuinely urgent and came from the subject or a sensor, not from a routine event.
2. Check the cooldown for this subject. If a call went out recently, stop — see references/repeat-triggers.md.
3. Build the message from references/call-goal.md. Short. One fact, one instruction.
4. Place exactly one call to recipient_phone, with an idempotency key derived from the recipient and the trigger minute so a retried request cannot ring twice.
5. Read the structured result: did it reach the recipient, and did they confirm.
6. If it did not reach them, follow references/escalation-ladder.md.
7. Record the outcome where the humans involved can see it.

Fire the call without blocking the trigger. The subject is standing there having asked for help; the app's response to them must not wait on a phone network, and a failure to connect must never surface to them as an error. Raise your in-app alert first, place the call alongside it.

What The Call Says

Confirm who is listening before you disclose anything. This ordering is the design, not a nicety:

"Hello, this is <product>. Am I speaking with <recipient>?"
   ├─ no / unsure → "Sorry to have troubled you. Goodbye."  → hang up, say nothing
   └─ yes         → "<subject> has pressed the help button and is asking for
                     you. Please go to them when you can."
                  → "Are you able to get to them?" → thank them → hang up

The obvious design leads with the message to save a second. It is wrong. A number will eventually be answered by a neighbour, a partner, a child, or a stranger with a recycled number — and leading with the message tells them a named vulnerable person has asked for help before you know who is listening. Nothing downstream can un-say it, and a "if it's the wrong person, stop" branch fires only after the model has already spoken.

After the gate:

• Do not sound alarmed. Panic on the phone gets nobody there faster.
• Do not speculate about why. You do not know, and a guess becomes what the responder believes on the drive over.
• Say nothing about the subject's health, condition, or history.
• Never ask a stranger to pass the message on — that is a disclosure with extra steps.
• Ask whether they can go — a question, not an instruction. "Confirm you are going to her" reads as an order barked at someone just woken up. Ask once, accept the answer, do not press. They may be two hours away.
• Sound like a person passing on a message, not a system issuing one. Models drift officious when handed numbered steps and a schema; say the register you want out loud.
• Voicemail names nobody. It is the one case where the gate cannot run, so the message must be safe for a whole room to overhear: no name, no reason, just "there is an alert waiting in your app".
• Keep it under a minute.

Full template and the reasoning line by line: references/call-goal.md.