Nobody sets out to build a deal desk. What happens instead is that a rep asks in Slack whether they can go to twenty five percent, somebody senior says yes, and eight months later nobody can explain why one customer pays list and a comparable one pays sixty percent of it. The function exists from the first exception. Formalising it just means admitting that.
That is worth saying up front because most writing on this topic describes a mature enterprise deal desk, complete with SLAs and an executive sponsor, and quietly implies that anything smaller is not a real one. The reverse is closer to true. A deal desk is a written policy about what a rep can agree to alone, plus a named path for everything else. Everything after that is scale. This guide covers what the function actually owns, what HubSpot can and cannot enforce on your behalf, the documented gaps in that enforcement, and the one number the whole apparatus quietly depends on. If you are earlier than this and mapping the wider process, the quote to cash guide covers the full chain first.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
What Is a Deal Desk?
A deal desk is a cross-functional group that reviews and approves deals falling outside standard terms. The standard definition stops there, which makes it sound like an org chart problem. It is not. It is two artefacts.
The first is the policy: a written statement of what a rep can agree to without asking anyone. Discount ceiling, acceptable payment terms, which contract clauses are negotiable, what the floor is on term length, whether non-standard billing frequency is allowed. This is the part that does the work, because it determines the volume of exceptions. A generous, well-reasoned policy produces a quiet desk. A policy set too tight produces a queue that everyone learns to route around.
The second is the exception path: who decides when the policy does not cover the case, how they are reached, how fast they answer, and where the answer is recorded. This is the part people build first and the reason so many deal desks feel like bureaucracy. An exception path without a policy is just a permission-asking ritual.
What a Deal Desk Actually Does
The approvals are the visible part and the smaller part. GitLab publishes its deal desk job family openly, and it is a useful corrective because it lists the unglamorous work plainly alongside the strategic framing: acting as a trusted advisor to sales on deal structure, monitoring the channels where quoting and booking questions arrive, and handling debooks, rebooks, refunds and internal corrections.
That last cluster is the tell. A substantial share of deal desk hours goes on repairing the record after the fact, because the deal that was approved and the deal that got booked drifted apart somewhere between the two.
The work sorts into four groups.
Pre-deal guidance
Helping a rep shape a deal before it becomes an exception. This is the highest-leverage thing the function does and the easiest to skip, because it is invisible when it works. A desk that only sees deals after they are structured is doing rework rather than advising.
Review and approval
The formal pass: does this pricing, discount, term length and payment arrangement fall inside what the company is willing to sign. Either approve it, send it back, or restructure it into something approvable. The third option is what separates a desk from a gate.
Booking accuracy
Making sure the approved deal is what enters the systems downstream, at the right amounts, on the right dates, against the right entity. This is where the CRM and the billing or accounting system are reconciled, and it is where most of the volume lives.
Policy feedback
Noticing that the same exception has been granted eleven times and proposing that it stop being an exception. Without this loop the desk's workload only ever increases, because every accommodation stays permanently manual.
Reporting lines vary and there is no standard. Deal desks sit under the CFO, the VP of Sales, the CRO or the VP of RevOps depending on the company, and the choice is not cosmetic: a desk under finance is understood as margin protection, and a desk under sales is understood as a service that helps close. Both work. Being unclear which one you have does not, because reps calibrate their behaviour to the answer.
Do You Need a Deal Desk?
The trigger is not headcount or deal volume. It is inconsistency.
Signs the desk already exists informally
The same question gets different answers. Two reps ask about the same discount level in the same month and get different responses from different managers. This is the single clearest signal, and it means the policy exists only in people's heads.
Terms are agreed somewhere unsearchable. Payment terms, a bespoke SLA or a cancellation right gets committed in an email thread, and six months later nobody can produce it. The commitment is real whether or not the CRM knows about it.
Finance finds out at invoicing. The first time anyone outside sales sees the actual terms is when someone tries to bill against them. At that point the negotiating is over and the only options are to absorb it or to go back to the customer.
Deals stall waiting for an unowned decision. A deal sits for four days because nobody is sure who is allowed to say yes. The cost here is cycle time, and it is usually larger than whatever the discount in question was worth.
Discount distribution has no shape. Pull every closed won deal from the last two quarters and plot the discount percentage. If there is no visible clustering around thresholds, there are no thresholds.
The inverse is worth stating too, because deal desks get recommended reflexively. If you sell at list price on standard terms with one signature, a desk adds a step and removes nothing. The function is justified by the volume of genuine exceptions, and if that number is near zero the honest answer is that you do not need one yet.
The Deal Desk Process, Step by Step
A workable process has six stages. The named SLAs matter more than the stage count, because an approval process without a promised turnaround is a black box and reps treat black boxes as obstacles.
- 1
1. Submission
The rep submits the deal with everything needed to decide it: the proposed pricing, the discount and its justification, the term, the payment terms, and any non-standard clauses. The most common cause of slow desks is incomplete submissions, and the fix is a required intake rather than a stern reminder. If the CRM cannot enforce the fields, the intake is not real.
- 2
2. Triage
Sort by what the deal actually needs. A ten percent discount inside policy on standard terms needs one person and ten minutes. A multi-year commitment with custom liability language and a bespoke billing schedule needs three functions and a scheduled conversation. Triaging these into one queue is the fastest way to make a desk unpopular.
- 3
3. Parallel review
Send the deal to everyone who needs to see it at once rather than in sequence. Sequential routing is where days disappear, because each hop inherits the previous reviewer's response time. Reserve genuine sequencing for cases where a later approver's decision actually depends on an earlier one.
- 4
4. Structuring
Where the desk earns its existence. The answer to a deal that is not approvable as submitted is rarely no. It is usually a different shape: shorter term at the requested discount, requested term at a smaller discount, annual prepay instead of monthly, or a narrower scope. A desk that only returns yes and no is a filter, and filters get routed around.
- 5
5. Decision and record
Approve, and record who approved what, against which version, on what date. The version detail matters. An approval attached to a deal rather than to a specific quote is not evidence of anything once the numbers change, and the numbers usually change.
- 6
6. Booking check
Confirm the approved terms are the terms that entered the downstream systems. This is the stage everyone assumes is automatic and the one that produces the debooks and corrections that fill a deal desk's week.
What HubSpot Can Actually Enforce
HubSpot does not sell something called a deal desk, but it ships most of the enforcement machinery. The catch is that it is split across two objects, two subscriptions and two independently configured features, and teams routinely turn on one while assuming it covers the other.
| Quote approvals | Deal approvals | |
|---|---|---|
| Subscription | Revenue Hub Professional or Enterprise | Sales Hub Enterprise |
| Scope | Individual quotes matching property filters | An entire deal pipeline |
| Approvers | Up to 10 | Up to 10 per pipeline |
| Sequencing | Enterprise only, up to 5 sequences of 10 approvers | Not supported |
| Gate mechanism | Quote cannot be sent until approved | A Pending approval stage added to the pipeline |
| On rejection | Requester edits and resubmits | Deal can only move to closed lost |
The filters are genuinely capable. HubSpot documents approval criteria on quote properties including quote amount, total discount percent, net payment terms, terms, acceptance method and ESign enabled, and on line item properties including discount percentage, SKU, billing frequency, currency, tax and margin. You can also key on related-object properties, including a company or contact's country or region, which is how a policy that differs by territory gets enforced rather than remembered.
Deal approvals work differently and the difference is easy to miss. They attach to a pipeline rather than to a document, HubSpot adds a Pending approval stage automatically, and applicable deals must clear it before advancing. Setting it up requires Super Admin permissions, and the individual approvers need the Approve permission granted in the Deals section first.
The Gate Has Documented Holes
This is the part worth reading before you rely on any of it, because the exemptions are in HubSpot's own documentation rather than hidden in behaviour.
A sole approver approves themselves
HubSpot documents it plainly: if a designated approver creates a quote and they are the only approver, the quote will not require approval. In a small company this is not an edge case, because the person with the authority to approve discounts is frequently also the person closing the largest deals. The control is switched on and the deals that most need it are exempt.
The same hole, on deals
Deal approvals do not activate when there is no deal owner, or when the owner is a required approver. Same shape, different object. A deal created by an integration or an import with no owner assigned passes through the approval stage without approval.
Existing deals are grandfathered
Deals already sitting in a stage when approvals are configured are exempt. That is reasonable behaviour and it means the control starts empty. If you switch approvals on in week eleven of a quarter, the deals closing in week twelve are mostly not covered by it.
Rejection is terminal
A rejected deal can only be moved to a closed lost stage. There is no send-back-for-rework path at the deal level, so the natural workaround is to avoid ever formally rejecting, which turns the deal approval into a stage that everything eventually passes through.
There is also a subtler limitation that has nothing to do with configuration. An approver in HubSpot has two actions: approve, optionally with a message, or request changes with feedback. That covers most of what an approval tool needs to do, and it does not cover the answer a deal desk gives most often, which is yes, if. Yes, if they commit to twenty four months. Yes, if it is annual prepay. Yes, if legal removes the uncapped liability clause.
There is no button for a conditional approval, so the conversation moves to chat, the condition is agreed there, and the record in HubSpot says approved without saying what it was approved on condition of. That is not a HubSpot flaw specifically, most approval tooling shares it. It is the reason the approval log and the actual agreement diverge, and the reason booking checks exist.
The Number the Policy Depends On
Look again at the list of properties HubSpot lets you gate on. Margin is in there, on line items, and it is the most valuable rule available. A discount threshold is a proxy for the thing you actually care about. Margin is the thing itself. A twenty percent discount on a high-margin product may be fine, and a five percent discount on a low-margin one may not be, and only a margin rule can tell those apart.
HubSpot calculates margin automatically. It also calculates annual contract value margin, monthly recurring revenue margin and annual recurring revenue margin, each documented as the corresponding revenue figure minus the cost of goods sold.
Then check where the cost comes from. Unit cost is a line item and product property described as the cost of the line item to you, and it is entered manually. It is not calculated, and nothing populates it by default. It sits in your product library because somebody typed it there.
So the most sophisticated deal desk rule HubSpot offers depends on a figure that lives in your ERP, your accounting system or a spreadsheet in procurement, and reaches HubSpot only if somebody maintains it by hand. In practice that means one of three states. Unit cost is empty, so margin is meaningless and the rule cannot be used. Unit cost was populated once at product creation and never revisited, so margin is confidently wrong in a direction nobody has checked. Or somebody genuinely maintains it, in which case it is accurate and the maintenance is a standing manual job that breaks the moment that person changes role.
This is the shape that recurs across every HubSpot governance feature: the counting is free and correct, and the input to the count is somebody's afternoon. The same pattern shows up across a portal review, which the HubSpot audit guide covers in more detail.
The fix is not exotic. Unit cost is a field, your ERP or accounting system knows it, and a sync that maintains it is a small integration by any measure. What makes it worth doing is leverage: it is the difference between a discount policy and a margin policy, and those are not the same control. If the cost data lives in NetSuite or QuickBooks, the NetSuite integration guide and the QuickBooks integration guide cover what the native connectors do and do not move.
Deal Desk vs Sales Ops vs RevOps vs CPQ
These four get used interchangeably and they are genuinely different things.
Sales operations owns the system
Pipeline stages, required fields, territories, quotas, forecast structure, reporting. Standing configuration that applies to every deal. The output is a process.
The deal desk owns the exceptions
Whether this particular deal, at this discount, on these terms, is one the company should sign. The output is a decision. The two meet when a decision repeats often enough to become configuration, which is the healthy handoff.
RevOps owns the whole revenue system
Marketing, sales and customer success operations under one function, including the data and tooling that spans them. Both of the above usually sit inside it in a company large enough to have one. The RevOps guide covers the scope properly.
CPQ is software, not a function
Configure, price, quote: tooling that produces an accurate quote from a complex product and price book. It can enforce a deal desk's policy and it cannot decide one. The CPQ guide covers what the three letters actually mean and which part is the commodity.
The practical error is buying CPQ to avoid making the policy decision. Configurable approval rules with no agreed thresholds produce an automated version of the ambiguity you already had, at a higher cost and with more implementation time.
How to Measure a Deal Desk
Two numbers carry most of the signal.
Turnaround time from submission to decision. This is what reps experience and it determines whether the desk is used or bypassed. A desk that answers in hours gets used. A desk that answers in days gets routed around by anyone with a relationship with an approver, and once that happens the approval data stops describing reality.
Exception rate, meaning the share of deals that reach the desk at all. This one measures the policy rather than the desk. A high rate means the thresholds are set too tight and the desk is processing routine business. A rate near zero means either the policy is generous and well calibrated, or nobody is submitting.
Below those, the useful measures are discount distribution over time (is dispersion narrowing), approved-versus-booked variance (do the terms survive to the invoice), and rework rate (how often a deal makes a second pass). Standard sales metrics like cycle time and win rate are worth watching, but too many other things move them to attribute the movement to the desk.
When a Deal Desk Becomes an Integration Problem
A deal desk is a decision-making function, so it is easy to treat as an organisational question. It stops being one at a specific and identifiable point: when the decision requires data the CRM does not hold.
Four questions come up on almost every non-standard deal, and each of them is answered somewhere other than HubSpot.
The questions that cross a system boundary
What is the margin on this configuration? Requires unit cost, which lives in the ERP or accounting system and reaches HubSpot only if something maintains it.
What does this customer already pay us? Requires current subscription and invoice history, which lives in the billing system. Discounting an expansion without knowing the existing rate is guessing.
Have we agreed these terms before? Requires the executed contract, which lives in the e-signature tool or a document repository. What comes back to the CRM after signature is often a status and a PDF link rather than the negotiated values, which the PandaDoc and Docusign integration guides cover in detail.
Did the approved terms survive to the invoice? Requires reading the billing system's version of the deal and comparing it to the CRM's. This is the booking check, and doing it by hand is what fills a deal desk analyst's week.
None of those are approval problems. They are all the same problem: the decision needs a value that another system owns, and the value either arrives late, arrives stale, or arrives as a human copying it across. When a deal desk feels slow, it is usually worth checking whether the delay is people deliberating or people looking things up.
Is your deal desk slow because people are deciding, or because they are looking things up?
Most approval delay is not judgement, it is somebody opening a second system to find a number. StackTie builds the integrations that put those numbers where the decision happens: unit cost from your ERP so margin rules mean something, current subscription and invoice state from billing, and negotiated terms written back from the e-signature tool instead of stopping at a PDF link. The audit call is free and ends in a written list of what is worth building and what is not. If a build is the answer, live in 14 days or your money back.
The Bottom Line
A deal desk is a written policy plus a named exception path. Get the policy right and the desk stays small, because the policy determines how many deals reach it. Skip the policy and no amount of approval tooling helps, because configurable rules with no agreed thresholds just automate an argument.
HubSpot supplies real enforcement, split awkwardly across quote approvals on Revenue Hub Professional and Enterprise and deal approvals on Sales Hub Enterprise, with sequenced approvals reserved for Revenue Hub Enterprise. The filters are capable and the documented exemptions are worth knowing about before you trust them: a sole approver skips their own quote approval, deals without an owner skip pipeline approval, existing deals are grandfathered, and a rejected deal can only go to closed lost. The tooling also has no conditional approval, so the most common real answer a desk gives leaves no trace in the system that recorded the approval.
The deeper constraint is the data. HubSpot will happily gate a quote on line item margin, and margin is computed from a unit cost that somebody types in and nothing keeps current. That is the whole pattern in one field: the arithmetic is free and exact, the input is manual and quietly ages, and the control built on top inherits the weakness of the input rather than the strength of the calculation.
So write the policy first. Turn on what HubSpot can enforce, knowing where the gaps are. Then fix the inputs, starting with the one number that turns a discount policy into a margin policy. That is the part that is actually an engineering problem, and it is a small one.
