Skip to content
Back to Resources
How-To

How to Automate Deal Desk Reviews and Discount Approvals

Skopx Team
July 27, 2026
10 min read

When you automate deal approvals, you are not trying to remove the human who signs off on a 35% discount. You are trying to remove the two days of chasing that happen before that human has enough information to decide. A rep pastes a request into a channel, the deal desk asks for the contract term, the rep goes back to the CRM, someone asks about the last renewal price, nobody can find it, and the quote expires while everyone waits.

This guide walks through building that workflow in Skopx: a webhook or schedule picks up new discount requests, the workflow pulls the deal record and account history, an AI step drafts a structured review packet against your discount policy, and the packet lands in front of the right approver with everything they need. The approver still approves. The workflow just makes the decision take ninety seconds instead of two days.

What manual deal desk review actually costs

Deal desk work is expensive in ways that never show up as a line item. The costs are structural.

Context assembly. Every non-standard discount request needs the same eight or nine facts: current ARR, contract term, payment terms, the discount already baked into list, competitive situation, prior discount history on the account, product mix, and who the economic buyer is. A rep assembles this by hand for every request. A deal desk analyst then re-assembles it because they do not trust the rep's version.

Queue invisibility. Requests arrive in Slack DMs, email threads, CRM approval queues, and hallway conversations. Nobody can answer "how many deals are waiting on us right now" without asking three people.

Inconsistent policy application. The same 28% discount gets waved through on a Tuesday and escalated to the VP on a Friday, depending on who picked it up. Reps learn to time their requests, which is a terrible incentive to create.

End-of-quarter compression. Sixty percent of the quarter's approval volume arrives in the last two weeks, which is exactly when the approvers have the least time. The queue that runs fine in week four falls over in week twelve.

The fix is not a faster approver. It is removing everything from the approval that is not actually a judgment call.

Why teams automate deal approvals instead of hiring more analysts

The work splits cleanly into two piles. One pile is retrieval, calculation, formatting, and routing. That pile is mechanical, it is where all the delay lives, and it is what you automate. The other pile is judgment: is this discount worth the revenue, does it set a precedent we regret, is the competitive threat real. That pile stays human, permanently.

Teams that automate deal approvals well are automating the first pile aggressively and the second pile not at all. The workflow becomes a preparation engine. It knows the policy, it knows where the data lives, it knows who owns each tier, and it produces a decision-ready packet. The approver reads and decides.

This is also why Skopx is a reasonable fit for this specific process. Skopx workflows have no human-approval step, which sounds like a gap until you look at what deal desk approval actually is. A discount approval is a commercial commitment with revenue consequences. It should never be executed by an automation, and a workflow that quietly approved a 40% discount because a field matched a threshold would be a liability, not a feature. The workflow prepares and routes. A person acts.

What to automate versus what stays human

Draw the line by asking a single question about each step: if this step is wrong, does the company lose money or make a promise it cannot unmake? If yes, a human does it.

StepAutomate itKeep it humanWhy
Pull deal, account, and quote recordsYesPure retrieval, no judgment
Calculate effective discount off listYesArithmetic on known fields
Look up prior discounts on the accountYesRetrieval, and nobody does it manually
Check the request against policy tiersYesDeterministic comparison
Draft the rationale and risk summaryYesAI drafts, a human reads before deciding
Decide to approve or rejectYesRevenue commitment, precedent risk
Send the approved quote to the customerYesCustomer-facing and irreversible
Apply the discount in CPQ or the CRMYesExecutes the commitment
Log the decision and notify the repYesOnce a human has decided, recording is mechanical

Two things on that table deserve emphasis. First, the AI step drafts a rationale, it does not render a verdict. Phrase your prompt so the output is "here is what the policy says, here is the account history, here are the two things worth questioning" rather than "approve this." Second, the workflow should never write the discount back into your CPQ system on its own. Prepare the change, notify the approver, let the approver commit it.

The workflow design

Start with the smallest version that removes real work. A quote submission fires a webhook, the workflow gathers context, an AI step builds the review packet, the packet gets logged and posted to the deal desk channel.

