Use observable triggers
Write rules a reviewer can verify: no approved source, conflicting account information, a requested policy exception, repeated unsuccessful steps, or an explicit request for a person. Avoid treating a fluent answer or an unexplained model confidence number as permission to continue. Decide which cases can receive a provisional factual reply and which should pause until review.
Specify the destination and acceptance
An escalation rule needs a recipient, required context and an acknowledgment step. Distinguish assignment from acceptance: putting a case in a queue does not mean a teammate has seen it. For US and Saudi coverage, state the receiving team's working hours and the fallback if no one accepts. A planned workflow must be tested in the actual helpdesk before customers depend on it.
Fictional worked example
A fictional customer asks for a return outside the published window. The assistant can explain the standard policy, but the exception goes to the authorized team. The handoff should say which condition failed and what decision is needed; it should not tell the customer that a refund has been approved. Test the same case in Arabic and English and confirm that both reach the same destination.
Action checklist
- Write each trigger as a condition that a reviewer can observe.
- Name the receiving team and the decision it is authorized to make.
- Include a fallback for unaccepted cases.
- Test that the assistant stops making commitments after escalation.