Deal exceptions

Non-standard pricing and terms routed to Finance, Sales Management and Legal in parallel — with every approval tracked instead of buried in email.

A rep needs Net 90 and a 20% discount to close. Today that becomes an email to three people, a thread nobody can find later, and a deal that stalls while everyone waits for someone else to reply first.

How it works

  1. The rep submits the exception — what they need and why.
  2. The policy engine compares it against your thresholds and works out who actually has to approve. A small discount may need one approver; stacking payment terms and liability may need three.
  3. Each approver gets their own leg, in parallel, in their own channel. Nobody waits on anybody else to start.
  4. The first rejection cancels the rest — no point asking Finance to approve something Legal has already refused.

Everyone can see where it is

The status is visible to the rep without asking: which legs are approved, which are outstanding, and who is holding it. That single fact removes most of the follow-up chasing that makes exception approval feel slow even when it is not.

Escalation is capped at two rounds per leg, so a request cannot ping-pong indefinitely.

It is a separate flow, on purpose

A deal exception is not a contract. It has no document, no redlines, and its own approval lineage — so it is kept apart from the contract register rather than pretended into it. Deal exceptions run in Slack and Microsoft Teams.


See also document review.

Common questions

Where do deal exceptions get reviewed?

In Slack or Microsoft Teams. Deal exceptions are deliberately chat-only — there is no web review surface for them.

Do the approvals happen one after another?

No. Finance, Sales Management and Legal review in parallel, each on their own leg, so nobody waits on anybody else. The first rejection cancels the remaining legs.