Skip to content
MirrorFirm

Why is escalation harder to evaluate than a plain approve or decline decision?

The correct action is often to refer rather than decide, the boundary depends on several fields, and quality sits in the handover as much as the routing.

**Because the correct action is often not a decision at all.** An agent can be right to decline to decide.

Three things make it harder:

- **The boundary is conditional.** Authority depends on product, risk grade, aggregate exposure and sometimes exceptions already granted, so no single field gives the answer. - **Several actions can look reasonable.** Approving, referring to the next tier, referring to a specialist, and returning for information can each be defensible on a surface read; only the policy and case state separate them. - **Quality sits in the handover.** A referral with a missing rationale or absent evidence is a failed escalation even if the routing was right.

A binary approve/decline label hides all of this. A useful task pack scores the routing choice, the cited trigger, the completeness of the handover package, and the resulting case state separately.

It also helps to include cases where the correct behaviour is to proceed without escalating. An agent that refers everything upward looks safe on a failure count but fails the purpose of the workflow, and a pack with no within-authority cases cannot detect it.

Ask any supplier how the expected outcome is represented, and whether more than one acceptable path is allowed.

Score routing, cited trigger, handover completeness and resulting state separately, and include cases where not escalating is correct.

Audience:
Evaluation teams
Content type:
FAQ
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Credit escalation