Basic deal desk review

Quote submitted webhook

Fetch opportunity record

Fetch account history

AI drafts review packet

Log review row

Post to deal desk

A discount request becomes a decision-ready packet in the deal desk queue.

Five steps, one trigger. The webhook trigger gives you a unique URL with a per-workflow secret, so your CPQ tool, form, or CRM automation can post the request directly. If your CPQ cannot call a webhook, use a schedule trigger instead: run every 15 minutes and query for quotes with an approval status of pending.

Once the basic version is running, add the branch that makes it genuinely useful: tier routing. A 12% discount inside a rep's standing authority does not need the VP. A 32% discount does. The condition step reads the calculated discount and sends the two cases down different paths.

Tiered approval routing

above tierwithin authority

Quote submitted webhook

Fetch opportunity record

Compute effective discount

Discount over threshold

AI drafts exception memo

Notify VP and deal desk

Record standard discount

Confirm to rep

Discounts above the threshold get an exception memo and executive routing; the rest are recorded and confirmed.

The "within authority" path is not an approval. It is a recording path for discounts the rep was already permitted to give under policy. No new permission is being granted, so nothing sensitive is being executed. Anything that needs a new permission goes down the other branch, to a person.

How to automate deal approvals in Skopx, step by step

Skopx workflows are built by describing them in chat. There is no canvas and no drag-and-drop. You write a sentence, Skopx builds the steps, and you open each step to check the field mappings.

1. Connect the tools first. Connect your CRM, your CPQ or quoting tool, your spreadsheet or database for the review log, and your messaging tool. Skopx connects to nearly 1,000 business tools, so the specific combination matters less than doing it before you describe the workflow. Steps built against a disconnected tool cannot be validated.

2. Write the description. Go to Skopx workflows, start a new workflow, and describe it in one pass:

When my quoting tool posts a discount request to this workflow's webhook, look up the opportunity in the CRM using the opportunity ID from the webhook, then look up the account's closed-won deals from the last 24 months. Calculate the effective discount as a percentage off list. If the discount is greater than 20, use an AI step to draft a deal desk exception memo containing the deal size, term, effective discount, the account's prior discount history, the stated justification, and the two biggest risks a reviewer should question, then post that memo to the #deal-desk Slack channel tagging the VP of Sales and log a row in the Deal Reviews sheet with status pending. If the discount is 20 or less, log a row in the Deal Reviews sheet with status within-authority and send the rep a confirmation message. Never change the quote or the opportunity record.

That last sentence matters. State the boundary explicitly so the built workflow contains no write step against the quote.

3. Check the expressions. Open each step and confirm the data references. The webhook payload is available as {{ trigger.opportunity_id }} and similar. Step outputs chain as {{ steps.<id>.output.field }}, so your AI step prompt pulls the CRM record with something like {{ steps.fetch_opp.output.amount }}. If a field name in your CRM differs from what was assumed, fix it here rather than re-describing the whole workflow.

4. Set the threshold in a transform, not in prose. Put the discount calculation in a field transform step and have the condition compare that single computed value with greater_than. When finance changes the tier from 20% to 15%, you edit one number.

5. Run it manually with a real deal. Trigger a manual run against a live opportunity ID. Every run is inspectable: each step records its real output, its duration, and the exact error if it failed. Read the AI step's actual output before you let this touch a real queue. If the memo is vague, the fix is a more specific prompt, usually naming the exact fields you want quoted.

6. Turn on the trigger. Point your CPQ tool at the webhook URL with the workflow secret, or switch to the schedule trigger and pick your timezone. Schedules run at a 15 minute minimum, hourly, daily, or weekly.

How to tell it is working

Watch four things in the first month.

Time to first review. Timestamp the request in your log row and timestamp the decision. The gap should collapse from days to hours, and the collapse should come from the preparation time, not from approvers deciding faster.

Packet completeness. Count how often an approver replies asking for information the packet should have contained. If that number is not near zero after two weeks of prompt tuning, your AI step is missing a data source.

