AI deal desk: a controlled workflow for pricing and approval exceptions

An AI deal desk should not approve discounts or contract terms on its own. Its useful job is narrower: assemble the facts behind a non-standard deal, apply explicit routing rules, show what is missing or inconsistent, and prepare an evidence packet for the people who own the commercial decision.

That distinction matters because deal desks operate at the boundary between speed and control. An account executive needs a quick answer. Finance needs to understand the commercial impact. Legal may need to review a term. Revenue operations needs a durable record of the exception and its approval path. A fluent summary is helpful only if those people can inspect the underlying deal facts and see why the request was routed to them.

This guide is for revenue operations leaders and deal-desk owners introducing AI assistance into an existing pricing-exception or non-standard-terms process. It covers a read-first workflow: the system can prepare and propose, while authorized people approve, reject, or negotiate the exception.

Start with one exception type and one decision owner

“Use AI for deal desk” is not a workable first requirement. Pick an exception that is frequent enough to justify a repeatable workflow and bounded enough to test.

For example:

For enterprise opportunities requesting a discount below the standard approval band, assemble the current quote, applicable pricing policy, opportunity facts, renewal or expansion context, and required approvals. Flag missing evidence and route the request to the designated approver. Do not change the quote, approve the discount, or send a customer-facing message.

The job statement specifies the trigger, decision, evidence, recipient, and action boundary. It also prevents the workflow from silently expanding into contract drafting, forecast changes, or pricing strategy.

Choose a first exception with clear policy and a named owner. Good candidates include a below-band discount, a non-standard payment schedule, a custom product bundle, or a term that requires legal review. Avoid a category where the organization routinely makes undocumented exceptions. AI can expose inconsistent practice, but it cannot turn an unstated policy into an enforceable rule.

Write the deal-review contract before connecting sources

The contract defines what the workflow is allowed to conclude and what a reviewer must receive. It should be owned by the deal desk, with finance, legal, and sales leadership agreeing where their decisions begin.

Keep policy rules out of a free-text prompt. A workflow can retrieve and summarize a policy, but approval thresholds, delegation rules, and hard stops should be structured, versioned, and evaluated as business logic. If an approver asks why a deal was routed, the answer should name the applied policy version and the specific facts that triggered it.

Use deterministic checks first, then AI for context

The workflow should have three lanes.

Lane 1: policy checks

Use fixed rules for known conditions: quote currency, discount band, approval authority, contract-template selection, required fields, expiration date, and whether the latest quote is the submitted quote. These checks are predictable and need reproducible outcomes.

For example, a 24% discount is not a model judgment. The workflow should calculate it from the approved list price and quote, apply the current band, and state whether the request crosses a routing threshold. If an exception is allowed only for a defined segment, the segment rule should be visible as well.

Lane 2: evidence assembly

AI can reduce the manual switching between systems after the deterministic checks have run. It can collect approved context from the opportunity, account history, quote, policy, order form, and internal notes; reconcile obvious differences; and prepare a timeline of material changes.

The output should not flatten sources into one confident narrative. Present each key fact with a source, timestamp or version, and link or stable identifier. When the CRM says the buyer needs a decision this week but the quote expires tomorrow, the discrepancy is a finding for the reviewer, not something to smooth over.

This is a practical application of the guidance in connecting AI agents to enterprise data: connect the smallest set of approved sources that can answer the job, and make freshness and access boundaries explicit.

Lane 3: human decision and record

The workflow may recommend the next review step, but the designated approver decides. Their decision should be recorded with the approved scope, conditions, expiry, and any follow-up needed to preserve the deal record.

This division of work supports the NIST AI RMF’s emphasis on defined human-AI roles, oversight, and documentation throughout the AI lifecycle. See the NIST AI RMF Core for the framework’s governance and mapping functions.

Give approvers an evidence packet, not a deal score

A score can help triage a queue. It is not an adequate basis for approving a commercial exception. The approver needs enough context to understand the requested deviation, its policy implications, and the unresolved questions.

For each submitted exception, prepare a compact packet with:

