AI agents for deal desk: auto-clearing the standard discount, escalating the exception

A rep needs 18% off to close by quarter-end. The request goes into an email thread, waits for a manager in back-to-back calls, bounces to finance over a margin line nobody can find the rule for, and clears two days later when the buyer has gone quiet.

Every deal desk has some version of this, and it is the most automatable bottleneck in the revenue org.

Salesforce built for it. Agentforce for Revenue puts an agent on the approval queue that can process standard discount requests within defined guardrails and escalate the exceptions to a human with full context. Teams that wire it well report the routine approval cycle dropping from a multi-day email chain to hours.

The failure mode is predictable, though, and worth naming before you build. A deal desk agent that decides how much discount a deal gets is a margin leak with a chat interface.

The design that works keeps a hard line: the agent clears requests that already sit inside policy and routes the ones that do not, and it never sets the number itself. Below is how to draw that line so the desk gets faster without getting looser.

What a deal desk decides, and what it does not

A deal desk is the control point between a rep who wants to close and a business that wants to protect margin. Its job is to approve or deny discount and pricing exceptions against policy, unblock deals that sit inside the rules, and escalate the ones that do not to whoever owns that call.

Note what that is not. A deal desk does not build the quote from scratch. Assembling the quote from the product catalog and the pricing engine is Revenue Cloud’s quoting job, and the load-bearing rule there holds here too: price comes from the engine, never from the model.

The deal desk sits one step later, on the exception the quote raised, deciding whether a discount the rep asked for is allowed.

Keeping those two jobs separate is what makes the agent safe to build. The quoting agent reads a catalog and applies configured rules. The deal desk agent reads a policy and applies a decision. Conflating them, letting one agent both propose a discount and approve it, is how you end up with a system that negotiates against itself.

The rule that keeps it safe: the agent routes, the policy decides

The single most important design choice is where the approve-or-deny logic lives. It cannot live in the prompt.

A language model asked “should this 18% discount be approved” will give you an answer, confidently, and it will be wrong often enough to cost real margin. The model is inferring a policy it was described, not executing one it can read.

The decision has to run through deterministic logic: an approval process, a Flow, a margin-floor check that returns the same verdict every time for the same inputs.

Salesforce Revenue Cloud gives you the pieces to encode that policy. You can configure tiered discount authority by sales role and product category, build cross-functional approval chains that route by the size and shape of the request, and set hard margin floors that block a submission below a profitability minimum.

The Discount Distribution Service handles how an approved discount spreads across the lines. Those are configuration, and they are deterministic, which is exactly where the consequential decision belongs.

The agent’s job is everything around that decision, not the decision itself. A small invocable that the agent calls, evaluating the request against tiered authority and a hard floor, keeps the verdict in one testable place:

public with sharing class DiscountPolicyEvaluator {
    public enum Verdict { AUTO_APPROVE, ESCALATE, BLOCK }

    public class Request {
        @InvocableVariable(required=true) public Decimal requestedDiscountPct;
        @InvocableVariable(required=true) public Decimal lineMarginPctAfter;
        @InvocableVariable(required=true) public String repRole;
        @InvocableVariable(required=true) public String productCategory;
    }

    // Hard floor below which nothing may be submitted, ever.
    static final Decimal MARGIN_FLOOR = 20;

    @InvocableMethod(label='Evaluate discount request against policy')
    public static List<String> evaluate(List<Request> reqs) {
        List<String> out = new List<String>();
        for (Request r : reqs) out.add(decide(r).name());
        return out;
    }

    private static Verdict decide(Request r) {
        if (r.lineMarginPctAfter < MARGIN_FLOOR) {
            return Verdict.BLOCK;
        }
        Decimal authority = maxDiscountFor(r.repRole, r.productCategory);
        if (r.requestedDiscountPct <= authority) {
            return Verdict.AUTO_APPROVE;
        }
        return Verdict.ESCALATE;
    }

    private static Decimal maxDiscountFor(String role, String category) {
        Discount_Authority__mdt tier = Discount_Authority__mdt.getInstance(
            role + '_' + category
        );
        return tier != null ? tier.Max_Discount_Pct__c : 0;
    }
}

The authority table lives in custom metadata, not in code and not in the prompt, so RevOps changes a tier without a deploy and without touching the agent. The margin floor is a hard constant that no path can talk its way past. Read it and you know what the desk will do; that readability is the point.

What the agent adds on top of the policy

If the decision is deterministic, it is fair to ask what the agent is even for. The answer is everything the email chain was slow at, which is most of the cycle time.

The agent reads the request in natural language and classifies it: what discount, on what lines, for which account, against which competitive situation the rep described. It assembles the context a human approver otherwise hunts for, the account’s history, the margin after the discount, whether this customer is already flagged as a retention risk that shouldn’t get more concessions.

Then it calls the policy evaluator, and acts on the verdict.

On an auto-approve, it applies the approved discount through the configured service, updates the quote, and tells the rep, in seconds rather than days. On an escalate, it does the part humans are worst at under time pressure: it writes the approver a clean summary. What is being asked, why, what the margin does, what policy line it crossed, and what the agent recommends, all in one view.

