exception-resolution-calls

Resolving blocked workflows by phone

When to use this

Use it when three things are true at once:

1. a workflow is stuck on a fact only a person has ("did you get the order?", "will it ship Friday?", "can you take this job?");
2. the answer has to change system state, not just get logged;
3. a wrong answer has a real cost, so "we think they said yes" is not good enough.

Do not use it for open-ended conversations, for anything where the caller must negotiate or commit the business to something, or where no bounded set of questions exists. Those are not exception resolution; they are sales, and they need a human.

The shape of the problem

The tempting design is: call, ask the model what happened, update the record. That design fails in production for a reason worth stating plainly.

Extraction and authority are different jobs. A model is good at turning a messy conversation into structured fields. It is not the right thing to decide whether a purchase order may be closed, because when the evidence is thin it will still return something, and that something becomes a business fact nobody chose.

So split them:

CALL-E                          Your policy code
──────                          ────────────────
holds the conversation          decides what the answer means
extracts strict JSON            re-validates the JSON
reports confidence              can refuse to act on low confidence
never touches state             owns every state transition

Build it in this order

1. Model uncertainty before you model success

Write the result schema first, and give every judgment field an unknown value. This is the single highest-leverage decision in the whole design.

{
  "type": "object",
  "additionalProperties": false,
  "required": ["received", "po_status", "needs_human"],
  "properties": {
    "received": {
      "type": "string",
      "enum": ["yes", "no", "unknown"],
      "description": "Use yes ONLY when they clearly confirm receipt. Use unknown when the answer was hedged, second-hand or unclear — for example 'I think someone in logistics has it'."
    },
    "po_status": {
      "type": "string",
      "enum": ["on_time", "delayed", "blocked", "unknown"],
      "description": "Never infer a status from tone or from a polite acknowledgement."
    },
    "needs_human": {
      "type": "string",
      "enum": ["yes", "no", "unknown"],
      "description": "Use yes when they ask for a person, dispute the record, or raise pricing, payment terms or contract changes."
    }
  }
}