Discount requests arrive in Slack at 6pm on the last day of the quarter. Here is the model behind a deal desk that can handle that, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A deal desk approval app is four parts: a request that captures the full deal economics, a routing ladder set by discount depth and contract value, an approver view with real context, and an exception record. The failure mode is speed: a deal desk that takes two days at quarter end gets routed around, and once it is routed around it stops being a control. Optimise for time to decision, not for thoroughness.
Deal desk
7
Waiting on you
41 min
Median to decision
22%
Median discount
4
Above the ladder
Brightsea
135K · 12%
Fenwick
48K · 9%
Kestrel Ltd
64K · 18% · 12 min
Halden Foods
410K · 27% · 1 day
Northrise
240K · 32% · 3h
Vantor
88K · 41% · 6h
You run a deal desk, revenue operations or sales finance. You already know your discount ladder. What you want is for reps to get an answer in minutes instead of a day, and for you to be able to answer what your discounting actually cost last quarter.
What a rep and an approver each do, and why speed is the whole design.
Entering the numbers shows which tier the request lands in and what the next tier down would need. Most requests shrink at this point.
List, proposed, term, payment terms, ramp and committed volume. A percentage alone hides the difference between a small deal and your largest contract.
A ladder based on both, published in the app, so nobody has to ask who approves what.
Account history and what comparable deals cleared at, on the same screen. Seeing that similar deals closed at 18 percent makes a 30 percent request answer itself.
Every approver has a deputy and requests reroute automatically. Quarter end is when this matters and when people are least reachable.
Which turns a quarter of individual decisions into a discount policy conversation you can actually have.
A deal desk app is not an approval chain with a discount field. It is four parts, and the first one is where most implementations go wrong.
List price, proposed price, discount percentage and absolute amount, term length, payment terms, ramp structure, committed volume, and any non-standard terms. Discount percentage alone hides the deals that matter.
Who approves what, based on discount depth and contract value together, with a clear ceiling for each level. Published in the app so reps know before they ask.
Everything needed to decide on one screen: the request, the account history, what similar deals got, and the margin impact. An approver who has to open the CRM will approve later, which means slower.
What was approved, by whom, when, and why, with the reason chosen from a fixed list. This is the artefact that lets you change the discount policy with evidence rather than opinion.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Capturing what an approver needs, and shrinking the ask before it is made.
In this Helix project, build me a deal desk approval app.
A rep asks for a discount, so capture what the discount actually is: list
price, proposed price, term length, payment terms, any ramp, committed
volume, and any non-standard terms. Derive the discount percentage and
amount from the prices so a rep cannot enter them inconsistently.
Keep the approval ladder in one editable file: tiers defined by discount
depth and contract value together, each with an approver role and a
ceiling. Not depth alone. Thirty percent off a small deal and off our
largest contract are different decisions.
Then do the one thing that changes behaviour: as the rep types the
numbers, show them which tier they are about to land in and what the next
tier down would require. A rep who can see that 24 percent clears one
approver and 26 clears three will usually ask for 24.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Showing the tier before submission is the cheapest discount control that exists, and it costs one screen.
Everything needed to decide, without opening the CRM.
Now the screen an approver opens, and treat time to decision as the thing
you are optimising.
Show the economics: list, proposed, discount as percentage and amount,
annual and total contract value, term, and margin impact if I give you a
cost basis. Show what we have sold this account before and what discounts
they have had. And show comparable deals: what similar-sized deals in this
segment were approved at, with the median and the range.
That comparables panel changes approver behaviour more than any policy
document, so make it prominent.
Actions: approve, approve at a lower figure they counter with, reject, or
ask the rep a question without ending the request.Deputies, escalation, and the metric that tells you if this is working.
Route each request through every approver its tier requires, in sequence,
and stop the chain on the first rejection.
Give every approver a named deputy, and reroute automatically after a
number of hours I set. Quarter end is exactly when people are travelling
and exactly when this matters.
Track time to decision per request, per approver and per tier, and put it
on a dashboard. A desk that takes two days in the last week of a quarter
gets routed around, and once it is routed around it has stopped being a
control. That number is the early warning.Reason codes, and the report they make possible.
Every approval and rejection records who, when, the figure approved, and a
reason chosen from a short fixed list plus free text. Keep the list to
about six options and make it editable. Free text alone produces a log
nobody can summarise, which is why discount policy never changes.
Append an audit entry for every state change with a snapshot of what the
approver saw.
Then report: total discount granted by quarter, segment, rep and reason.
Median discount by tier. And a single list of every deal approved above
the standard ladder, which is where a discount policy review should
start.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Salesforce>. Read the opportunity, the account history and comparable
closed deals, then write the approved pricing back.
<Salesforce CPQ>. Read list price and any ramp structure, so the discount
is calculated rather than typed.
<Slack>. Reach an approver at quarter end, which is when speed is the
whole point.
<Okta>. Read the manager chain and group membership, so the approval
ladder is derived from the real org rather than a hardcoded list of names.
<Gong>. Read what was actually said on the call, which is often the
justification a rep did not write down.
<DocuSign>. Read whether the quote at the approved discount was ever
signed, which closes the loop on exceptions.
<Snowflake>. Land each approved exception beside the closed deal, which is
what turns whether we are discounting more than last year into a query.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Set Access Control before sharing: reps see their own requests, the desk sees everything.
A deal desk lives next to the CRM. Almost everything an approver needs to decide is already in it.
Salesforce
Read the opportunity, the account history and comparable closed deals, then write the approved pricing back.
Salesforce CPQ
Read list price and any ramp structure, so the discount is calculated rather than typed.
Slack
Reach an approver at quarter end, which is when speed is the whole point.
Okta
Read the manager chain and group membership, so the approval ladder is derived from the real org rather than a hardcoded list of names.
Gong
Read what was actually said on the call, which is often the justification a rep did not write down.
DocuSign
Read whether the quote at the approved discount was ever signed, which closes the loop on exceptions.
Snowflake
Land each approved exception beside the closed deal, which is what turns whether we are discounting more than last year into a query.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working desk. It reads CRM data, decides what pricing gets offered, and produces the record a revenue audit asks for, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Discount authority maps to real roles. SSO means approvers sign in with their existing account, and access is scoped so a rep sees their own requests while the desk sees everything.
App Security
Reading opportunities and writing approved pricing back needs real CRM access. Granting it to the app rather than pasting a key into it means it can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It routes non-standard pricing requests to the right approvers based on discount depth and contract value, gives those approvers the context to decide quickly, and records every exception with its reason. It is a control that only works if it is fast enough to use.
The full economics: list and proposed price, discount as both a percentage and an amount, term, payment terms, ramp, committed volume and any non-standard terms. Percentage alone hides the difference between a small deal and your largest contract.
On discount depth and contract value together, in a published ladder with a ceiling per tier. Routing on percentage alone sends trivial deals up the chain and lets large ones through at the same threshold.
Because they are slow at quarter end, which is exactly when reps have least tolerance for waiting. Measure time to decision from the first day and set up deputies for every approver, or the desk quietly stops being a control.
A short fixed list of reasons alongside the free text. Free text alone produces a log nobody can summarise, so the discount policy never changes. Six reason codes make a quarter of decisions readable in one chart.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are your ladder thresholds and your reason codes, and neither is something a tool can decide for you.
Sales and RevOps
Find the opportunities distorting your forecast, name who owns each fix, and make hygiene a short weekly list rather than a quarterly clean-up. Prompts to build it, and what it takes to run it.
Sales and RevOps
Calculate commission from the plan rather than from a spreadsheet nobody can audit, show every rep how their number was reached, and handle the disputes as data. Prompts to build it, and what it takes to run it.
Legal and Compliance
One front door for legal work, with enough detail captured up front to triage it, a queue with priorities, and self-service for the requests that do not need a lawyer. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.