That summary is the real productivity gain. An approver who opens a request and sees the whole picture decides fast and decides well. An approver who has to reconstruct the deal from a forwarded thread either rubber-stamps it or sits on it, and both of those are how margin leaks or deals stall.

The escalation is the product, not the fallback

Teams building these agents treat escalation as the failure case, the thing that happens when the agent could not handle it. Invert that. The escalations are the deals that most need a human, and routing them well is the agent’s most valuable output.

The human-in-the-loop principle that governs any consequential agent applies with force here: gate the irreversible action, and make the reviewer’s job easy. A discount, once granted and communicated to a customer, is very hard to claw back, so anything above standing authority routes to a person, and the person gets everything they need to decide in one place.

Design the escalation path to match the exception, not to dump everything in one queue. A request that fails on margin goes to finance. A request that is large but healthy goes to the sales VP. A strategic-account exception goes to whoever owns that relationship.

The agent classifying which kind of exception this is, and routing accordingly, is worth more than the auto-approvals, because it puts the right human on the deals that need judgment.

The gotchas that decide whether it works

Margin data is the first one, and it is a prerequisite, not a detail. The agent cannot enforce a margin floor it cannot compute, which means cost or COGS has to be available on the line at decision time.

Plenty of orgs discover during this build that their cost data is stale, missing on half the catalog, or living in a system the quote cannot reach. Fix that before you automate, because a margin floor that reads a null cost is a floor made of nothing.

The second is the agent proposing discounts. A rep will ask the agent what discount would get approved, and if the agent answers, you have just taught your customers that the fastest path to a bigger discount is to ask the bot. Keep the agent on evaluating requests, not generating them, and hold the guardrail that stops it volunteering concessions as firmly as any policy in the metadata.

The third is the audit trail. A deal desk decision is a financial control, and “the agent approved it” is not an answer an auditor accepts. Every auto-approval needs to record what policy authorized it, which tier, which margin, which evaluator run, so the decision is reconstructable a year later.

Deterministic policy makes this straightforward, because there is a specific rule to point at. That is one more reason the verdict cannot live in a prompt you cannot replay.

The fourth is the bypass. Approval processes have override paths, and an agent operating alongside human approvers must not become the quiet way around a control a human would have caught. If a request that should escalate can be auto-cleared because it entered through the agent instead of the form, you have built a hole, not a desk. Route both paths through the same policy evaluator so the answer is identical no matter who or what asked.

What I would build first

Start with read-only. Point the agent at the incoming discount requests and have it classify, assemble context, and draft the escalation summary, without granting a single approval. For a few weeks it is a very good analyst that makes your human approvers faster, and you get to watch its classifications against what the humans actually decide.

Then turn on auto-approval for the narrowest, safest tier: small discounts, healthy margins, standard products, well inside standing authority. Watch those hold, then widen the auto-approve band one tier at a time, and only after the layer below it has been boring for a stretch.

A deal desk agent earns the right to clear a request the same way a new desk analyst does, by being right on the easy ones long enough that you stop double-checking. The margin floor is the line that stays fixed the whole way up.

If you are still moving off CPQ onto Revenue Cloud, sequence this after that migration, because the policy primitives the agent leans on live on the newer platform.

Understanding the basics

What is a deal desk agent in Salesforce?

It is an AI agent, built with Agentforce for Revenue, that works the discount and pricing-exception queue a deal desk handles. It classifies each request, assembles the context a human approver needs, applies your discount policy through deterministic logic, auto-clears requests that sit inside standing authority, and escalates the exceptions to the right person with a full summary. The goal is compressing an approval cycle that runs on email into one that runs in minutes for the routine cases.

Should the AI agent decide how much discount to give?

No. The agent should evaluate a discount request against policy and route it, never set the discount amount or approve one that breaks a margin floor. The approve-or-deny logic belongs in deterministic configuration, an approval process, a Flow, a margin-floor check, so it returns the same verdict every time. A language model asked to judge discounts directly will be confidently wrong often enough to cost real margin.

How does Salesforce Revenue Cloud enforce discount policy?

Revenue Cloud lets you configure tiered discount authority by sales role and product category, build cross-functional approval chains that route by the size and type of request, and set hard margin floors that block a submission below a profitability minimum. The Discount Distribution Service handles how an approved discount is applied across the quote lines. These are deterministic controls, which is exactly why the agent should call them rather than reimplement the decision in a prompt.

What has to be true before we automate the deal desk?

Cost or margin data has to be reliably available on the quote line, because the agent cannot enforce a floor it cannot compute. Your discount authority has to be written down as policy, not held in a manager’s head, so it can be encoded. And you need an audit trail that records which policy authorized each auto-approval. Get those three in place and the automation is safe; skip any of them and it is a control with a hole in it.

---

A deal desk agent lives or dies on the policy underneath it, and the line between faster and looser is easy to cross by accident. Talk to us if you want that policy encoded so the desk speeds up without leaking margin, or see how we help SaaS and technology revenue teams put quoting and approvals on rails that scale.