How to set escalation rules that don't get ignored

Your escalation rule says anything over $250,000 goes to the general counsel. Somebody skips it once, on a deal that felt routine, and nothing bad happens. They skip it again. Three contracts later, the number on the page is more of a suggestion than a rule, and nobody remembers deciding that.

Nobody decided to stop following the rule. It's just what happens to any threshold that gets applied the same way to everything, whether the thing behind it is actually risky or just technically over the line.

Treating every flag the same way is what kills the rule

Escalation lists tend to get built the same way everywhere: a dollar amount, a handful of clause types (indemnity, liability, IP, data protection), and a rule that anything matching those gets kicked upstairs. That's a reasonable starting point, and it's roughly what shows up in every contract review policy template out there. The problem shows up later, at volume, when half your flagged files are a genuinely unusual liability position and the other half are a routine renewal that happened to cross the dollar line by a few thousand dollars. Both get the same flag. Both land in the same queue. Reviewers learn fast which flags are worth opening and which ones aren't, and once that happens, the rule is only as good as whoever still bothers to read it.

This isn't unique to contracts. On-call engineering teams ran into the identical wall with system alerts years ago, and the fix they landed on is worth borrowing. Atlassian's write-up on the problem puts it plainly: one way to prevent alerts from overwhelming an on-call team is to set intelligent thresholds for them, because too few alerts can mean missed incidents, but too many can also lead to missed incidents through alert fatigue. Their point about severity is the one worth keeping: if not all alerts carry the same weight, they shouldn't show up the same way in front of the person who has to act on them. A contract queue works the same way. A flag that means "read this before lunch" and a flag that means "stop, this needs a partner" can't look identical, or your team will treat both like the second kind, meaning ignored until someone complains.

Route on deviation and novelty, not only on a static list

The fix isn't a longer list of clause types. It's splitting escalation into two different questions, because they aren't the same question. First: how far does this term sit from your standard position, not whether it merely touches a sensitive topic. A liability cap at 1x fees against a standard of 1x fees is not the same event as an uncapped liability clause, even though both technically involve "the liability clause." Second: has your team seen this pattern before. A deviation your playbook already has a fallback for is a different animal from language nobody on the team recognizes, even when the dollar value is smaller.

Score on those two axes and you get something closer to a real signal: small deviation plus familiar pattern stays with the first-pass reviewer, small deviation plus unfamiliar language gets a second set of eyes, and any large deviation goes up regardless of dollar size. This is also where a playbook earns its keep, since your reviewers need somewhere to check "familiar" against, and an intake process that already tags contracts by risk before they reach a reviewer makes this scoring cheaper to apply, because half the classification work is already done by the time the file lands in someone's queue.

Watch your escalation rate the way you'd watch anything else

Once the rule is running, the number that tells you whether it's working isn't how many contracts got flagged. It's what share of flagged contracts actually needed the senior reviewer once they got there. Incident.io's guide to escalation policy design tracks the equivalent number for on-call teams and treats a 10 to 30 percent escalation rate as healthy, with rates consistently above that range pointing to a routing problem rather than a run of bad luck. Contract review isn't identical, but the underlying test carries over fine. If almost everything that gets flagged turns out to need the senior reviewer, your first-pass thresholds are too loose and you're spending a specialist's time on things a playbook could resolve. If almost nothing does, your flags are catching noise instead of risk, and somebody eventually stops trusting them.

Software that applies a first pass against your playbook can help here, mainly by making the deviation-and-novelty scoring consistent across a hundred contracts instead of depending on whoever happens to be reading that day. It won't decide what your thresholds should be, and it won't catch the contract that's risky in a way nobody has written a rule for yet. That part stays with the people who own the escalation policy.

Pull last month's flagged contracts, sort them by whether the senior reviewer actually changed anything, and you'll know within an hour whether your rule is catching risk or just making noise.

Try goHeather free and run it against a batch of contracts you've already reviewed, to see where its first pass would have routed each one.

This is legal information, not legal advice; consult a lawyer for legal advice.