Deal Desk: Approving the Deals That Do Not Fit the Standard

A deal desk is the function that decides what a business will agree to when a deal does not fit the standard offer. Discounts beyond a set level, unusual contract lengths, non-standard payment terms, bespoke legal clauses, complicated configurations and commitments to deliver something new all fall to it. It sits between sales and the functions carrying the consequences, principally finance and legal, and its purpose is to make those decisions consistent, quick and recorded. In a large organisation it is a team; in a small one it should be three written rules rather than a function, because formality without volume just adds delay.

Thresholds decide what arrives

The design starts by defining what needs no review at all. A deal built from standard configuration and standard terms should proceed without anyone being asked. Review is triggered by specific deviations: a discount above a stated percentage, a term outside the usual range, payment terms differing from the default, any change to contract language, or a commitment to build something.

Tiers decide who answers

Authority should sit as low as is safe. A workable structure gives the salesperson a small band, the first-line manager a larger one, and the desk or finance anything beyond, with legal triggered by clause changes rather than by deal size. Each tier should resolve most of what reaches it; a structure where every request ends up in the same place is a queue with extra steps.

Response times decide whether it works

An approval process is only real if it is faster than the alternative. When a decision takes days, salespeople stop asking and start telling customers that something has been agreed, which produces exactly the risk the desk existed to prevent. A response window with escalation, and measurement of time to approval by request type, is what keeps the process inside the workflow rather than beside it.

A worked example (illustrative)

Suppose the rule is that salespeople may approve up to 10% discount, managers up to 20%, and anything beyond goes to the desk along with any non-standard clause. A deal worth ₹12,00,000 comes in at a requested 25% discount with a payment term of ninety days rather than thirty. Two thresholds are crossed, so the request routes to the desk with the deal context attached: the competitive situation, the term offered, the reason for the exception and what the customer conceded in return. The desk approves 18% with standard payment terms, or 25% with a two-year commitment, and records the decision against the opportunity. The salesperson has two structured options within hours rather than an open question for a week, and the next similar request has a precedent to follow.

The obvious purpose is protecting margin, and it is the least interesting one. The more valuable functions are consistency and memory. Consistency means the answer to a given request does not depend on which manager was available, which matters enormously once customers start comparing notes or a salesperson moves between accounts. Memory means a situation that has arisen before gets a fast answer, because somebody recorded what was decided last time and why.

There is also a diagnostic function that most teams underuse. Exception requests are a running commentary on where the standard offer does not match the market. A clause requested on most large deals is not an exception; it is evidence that the standard contract needs changing. A discount band that is almost always exceeded is evidence about list price. Reporting exceptions by type turns a queue of approvals into product and pricing input.

Reviewing too much

A desk that sees most deals will be slow, and a slow desk is bypassed. The proportion of deals requiring review is the single most important design number, and it should be small. When it is not, the answer is usually to change the standard offer rather than to add capacity to the review process.

Deciding on the discount alone

A discount percentage without context is not enough information to decide anything. The same concession can be sensible against a credible competitive threat with a longer commitment attached, and indefensible on a deal with no alternative in play. Requiring the context with the request costs the salesperson a few minutes and improves the decision substantially.

Approvals nobody can find

Where approvals live in email threads and messaging apps, the record disappears when somebody changes role. Months later a customer refers to a commitment nobody can verify, and the business either honours something it did not agree or damages a relationship. Recording the decision against the opportunity, with the quote version it applies to, resolves this at almost no cost.

Three measures cover most of it. The share of deals requiring review, which should be low and stable. Time to approval by request type, which should be short enough that bypassing is not tempting. And the distribution of exception types, which should be scattered rather than concentrated, since concentration means the standard is wrong.

A fourth is worth adding once the first three are stable: what happened to deals where an exception was granted. Did the discount actually win the deal, and did those customers retain? Concessions are frequently granted on the assumption that they were decisive, and the evidence is often more mixed than anyone expects.

These four are frequently confused, particularly in businesses where one person does several of them.

A deal desk is also distinct from configure, price and quote software. The software enforces rules automatically at the point a quote is built; the desk decides what happens when somebody needs to go outside them. Businesses that implement the software without agreeing the rules tend to find the exception queue grows rather than shrinks.

Approvals work best when they live in the same place as the deal. Start with what a CRM is, then look at product features for quoting, sales automation for routing and reminders, lead management software, CRM for small business for the lightweight version, and sales use cases.