1. Request: the precise pricing, term, bundle, or payment exception, compared with the standard position.
2. Policy result: the rules evaluated, the policy version, and the required approval path.
3. Commercial facts: account, opportunity stage, products, quantity, term, requested close date, and quote version from the approved systems.
4. Rationale and evidence: the seller’s stated reason, supporting records, and a clear distinction between observed account facts and assertions.
5. Trade-offs: the relevant comparison, such as standard versus requested term or list versus proposed price. Do not present a margin or revenue conclusion unless finance has defined the required inputs and calculation.
6. Conflicts and gaps: stale fields, missing approvers, inconsistent dates, unavailable records, or a policy that does not cover the request.
7. Decision request: the named decision, approver, expiry, and next action.

Consider a hypothetical request for a larger discount in exchange for a longer initial term. The packet can show the approved quote, the current stage, the applicable discount band, prior account commitments, and the seller’s rationale. It should not claim that the discount will close the deal or that it is economically justified unless the organization has evidence and a method to support those conclusions.

Route by consequence, not by model confidence

Model confidence is not a commercial control. A request can be easy to summarize and still require senior review because it affects price precedent, contractual risk, or a strategic customer commitment.

Route using policy-driven consequences:

• Standard path: complete request within the defined band and using approved terms. The system can prepare the packet and route to the normal authorized approver.
• Exception path: a known deviation, such as a deeper discount or extended payment term. Require the additional finance, sales, or legal review defined by policy.
• Stop path: missing mandatory facts, a request outside the documented policy, conflicting source records, or an attempt to change a quote without authorization. The workflow should state what is missing and pause for a human owner.

The AI escalation matrix for business-data workflows explains the same operating principle: business consequence, reversibility, and evidence quality are more stable escalation inputs than a confidence label alone.

Treat deal content as evidence, not instructions

Commercial documents can contain terms, negotiation language, and customer requests. They should inform the review, but they must not be allowed to rewrite the workflow’s policy, change tool permissions, or bypass an approval path.

This is especially important when AI retrieves documents and notes. OWASP identifies prompt injection as a risk when untrusted content can influence a model’s behavior or tool use. Apply its LLM prompt-injection prevention guidance by keeping system policy separate from retrieved content, validating tool inputs, and requiring explicit authorization for consequential actions.

Access also needs to follow the person and the job. A deal desk may need commercial context from several systems without granting every requester access to all contract files, compensation data, or sensitive account notes. The model is not the security boundary; source permissions and action controls must be enforced around it. For a fuller implementation pattern, see AI agent permissions and access control.

Evaluate the workflow against completed exceptions

Begin with a retrospective sample of approved, rejected, withdrawn, and escalated deals. Include routine exceptions plus difficult cases: a revised quote after an approval, a stale opportunity stage, an incomplete rationale, conflicting contract language, a restricted source, and a policy change that affected the route.

Assess separate dimensions rather than relying on one “accuracy” number:

• Did the workflow identify the correct current quote and policy version?
• Were deterministic thresholds and approval routes applied correctly?
• Did every material claim have inspectable evidence?
• Did it expose conflicting, stale, or inaccessible information instead of guessing?
• Did it respect source permissions and keep prohibited actions unavailable?
• Did it send the reviewer a decision-ready question without asserting an unsupported outcome?
• Could the approver reconstruct the decision later?

Use the process described in how to evaluate an AI agent for business data to turn failures into a maintained test set. A correction may point to a missing identifier, policy exception, source freshness issue, or unclear ownership. Those are operating-model problems worth fixing, not merely prompt tweaks.

Pilot one approval queue before expanding

For a first release, run the workflow beside the existing deal desk without making changes to pricing, contracts, or customer communication. Select one exception type and one segment. Have reviewers compare the packet with their normal investigation and record where it saved lookup work, omitted a needed fact, routed incorrectly, or made a claim they could not verify.

Measure the path you changed: completeness of submitted requests, time from submission to an appropriately assigned reviewer, number of manual source lookups before a decision, approval reroutes, reopened decisions, and evidence or permission failures. Do not claim that the workflow improved win rate or margin without a suitable measurement design and comparison.

Jovis gives teams a governed workspace for agents working across approved business sources and shared context. A good evaluation is one real deal-desk queue: test whether the workflow helps reviewers reach a defensible decision with fewer manual handoffs, while the people accountable for price and terms retain the final say.