Tier distribution. If 90% of requests land above your threshold, your threshold is wrong or your list prices are. That is a pricing signal the manual process was hiding.

Run failures. Open the run history weekly. Failed runs usually mean a renamed CRM field or a revoked connection, and they are much easier to catch as a pattern than as a one-off.

The same instrumentation logic applies to adjacent sales workflows. If you have already built lead routing, you know that the win condition is queue visibility rather than raw speed. Deal desk is the same shape at the other end of the funnel.

Common mistakes

Letting the workflow approve. The most common request is also the worst idea: auto-approve anything under 15%. Even when policy technically permits it, an automation that grants commercial permission removes the audit trail that makes deal desk defensible. Record and notify. Do not approve.

Writing back to the quote. A workflow that updates the CPQ record before a human decides creates a quote the customer can see. Keep every write out of the quote object.

Feeding the AI step raw JSON dumps. Pull the specific fields you need in the retrieval steps and reference them individually in the prompt. Whole-record dumps produce memos that restate the record instead of analyzing it.

Assuming stale CRM data is accurate. A deal desk packet built on a half-empty account record is a confident-looking document that is wrong. If your records are thin, fix that first with CRM data enrichment.

Overbuilding on day one. Workflows are capped at 20 steps and are acyclic, with no loops. That cap is rarely the real constraint. The real constraint is that a 19 step workflow is hard to debug. Split multi-region or multi-product logic into separate workflows triggered from the same webhook.

Ignoring the schedule grace window. If you use a schedule trigger and a run is missed beyond a 2 hour grace window, it is recorded as failed rather than fired late. That is deliberate, because a stale deal desk sweep firing six hours late is worse than a visible failure, but you should be watching for it at quarter end.

Extending the workflow

Once the core loop is stable, the natural additions are all preparation, never execution. Attach the last three renewal prices for the account. Pull the competitor named in the opportunity and have the AI step flag whether the discount matches your standard competitive response. Post a daily 8:00 digest of everything still pending so nothing sits silently. If the approver meets the rep to discuss it, the packet doubles as the input to an automated meeting prep brief.

What you should not add is a step that closes the loop automatically. The value here is a decision-ready packet in front of the right person fast. The person stays.

Frequently asked questions

Can Skopx approve a discount automatically if it is under our threshold?

No, and it should not. Skopx has no human-approval step, and it will not execute the approval on your behalf. Under-threshold discounts that a rep already has authority to give can be recorded and confirmed automatically, because no new permission is being granted. Anything requiring a new permission is prepared, packaged, and routed to a person who decides.

What triggers this workflow if our CPQ tool cannot send webhooks?

Use a schedule trigger. Run every 15 minutes, hourly, or daily in your chosen timezone, and have the first step query your CRM or CPQ for quotes in a pending approval status. The tradeoff is latency: a 15 minute schedule means up to 15 minutes before a request is picked up, which is usually irrelevant against a manual baseline measured in days.

How much does the AI step cost to run?

AI steps run on your own provider key with zero markup, so the model usage bills directly to your provider account and Skopx adds nothing on top. You need your own API key connected for AI steps to run at all. The Skopx subscription itself is Solo at $5 per month, Team at $16 per seat per month, and Enterprise at $5,000 per month. Every plan bills from day one.

Can the workflow handle different thresholds per region or product line?

Yes, with a caveat. If/else conditions support comparisons like equals, contains, greater_than, and is_empty, and you can chain conditions inside the 20 step limit. But nested tier logic gets unreadable fast. For more than three tiers, run separate workflows per region or product line, each pointed at the same webhook and each filtering for its own segment in the first condition.

Is our deal and pricing data safe in this workflow?

Skopx has SOC 2 controls in place, and every run records exactly which steps read which records, so you have an audit trail of what the workflow touched. As a practical matter, limit the retrieval steps to the fields the packet actually needs rather than pulling full records, and keep write access out of the workflow entirely for this use case.

Share this article

Skopx Team

The Skopx engineering and product team

Related Articles

Stay Updated

Get the latest insights on AI-powered code intelligence delivered to your inbox.