Discount and promise guard: no discount or delivery date without the evidence on the card
How the Discount and promise guard holds each proposed discount or commitment for a person, with the forecast's record and CommitOps's answer to whether the date can be met.
The Discount and promise guard is a workflow for revenue teams, and for the finance and engineering leads who live with what sales offered. When a rep or a sales agent proposes a discount or a delivery date, the guard holds it for a person. The person will see the deal’s forecast record and the CommitOps answer to one question: can we promise this by then? Sales as Code, PromptCompute and CommitOps each do a part.
The hold in Sales as Code is built. The PromptCompute card and the CommitOps promise are still to go.
The problem
Reps and sales agents offer discounts and dates to close deals. That is their job. The trouble is who finds out, and when. Finance learns about the discount when the invoice goes out. Engineering learns about the date when the customer asks why the feature is late.
An AI sales agent makes the gap wider. It drafts proposals quickly, and if nothing stops it, a proposal with a discount and a date reaches the customer before anyone who owns the margin or the roadmap has seen it.
How the workflow solves it
The guard puts a person between the proposal and the customer, and will give that person the evidence. Sales as Code holds every proposed discount and commitment. CommitOps answers whether the date can be met, from the work behind it. PromptCompute will show both on one approval card, next to the forecast’s odds and the drivers behind them. Once the person approves a commitment, CommitOps will record it as a promise with its due date, so it will be tracked from that moment.
When CommitOps cannot tell, the card will say so in plain words, and the default action on the card will be reject. A date nobody can check will not go out by default.
Step by step
When the workflow runner ships, a run will take these steps. Present tense means the part works in its product today; “will” means it is still to build.
A run will start when a rep or an agent proposes a discount or a date on a deal.
- Sales as Code holds the proposed discount or commitment for a person. Local approval is on, so the proposal waits inside Sales as Code until someone decides.
- CommitOps answers whether the date can be met. Its answer is one of four: shipped, projected before the date, projected after it, or cannot tell. It already gives the same answer on HubSpot, Salesforce and Attio deal cards and in Slack.
- PromptCompute will show the forecast record and the CommitOps answer on the approval card. The approver will see the deal’s odds, the drivers behind them, and whether the date holds.
- CommitOps will record the promise once approved, with its due date, as a promise it then tracks to kept or broken.
Sending the proposal itself is a separate approval, under sales.proposal.send, so an approved discount still does not reach the customer until someone sends it.
What the workflow will report
Each run will report:
- The share of discounts approved with evidence attached. The plan sets the target at 100%.
- The promises made that CommitOps had marked cannot tell.
- The kept rate of promises made through the guard.
The second number will show how often the team commits without evidence. The third will tell you whether the guard is worth having, because you will be able to compare it with the kept rate of promises made outside it.
Why it matters to a revenue team
A discount approved on evidence protects margin, and a date checked against the work protects the renewal. The guard will put the forecast and the delivery answer in front of the approver at the moment they decide, instead of in a meeting after the contract is signed.
For a founder who sells, it will also mean the sales agent can draft proposals freely, while everything that commits the company waits for you.
How to set it up
Outside the family you connect your CRM: HubSpot, Salesforce or Attio.
When the runner and the signed-in app ship, setup will be:
- Sign in with PromptReports ID and pick your org.
- Connect Sales as Code, PromptCompute and CommitOps, and link the CRM through Sales as Code.
- Register the agent that drafts proposals, if one does.
- Set the approval policy for approving a discount (
sales.discount.approve), approving a commitment (sales.commitment.approve) and sending a proposal (sales.proposal.send). All three default to high risk; start each at Require approval. - The trigger is a proposed discount or date, so there is nothing to schedule. Start a dry run on an open deal.
- Approve or reject each proposal from the card.
An agent will start or follow a run through the PromptReports MCP server or API, with the proposed start_run and get_run tools.
The guard is on every plan. Plans are per user per month: $25 for 100 workflow requests, $50 for 500, and Enterprise above 500. There is no free tier. Each proposal held and decided is one request.
Today the hold works inside Sales as Code alone, and CommitOps answers the date question on deal cards and in Slack. An approver reads the two side by side rather than on one card.
What is built today and what is planned
The workflows page lists the guard as partly built: all three parts are merged, the CommitOps promise is switching on, and the runner is still to go.
Built:
- Sales as Code sends discount and commitment proposals for approval with the deal evidence (Sales-Intelligence #2812).
- PromptCompute takes those discount and commitment approvals with the deal evidence Sales as Code read (promptcompute.ai #221).
- CommitOps turns an approved commitment into a tracked promise with its due date (commitops #152). It is off behind a setting and switching on.
- CommitOps answers can-we-promise from Slack and from HubSpot, Salesforce and Attio deal cards.
Still to go:
- The workflow runner. No runner exists today. The plan is a durable runner service in the PromptCompute stack, with one run id across products, approvals as steps, and each run metered as one workflow request.
Read more
This post has no record on AI Source of Truth yet. Once it does, its verdict badge shows here and links to the record.