Patient access.
Urgency before intent.

In most support contexts a wrong answer costs a customer some inconvenience. In patient access, the distribution of consequences is extremely uneven: nearly every interaction is harmless to get slightly wrong, and a very small number are catastrophic. A system designed around average performance is designed around the wrong statistic entirely.

So the architecture is built around the tail. The first question the system answers is not what the patient wants, but whether this contact shows any indication of urgency — and the threshold for handing to a human is set deliberately low, accepting a substantial rate of unnecessary escalations as the cost of the safety property.

That is an unusual thing to optimise for and it needs saying to a client early, because it means the automation rate will be lower than a vendor promising eighty per cent deflection will quote. We think a lower deflection rate with a safe failure mode is the only honest product in this setting.

The evaluation set is built primarily from the dangerous cases, not the common ones. Real contacts where urgency was present but the opening words looked administrative — the caller who asks to rebook and mentions chest pain in passing. Performance on that set is the gate; performance on routine booking is assumed and monitored.

Escalation is logged with the reason, and sampled by clinical staff on an ongoing basis. Two numbers are watched: how often it escalated unnecessarily, which is a cost, and whether it ever failed to escalate when it should have, which is not a cost but a stop.

And the system says what it is. Patients are told they are talking to an automated service and how to reach a person, in the first exchange. Beyond being required in many places, it materially changes how people phrase things — and in this setting that is a safety feature.