deal-desk-approval

{
  "skill_name": "deal-desk-approval",
  "evals": [
    {
      "id": 1,
      "prompt": "I run RevOps at Verrick Analytics, B2B SaaS, about $28M ARR, median ACV $34K, fully sales-led. Our AEs discount whatever it takes and every exception lands in the CFO's inbox as an email. I want a real approval matrix. I found a template online that looks sensible: under 15% auto-approved, 15-25% goes to the VP Sales, above 25% to the CRO and CFO jointly, plus a 75% gross margin floor as the hard stop nobody crosses. We have seven quarters of closed-won and closed-lost in the CRM with a discount percentage on every deal. Build me the matrix.",
      "expected_output": "An approval matrix spec that refuses the imported ladder and the 75% floor as fact, derives the auto-approve floor from Verrick's own win-rate-by-discount-band data, governs all five concession levers, carries a prohibited class and an approver-independent margin floor, and tags every threshold with provenance.",
      "files": [],
      "expectations": [
        "Does not adopt the under-15% / 15-25% / above-25% ladder as the recommended tier boundaries",
        "Identifies the 75% gross-margin floor as a circulating, unattributed number rather than an industry benchmark, and does not use it as the floor",
        "Recommends deriving the auto-approve floor from Verrick's own win rate by discount band, using its seven quarters of closed-won and closed-lost deals",
        "States that win-rate derivation ranks above a discount-distribution percentile, which in turn ranks above an illustrative placeholder",
        "Explains that a distribution percentile encodes past rep behaviour, discount creep included, as policy",
        "Governs all five concession levers, naming price/discount, payment terms and billing, services and delivery commitments, contract risk, and security/privacy commitments",
        "Requires every non-price concession to be converted into an equivalent economic or discount-equivalent value so approvers can compare it against discount",
        "Includes a prohibited class no tier may approve, naming at least MFN/best-price guarantees, open-ended price holds, uncapped liability outside pre-approved carve-outs, and roadmap commitments lacking Product and Delivery pre-approval",
        "States the margin floor is approver-independent and that no tier waives it",
        "Tags each numeric threshold in the output with its provenance: derived from the company's own data, house policy, or illustrative"
      ]
    },
    {
      "id": 2,
      "prompt": "Kessel Docs sells two things. One is an AI contract-extraction product where inference and OCR cost us roughly 41 cents per document processed, and gross margin on that line swings between 48% and 62% depending on how heavily a customer runs it. The other is an older seat-based review module that costs us essentially nothing per additional seat. Our CFO wants one hard floor written into the approval policy so no approver can go below it. What floor do we write?",
      "expected_output": "Separate floors per product family: a policy margin floor for the near-zero-COGS seat module, a cost floor that genuinely binds on the usage-scaling AI line, both derived from Kessel Docs' own costs and both approver-independent.",
      "files": [],
      "expectations": [
        "Sets separate floors per product family rather than a single company-wide floor",
        "States the binding floor for the near-zero-marginal-cost seat module is a policy margin floor, not a cost floor",
        "Explains that near-zero marginal cost puts a cost floor far below any price anyone would accept, so it binds nothing",
        "States the usage-scaling COGS of the AI extraction line makes a cost floor rise and genuinely bind there",
        "Recommends verifying the usage-scaling treatment against Kessel Docs' own unit costs",
        "States the floor is approver-independent and that no tier waives it",
        "Derives the floor from Kessel Docs' own COGS and target model rather than from an imported number",
        "Does not present a 75% gross-margin floor as a standard or benchmark",
        "Includes margin impact as a matrix dimension where per-deal margin is computable, treating discount percentage as its proxy"
      ]
    },
    {
      "id": 3,
      "prompt": "I'm head of RevOps at Halden HR, SaaS, around $40M ARR, customers in the US and the UK. Our CFO read something about price discrimination and now wants every discount above 20% to get a legal review before approval, because two customers in the same industry could end up paying different prices for the same product. He wants a compliance sign-off step added to the approval chain for exactly that reason. Write it into the approval design.",
      "expected_output": "A design that declines to build discrimination-driven approval friction, explains why Robinson-Patman and the dominance-gated EU/UK regimes do not reach a non-dominant SaaS vendor's differential discounting, names the residual caveats, and keeps Legal routing only where structures actually require it.",
      "files": [],
      "expectations": [
        "States the Robinson-Patman Act does not reach ordinary SaaS differential pricing",
        "Gives the reason: the Act covers commodities rather than services, and purchases rather than leases",
        "States the EU and UK discriminatory-pricing prohibitions, Article 102 TFEU and Chapter II of the UK Competition Act 1998, are gated on dominance",
        "Concludes that a non-dominant B2B SaaS vendor is not meaningfully constrained from charging different customers different prices",
        "Advises against adding a discount-percentage-triggered legal or compliance review for the price-discrimination concern",
        "Names the residual caveats: general antitrust theories, sector or public-sector procurement regimes, and MFN clauses the vendor itself signed",
        "States MFN and best-price clauses are a self-inflicted constraint and belong in the prohibited class",
        "Declines to give legal advice and routes any actual legal question to counsel",
        "Keeps Legal routing for the structures that do require it, such as termination-right changes, novel redlines, and prohibited-class terms, instead of removing Legal from the chain"
      ]
    },
    {
      "id": 4,
      "prompt": "I run the deal desk at Mirrowind, about 600 quotes a quarter. Our reported average turnaround is 6 business hours and leadership is delighted with it. But our CRO says reps are closing verbally and submitting for approval afterwards. Today the timer starts when an analyst opens the ticket and stops when the analyst clicks approve, and when a request is missing fields we chase the rep while it sits in the queue. Redesign the SLAs and how we report them.",
      "expected_output": "Two SLA clocks with precise start and stop definitions in business hours, a completeness gate that bounces rather than queues incomplete requests, 50/80/100 elapsed escalation, and reporting switched from mean to median plus p90.",
      "files": [],
      "expectations": [
        "Replaces mean cycle time with median and 90th-percentile reporting",
        "Identifies the p90 tail as what drives the bypass behaviour the CRO described",
        "Defines two separate clocks: a response clock and a decision clock",
        "Starts the clock when required fields are complete in the system of record, not when an analyst opens the ticket",
        "Stops the clock when the decision is recorded and communicated, not when the analyst clicks approve",
        "States the clock does not stop when a reviewer replies with a clarifying question",
        "States both clocks run in business hours",
        "Bounces incomplete submissions instead of letting them sit in the queue, with the completeness gate holding the clock",
        "Specifies a structured bounce that lists the missing items, the business impact, the responsible party, and resubmit instructions",
        "Defines 50/80/100 percent elapsed-SLA escalation and the action taken at each of the three points"
      ]
    },
    {
      "id": 5,
      "prompt": "Tallowpine is a self-serve design tool, $19 to $79 a month, about 41,000 paying accounts. Two people handle anything above $8K a year. Right now support hands out 30% loyalty discounts whenever somebody threatens to cancel, customers stack coupon codes on top of our annual discount, and our promo codes keep turning up on coupon aggregator sites. Build us a deal desk with approval tiers so this stops.",
      "expected_output": "A rules-driven discount policy rather than a human approval chain: published bands, promo-engine-enforced stacking rules, a fixed-menu save offer, the sales-assist handover line, and creep monitoring.",
      "files": [],
      "expectations": [
        "States no human deal desk exists below the sales-assist line and does not invent approval tiers for the self-serve motion",
        "Delivers a rules-driven discount policy instead: published discount bands, promo and coupon governance, and exception rules published in the terms",
        "Blocks coupon stacking in the promo engine rather than by support judgment",
        "States support may not invent discounts",
        "Requires every published rule to state its own exception path, so the answer to an unlisted ask is no",
        "Makes save and win-back offers a fixed menu, logged per account, and frequency-capped",
        "Makes promo codes single-use, expiring, and capped per campaign budget",
        "Sets the human line at the $8K-per-year sales-assist threshold, above which a B2B approval matrix takes over",
        "Includes creep monitoring covering at least share of revenue on any discount, average realized discount, coupon-leakage checks against aggregator sites, and save-offer redemption against churn saved",
        "Presents the contrast between the two motions as reasoning about how the mechanics carry across, not as a documented industry finding"
      ]
    },
    {
      "id": 6,
      "prompt": "Setting up routing at Brandenholt Systems. My proposal: deals under $25K go to a fast lane, $25K to $150K to a complex lane, anything above $150K to an exception lane. And in the last three weeks of a quarter we drop the two-lever review rule down to one lever so quotes keep moving. For context, last quarter 41% of the full year's discount value was granted in those final three weeks. Sanity check this and write the final routing rules.",
      "expected_output": "Routing rules where structural risk rather than deal size forces the lane, the exception lane protected from fast-lane widening, and a quarter-end peak mode that adds capacity and cutoffs while leaving the rules untouched.",
      "files": [],
      "expectations": [
        "Rejects deal size as the criterion that forces the lane",
        "States that structural risk is what forces the lane",
        "Gives the contrast that a large deal at list price on standard terms needs no review, while a small deal with a custom indemnity clause does",
        "Routes below-floor economics, prohibited terms, novel security obligations, and high-precedent structures to the exception lane regardless of deal size",
        "States the design goal is to move volume into the fast lane, which should carry the bulk of cases",
        "Names the starvation risk that a desk measured on cycle time widens fast-lane guardrails until precedent-setting structures slip through",
        "Refuses the quarter-end relaxation of the lever-count review rule",
        "States peak mode adds capacity and clarity only, leaving the completeness gate and the approval matrix intact",
        "Names peak-mode components including extended coverage, published completeness cutoffs for same-day handling, and dedicated executive escalation windows",
        "Identifies the period-end concentration of discounting as the signature of undisciplined rather than strategic discounting",
        "Names earlier deal shaping upstream as the durable fix rather than crunch-time exceptions"
      ]
    },
    {
      "id": 7,
      "prompt": "Sixgrain Robotics, about 90 deals a quarter, and I am the only RevOps person here. The desk gets maybe a day and a half of my week in total, and that is not going to change this year. Nothing is formally carried over at renewal today, but last year three customers cited a one-time 25% we granted them in 2024 as the price they now expect, and we caved on two of them. I'm writing the policy this week. What happens to a granted exception when the contract comes up for renewal?",
      "expected_output": "Sunset as the default renewal treatment, step-up removed because the one-person desk cannot fund per-account tracking, silent grandfathering excluded outright, treatment decided at grant time and recorded as house policy, with an expiry on every exception.",
      "files": [],
      "expectations": [
        "Recommends sunset as the default renewal treatment",
        "Justifies sunset as recovering the whole concession for near-zero standing effort while remaining reversible",
        "Removes step-up from the options given the stated effort ceiling, rather than listing it as a lower-ranked choice",
        "Explains step-up's cost as per-account tracking across one to two renewal cycles, a standing job for whoever owns the register",
        "States explicitly which answer moved the ranking, naming the desk's effort ceiling",
        "States the condition that would promote step-up anyway: a price snap-back that has already driven churn or escalation in that segment",
        "Excludes silent grandfathering entirely rather than ranking it last among the options",
        "Requires the renewal treatment to be decided at grant time, per exception class, never at the renewal itself",
        "Time-boxes every granted exception with an expiry date written into the original approval",
        "States that published guidance on renewal treatment is thin, so the choice is decided with the user and recorded as house policy",
        "Specifies exception register fields including expiry or sunset date, a renewal-exposure flag, and tracking of whether the exception was later cited as precedent"
      ]
    },
    {
      "id": 8,
      "prompt": "Ferrolane Security, 380 renewals a year, three people on the deal desk. Roughly 60% of our renewal book carries a discount somebody granted years ago with no end date on it. Two years ago we snapped our mid-market segment back to list at renewal and lost 4 of the 11 accounts we tried it on. Our CRO owns pricing policy and will fight anything that tightens the bands. Design the renewal-exception fix.",
      "expected_output": "Step-up promoted above sunset for this situation on the evidenced snap-back churn and the grandfathered book, its tracking cost accepted, silent grandfathering still excluded, and floors derived from Ferrolane's own data to survive the CRO's veto.",
      "files": [],
      "expectations": [
        "Promotes step-up above sunset for this situation and says so explicitly",
        "Names the snap-back that already drove churn in that segment as the evidence promoting step-up",
        "States that a renewal book already full of grandfathered terms makes sunset a re-negotiation rather than an expiry",
        "Accepts step-up's standing cost of per-account tracking across one to two renewal cycles",
        "Excludes silent grandfathering as an option",
        "States the CRO's veto over policy raises the political cost of tightening any floor",
        "Recommends floors derived from Ferrolane's own deal data precisely because the CRO cannot argue with them",
        "Requires an expiry date on every exception granted from now on",
        "Anchors renewal pricing to the last contract period's price for ramped or staged deals",
        "States the ordering is a default re-ranked against Ferrolane's situation rather than a fixed rule"
      ]
    },
    {
      "id": 9,
      "prompt": "Live deal at Corvane Systems: $900K over three years, bundled as platform subscription plus $180K implementation plus training. The customer wants the entire 22% discount applied to the implementation line so the platform price stays at list, because their board only looks at software list price. They also want a written promise of the same 22% at their renewal, they want to prepay years two and three at signature, and they want a 60-day termination-for-convenience right. My VP Sales says all four are painless paperwork. Our Tier 2 is VP Sales plus Finance. Can Tier 2 approve this?",
      "expected_output": "A routing answer: Tier 2 cannot approve alone because each of the four elements routes to Finance or to Legal and Finance first, with the reason for each routing stated as a design constraint rather than accounting advice.",
      "files": [],
      "expectations": [
        "States Tier 2 cannot approve this on its own, because routing happens before any tier approves",
        "Routes the line-item-steered discount to Finance",
        "States the discount is allocated proportionately across all performance obligations by relative standalone selling price, regardless of which line the quote names",
        "States that specific allocation instead requires observable evidence: observable standalone selling prices, an observable bundle price, and a discount matching what the allocation would produce",
        "Routes the promised renewal discount to Finance at any deal size",
        "Identifies the promised renewal discount as a possible material right, a separate performance obligation that defers part of today's revenue",
        "Routes the termination-for-convenience change to Legal and Finance together",
        "States the enforceable contract term may shrink to the 60-day notice period despite the paper saying three years",
        "States the accounting consequence of a termination-for-convenience right is usually larger than the legal one",
        "Notes that a substantive termination charge, or full upfront payment with no clawback right, preserves the full term",
        "Routes the multi-year prepay to Finance for a possible significant financing component"
      ]
    },
    {
      "id": 10,
      "prompt": "Oakbell Cloud is adding resellers and MSPs next quarter, and partners will set their own end-customer prices. I want to copy the partner tier structure AWS and Microsoft use, since it is proven at that scale, straight into our approval matrix. Separately, one MSP is asking for pay-when-paid terms, which our finance analyst says is just a payment-terms tweak. Write the channel section of our deal desk policy.",
      "expected_output": "A channel section that refuses to import partner-program tiers as an approval matrix, adds channel-specific intake (route to market, deal registration, per-channel order forms) routed to partner management, labels the thresholds as house policy, and escalates pay-when-paid non-delegably to Finance leadership.",
      "files": [],
      "expectations": [
        "Refuses to import AWS, Microsoft, Google Cloud, or Salesforce partner-program tier structures as a deal-desk approval matrix",
        "Explains those programs govern the wholesale discount or margin the vendor extends to the partner, not case-by-case approval of what the partner charges the end customer",
        "Designs the channel thresholds explicitly with the user and labels the result as house policy",
        "Adds separate quote or order-form templates per channel type such as authorized reseller, MSP, and distributor, alongside the standard order form",
        "Adds a route-to-market intake field distinguishing direct, channel, and marketplace",
        "Routes channel and marketplace deals to partner territory or partner account managers rather than to the standard deal-desk analyst lane",
        "Includes deal registration as the channel-specific intake gate with no analog in the direct motion",
        "Escalates the pay-when-paid clause non-delegably to Finance leadership",
        "States that pay-when-paid shifts the vendor toward acting as a lender",
        "Treats the payment-terms ask as a concession requiring a priced trade rather than an administrative request"
      ]
    },
    {
      "id": 11,
      "prompt": "Six months since we launched the desk at Pellmoor Data. Median decision time is 3.1 business hours, p90 is 5 hours, and 94% of submissions get approved. Meanwhile discount rate is up 4 points and gross margin per deal is down 2 points since launch. The board wants one headline number and my desk lead says the cycle time proves the desk is working, and wants two more analysts to keep it there. What do I take to the board?",
      "expected_output": "A refusal to report cycle time alone, the five-KPI scoreboard presented together, the near-instant approvals read as an over-approval signal calling for a higher auto-approve floor rather than headcount, plus the supporting exception, late-discovery, and price-realization metrics.",
      "files": [],
      "expectations": [
        "Refuses to report cycle time as a single headline number for the desk",
        "Names all five scoreboard KPIs: cycle time, win rate, discount rate, margin, and leakage",
        "States that a speed-only view approves bad deals fast while a margin-only view produces gridlock and reps routing around the desk",
        "Reads the near-instant approvals and 94% approval rate as a signal that too many things require approval",
        "Recommends raising the auto-approve floor in response to that signal",
        "Does not recommend adding analysts as the fix for the near-instant-approval signal",
        "Flags the rising discount rate and falling per-deal margin as the erosion that the speed metric hides",
        "Adds exception rate by type as the pattern-to-policy trigger",
        "Adds late-discovery rate, non-standard terms surfacing after proposal, as an intake-gap indicator",
        "Adds price realization measured as pocket price over list price",
        "States the counterpart calibration rule: a p90 beyond the exception-lane SLA means the tiers are wrong and must be re-cut"
      ]
    },
    {
      "id": 12,
      "prompt": "At Windmere Labs I want one approval framework and one tool covering four things: sales discount exceptions, marketing campaign spend sign-off, new-hire offer approvals, and engineering change requests. Same matrix, same tiers, same SLAs for all of it. On the sales side, most exception requests just say the customer asked for it in the justification box, and 43% of last quarter's exceptions were tagged strategic. Also tell me what our new pricing tiers should look like while you're in there.",
      "expected_output": "A scope refusal for the three non-deal approval domains and for pricing tiers, plus an intake redesign that weights impact of denial highest, splits justification into economic and strategic fields tied to the specific ask, and separates strategic from tactical discounting.",
      "files": [],
      "expectations": [
        "Declines to cover marketing campaign spend sign-off, new-hire offer approvals, and engineering change requests",
        "States the desk governs deal-level commercial approvals only and that general business-process approvals are out of scope",
        "Declines to design pricing tiers and packaging, routing that out as pricing strategy rather than deal desk scope",
        "Rejects \"the customer asked for it\" as a justification",
        "Makes impact of denial the highest-weight intake field and defines it as what changes if the exception is refused",
        "Splits justification into separate economic-upside and strategic-upside fields",
        "Requires each justification field to tie to the specific exception requested rather than to the account overall, so a strategic logo does not justify every concession",
        "Requires the request to state what the company gets in exchange for the ask",
        "Separates strategic discounts, executive-approved and logged with their rationale, from tactical bands",
        "Flags that at 43% of exceptions tagged strategic the label carries no meaning"
      ]
    },
    {
      "id": 13,
      "prompt": "Three things are stuck in the Ashgrove Systems queue. A 500-seat prospect wants a six-month free proof of concept. A second customer wants a custom SLA with uncapped service credits. And we take roughly 14 MSA redline sets a quarter, all of which sit two weeks each on our single in-house lawyer's desk. Our VP Sales wants standing authority to approve all three categories so the queue clears. Draft the policy for these.",
      "expected_output": "A policy that time-boxes the POC with its explicit no-charge, IP, and revenue-treatment controls, escalates uncapped credits instead of granting VP authority, and moves redline volume onto a fallback library with three-track routing.",
      "files": [],
      "expectations": [
        "Time-boxes the proof of concept and recommends a paid pilot beyond roughly 90 days",
        "Requires \"at no charge\" to be stated explicitly, to prevent an implied-payment claim",
        "Requires foreground-IP ownership to be settled up front",
        "Requires Finance sign-off on the ARR or revenue treatment of the eventual conversion",
        "Refuses standing VP authority over the uncapped service credits and escalates them to leadership",
        "States a custom SLA stays non-escalated only when credits are capped at the standard tier, the SLA matches real operational capability, and credits are the exclusive remedy",
        "Recommends a fallback library of pre-approved positions ahead of per-deal counsel review for the redlines",
        "Lets an analyst rather than a lawyer handle redlines that fall inside the library, with only novel terms reaching counsel",
        "Describes three-track routing, standard paper signed as-is, library redlines on a short analyst SLA, and novel or regulated terms to counsel, as a routing goal pushing volume toward the first track rather than a per-deal choice",
        "States that uncapped liability or consequential damages outside pre-approved carve-outs is prohibited-class rather than an approvable exception"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "design a deal desk approval matrix for our enterprise deals", "should_trigger": true },
    { "query": "who should be allowed to approve a 30% discount?", "should_trigger": true },
    { "query": "our AEs discount whatever it takes and everything ends up in the CFO's inbox", "should_trigger": true },
    { "query": "set up delegation of authority for non-standard deals", "should_trigger": true },
    { "query": "build a discount approval workflow with tiers and SLAs", "should_trigger": true },
    { "query": "quote approval process design", "should_trigger": true },
    { "query": "we need rules for when reps can hand out net-90 terms", "should_trigger": true },
    { "query": "reps keep promising free implementation to close deals, how do I control that", "should_trigger": true },
    { "query": "last year's one-time exceptions are all back at renewal", "should_trigger": true },
    { "query": "discounts spike every quarter end, fix it", "should_trigger": true },
    { "query": "how do I stop margin erosion from concessions", "should_trigger": true },
    { "query": "what should the auto-approve threshold be for discounts", "should_trigger": true },
    { "query": "concession governance for non-standard contract terms", "should_trigger": true },
    { "query": "our approvals take a week and deals die waiting", "should_trigger": true },
    { "query": "design an exception handling process for custom SLAs and security addenda", "should_trigger": true },
    { "query": "we want a margin floor that nobody can override", "should_trigger": true },
    { "query": "should the CRO be able to approve an MFN clause", "should_trigger": true },
    { "query": "a prospect asked for a best-price guarantee, what should our policy be", "should_trigger": true },
    { "query": "formalize who signs off on non-standard payment terms", "should_trigger": true },
    { "query": "set up a promo and coupon policy for our self-serve plan", "should_trigger": true },
    { "query": "support keeps handing out ad-hoc discounts to save churners", "should_trigger": true },
    { "query": "our coupon codes are leaking onto deal aggregator sites", "should_trigger": true },
    { "query": "design an approval chain for deals priced below our margin floor", "should_trigger": true },
    { "query": "how many tiers should a discount approval matrix have", "should_trigger": true },
    { "query": "we're formalizing a deal desk at $30K median ACV", "should_trigger": true },
    { "query": "what fields belong in our exception register", "should_trigger": true },
    { "query": "what should we put on the deal desk intake form", "should_trigger": true },
    { "query": "reps route around the desk and close verbally first", "should_trigger": true },
    { "query": "help me decide what happens to a granted discount when the contract renews", "should_trigger": true },
    { "query": "our one-time exceptions have no expiry dates on them", "should_trigger": true },
    { "query": "build a give-get policy so we stop conceding for free", "should_trigger": true },
    { "query": "which deal structures should reach finance before anyone approves them", "should_trigger": true },
    { "query": "our sales VP wants blanket authority to approve free POCs", "should_trigger": true },
    { "query": "who owns approving a custom data processing addendum inside a deal", "should_trigger": true },
    { "query": "set thresholds for when legal has to review a redline", "should_trigger": true },
    { "query": "we want a fallback library so our lawyer stops reviewing every MSA", "should_trigger": true },
    { "query": "how do we govern reseller and MSP pricing approvals", "should_trigger": true },
    { "query": "should partner deals go through the same approval lane as direct ones", "should_trigger": true },
    { "query": "what metrics tell me whether my deal desk is working", "should_trigger": true },
    { "query": "our average approval turnaround looks fine but reps still complain", "should_trigger": true },
    { "query": "our approvals come back almost instantly, is that actually good", "should_trigger": true },
    { "query": "we approve 94% of exception requests, is that a problem", "should_trigger": true },
    { "query": "cut our quote turnaround time without letting bad deals through", "should_trigger": true },
    { "query": "design quarter-end coverage for the approvals team", "should_trigger": true },
    { "query": "how do I keep people from calling every deal strategic", "should_trigger": true },
    { "query": "we need an escalation path for when the approver is on vacation", "should_trigger": true },
    { "query": "nobody here knows who can sign off on what when a price exception comes up", "should_trigger": true },
    { "query": "a customer wants a three year price hold, is that something we can sign", "should_trigger": true },
    { "query": "our reps are promising roadmap features to close deals", "should_trigger": true },
    { "query": "pick discount bands that our win rate data actually supports", "should_trigger": true },
    { "query": "we have two quarters of closed deals, where should the floor sit", "should_trigger": true },
    { "query": "stop concessions leaking out through payment terms instead of price", "should_trigger": true },
    { "query": "what has to be filled in before a non-standard deal request gets worked", "should_trigger": true },
    { "query": "build governance so the same discount doesn't get re-granted forever", "should_trigger": true },
    { "query": "put guardrails on what our sales managers are allowed to sign off", "should_trigger": true },
    { "query": "write the rules for when a deal needs CFO sign-off", "should_trigger": true },
    { "query": "create the sign-off policy for deals that carry custom terms", "should_trigger": true },
    { "query": "how should we handle a customer asking for uncapped liability", "should_trigger": true },
    { "query": "our renewals silently carry last year's discount, stop that", "should_trigger": true },
    { "query": "design the escalation timings for approval requests that stall", "should_trigger": true },
    { "query": "audit our pipeline stage exit criteria", "should_trigger": false },
    { "query": "our stage definitions are based on rep activity instead of buyer actions", "should_trigger": false },
    { "query": "flag the stale deals in this pipeline snapshot", "should_trigger": false },
    { "query": "our forecast is always wrong, diagnose why", "should_trigger": false },
    { "query": "reps sandbag their commit numbers every quarter", "should_trigger": false },
    { "query": "design our lead routing rules and round robin", "should_trigger": false },
    { "query": "build a lead scoring model with fit and engagement signals", "should_trigger": false },
    { "query": "where should we set our MQL threshold", "should_trigger": false },
    { "query": "design a composite customer health score", "should_trigger": false },
    { "query": "which product usage signals predict churn", "should_trigger": false },
    { "query": "who owns each CRM field and how often does it have to be refreshed", "should_trigger": false },
    { "query": "pick the system of record for our subscription object", "should_trigger": false },
    { "query": "design our revenue funnel stages and the unit of analysis", "should_trigger": false },
    { "query": "build a board-level revenue KPI tree that reconciles", "should_trigger": false },
    { "query": "where is revenue leaking out of our renewal process", "should_trigger": false },
    { "query": "structure our monthly board revenue report", "should_trigger": false },
    { "query": "consolidate our GTM tool stack, we have too much overlap", "should_trigger": false },
    { "query": "what should transfer from sales to CS at closed won", "should_trigger": false },
    { "query": "am I ready for a senior revops role", "should_trigger": false },
    { "query": "write the interview loop for a revops manager hire", "should_trigger": false },
    { "query": "which revops newsletters and podcasts should I follow", "should_trigger": false },
    { "query": "route my revops task to whichever skill fits it", "should_trigger": false },
    { "query": "set up an approval workflow in Lark for expense claims", "should_trigger": false },
    { "query": "design our procurement approval thresholds", "should_trigger": false },
    { "query": "who approves purchase orders above $10k", "should_trigger": false },
    { "query": "build an expense report approval chain", "should_trigger": false },
    { "query": "approval workflow for engineering change requests", "should_trigger": false },
    { "query": "design our PTO request approval process", "should_trigger": false },
    { "query": "review this contract and flag the risky clauses", "should_trigger": false },
    { "query": "summarize the indemnity terms in this MSA for me", "should_trigger": false },
    { "query": "draft an employment contract template for our first hire in Spain", "should_trigger": false },
    { "query": "audit our smart contract for vulnerabilities", "should_trigger": false },
    { "query": "what should we charge for our new product tier", "should_trigger": false },
    { "query": "design our packaging and pricing tiers from scratch", "should_trigger": false },
    { "query": "should we move from seat-based to usage-based pricing", "should_trigger": false },
    { "query": "calculate the azure pricing for this workload", "should_trigger": false },
    { "query": "find me the best hotel deal for this trip", "should_trigger": false },
    { "query": "build our ideal customer profile", "should_trigger": false },
    { "query": "write a commission plan for our AEs", "should_trigger": false },
    { "query": "design sales quota allocation across territories", "should_trigger": false },
    { "query": "write a negotiation playbook my AEs can use live on a call", "should_trigger": false },
    { "query": "coach my rep through handling a pricing objection", "should_trigger": false },
    { "query": "what discount should I push our software vendor for at renewal", "should_trigger": false },
    { "query": "help me negotiate our AWS enterprise agreement down", "should_trigger": false },
    { "query": "how do I get pull requests approved faster", "should_trigger": false },
    { "query": "set up branch protection approval rules in github", "should_trigger": false },
    { "query": "design a change advisory board for production deploys", "should_trigger": false },
    { "query": "write the returns policy for our ecommerce store", "should_trigger": false },
    { "query": "design a loyalty points program for our app", "should_trigger": false },
    { "query": "build a partner tier program with gold silver and bronze levels", "should_trigger": false },
    { "query": "draft our reseller agreement terms", "should_trigger": false },
    { "query": "recruit affiliates for our referral program", "should_trigger": false },
    { "query": "design our SDR outbound sequence", "should_trigger": false },
    { "query": "build our partner enablement curriculum", "should_trigger": false },
    { "query": "forecast next quarter's bookings by segment", "should_trigger": false },
    { "query": "clean up the duplicate accounts in our CRM", "should_trigger": false },
    { "query": "write a QBR deck for our biggest customer", "should_trigger": false },
    { "query": "set up SSO and user permissions in our CRM", "should_trigger": false },
    { "query": "draft our responses to this SOC 2 security questionnaire", "should_trigger": false },
    { "query": "measure our sales cycle length by segment", "should_trigger": false }
  ]
}

# Accounting and Legal Constraints

These are design constraints for the approval spec - reasons certain structures must route to Finance or Legal before any tier can approve. They are not legal or accounting advice; the spec's job is to route the question to the right function, never to answer it.

## Revenue recognition (ASC 606 / IFRS 15)

**Discount allocation across performance obligations**

- A discount on a bundle (subscription + implementation + services) is allocated proportionately across all performance obligations by relative standalone selling price, not to whichever line item the negotiation focused on.
- Sales' internal logic ("we discounted the services, not the license") is accounting-irrelevant unless the specific-allocation criteria are met with observable evidence: observable standalone prices, an observable bundle price, and a discount matching what the allocation would produce (ASC 606-10-32-37).
- Design consequence: any deal that steers a discount onto one line item routes to Finance. The quote's line-item story does not control the books. [Big-Four-documented standard mechanics]

**Material right**

- A customer-specific future discount promised today, e.g. a steep renewal discount not offered to others granted to win the initial deal, can be a material right: a separate performance obligation forcing part of today's revenue to be deferred until the option is exercised or expires.
- Design consequence: future-discount promises and customer-specific renewal locks route to Finance at any size. [standard mechanics, vendor-explainer sourced]

**Termination for convenience and contract term**

- If a customer can terminate at will with no substantive penalty, the enforceable contract term for revenue purposes is the notice period, not the stated multi-year term, even though the paper says "3 years". A substantive termination charge preserves the full term.
- Confirmed by the standard-setters' transition group for government contracts; the mechanic generalizes.
- Design consequence: any change to termination rights routes to Legal and Finance together. A "harmless" legal concession can silently change how much revenue exists. [practitioner-accounting sourced]

**Significant financing component**

- When payment timing diverges materially from delivery (multi-year prepay, long deferrals), a financing component may need to be recognized.
- Practical expedient: gaps under one year are exempt, which is why standard annual billing is fine and multi-year prepaid or deferred-payment structures need Finance scrutiny.
- Design consequence: payment-timing exceptions beyond one year route to Finance leadership. [practitioner-accounting sourced]

**Variable consideration boundary**

- A discount fixed at contract inception is not variable consideration; only amounts contingent on future events (rebates, refunds, performance credits, penalties) are.
- Useful for keeping ordinary negotiated discounts out of a more complex accounting path, but the classification call belongs to Finance. [practitioner-accounting sourced]

### Routing table

| Structure                                         | Routes to          | Why                                              |
| ------------------------------------------------- | ------------------ | ------------------------------------------------ |
| Discount steered to one line item of a bundle     | Finance            | Relative-SSP allocation controls, not the quote  |
| Customer-specific future/renewal discount promise | Finance            | Possible material right; revenue deferral        |
| Termination-for-convenience change                | Legal + Finance    | Contract term may shrink to notice period        |
| Multi-year prepay or extended payment tail        | Finance leadership | Significant financing component; credit risk     |
| Acceptance-based or deferred invoicing            | Finance            | Only sound with objective, time-bounded criteria |
| Rebates, credits, performance penalties           | Finance            | Variable consideration estimation                |

## Pricing-discrimination law: the load-bearing negative finding

- US - Robinson-Patman Act: on the enforcement agency's own framing, the Act applies to commodities, not services, and to purchases, not leases. SaaS is a service/intangible, so Robinson-Patman does not reach ordinary SaaS differential pricing at all. Even where it applies (tangible goods), it demands competitive injury among actual competitors and is notoriously hard to enforce. [agency guidance, corroborated by legal commentary]
- EU/UK - Article 102 TFEU and Chapter II of the UK Competition Act 1998: discriminatory-pricing prohibitions exist but are dominance-gated - they only bind firms already found dominant in a relevant market. A non-dominant vendor's differential discounting falls outside their scope by definition. [legal-commentary synthesis]
- Plain statement for the spec: for a typical, non-dominant B2B SaaS vendor, neither the US nor the EU/UK regime meaningfully constrains charging different customers different prices through a deal desk. Do not manufacture this compliance risk or build approval friction around it.
- Residual caveats, stated once:
  - General antitrust theories (e.g. US Sherman Act / FTC Act, or abuse rules if the vendor is dominant) can still reach genuinely anticompetitive pricing conduct.
  - Sector rules and public-sector procurement have their own regimes.
  - Contractual MFN clauses the vendor itself signed are a self-inflicted constraint (which is one reason they sit in the prohibited class).

  Route any actual legal question to counsel.

# Approval Matrix Design

Provenance tags used throughout this reference:

- `[practitioner]` - published practitioner/consultancy source (Umbrex deal-desk playbook, RevOps Co-op, SBI Growth - operator series, not standards bodies).
- `[illustrative]` - single vendor blog or example, not a benchmark.
- `[derive]` - must come from the user's own deal data.

Level counts and thresholds vary per company: treat every number below as a default to calibrate, never an industry constant.

## The five governed levers [practitioner]

The matrix governs five concession levers, not just price:

- Price/discount
- Payment terms and billing
- Services inclusion and delivery commitments
- Contract risk (liability, remedies)
- Security/privacy commitments

Governing only discount is a named failure mode: concessions migrate to the ungoverned levers, where they are harder to see and cost more. Translate every non-price concession into an equivalent economic value so approvers can compare it to discount (a net-90 term, a free implementation, an uncapped SLA credit all have a price).

## Dimensions beyond discount %

- Deal size (ACV or TCV band) - a 30% discount on a $5K deal and on a $500K deal are different decisions.
- Segment: industry, company size, region, channel. Build eligibility fences per segment so approvals are comparable like-for-like and cross-segment arbitrage is blocked [practitioner].
- Motion: new business vs renewal vs expansion - each gets its own corridor; renewal discounts compound forever.
- Term length and product line - fold into deal type at intake; a multi-year ask changes the economics of the same headline %.
- Margin impact - the truest dimension when per-deal margin is computable; discount % is its proxy.

## Tiers and the auto-approve floor

Modal practice is 3-4 tiers [practitioner, convergent across sources - descriptive of common practice, not a standard]:

| Tier | Meaning                       | Typical approver                            | Analyst load per deal             |
| ---- | ----------------------------- | ------------------------------------------- | --------------------------------- |
| 0    | Within policy - auto-approved | Nobody; quote tool applies rules            | none                              |
| 1    | Managed exception             | Sales manager or deal desk analyst          | minutes                           |
| 2    | Material exception            | Sales VP + Finance (or deal desk lead)      | an hour, plus two calendars       |
| 3    | Executive exception           | CRO/CFO level, jointly for the largest asks | an hour, plus executive calendars |

The auto-approve floor is list price or a low single-digit discount, applied by the quote tool [practitioner]. Every deal it absorbs into tier zero costs no analyst time at all, so where the floor sits decides the desk's entire workload. Three ways to place it.

Lead with the win-rate derivation - it is the only floor that survives being challenged by a rep.

- discount the floor actually stops: win-rate derivation > distribution percentile > illustrative placeholder
- effort: win-rate derivation > distribution percentile == illustrative placeholder
- reversibility cost: illustrative placeholder > distribution percentile == win-rate derivation

**Win-rate derivation** [derive]. Plot win rate by discount band over 2+ quarters of closed deals and set the floor where extra discount stops buying win rate. An hour of analysis once the data exists, and the number is defensible band by band when sales pushes back.

**Distribution percentile** [derive]. Set the floor at a chosen percentile of the historical discount distribution. Near-zero effort, but it encodes what reps already did as policy - it describes past behaviour, creep included, rather than what worked.

**Illustrative placeholder** [illustrative]. Ladders seen in the wild, to hold the slot for one cycle and never to ship as policy:

- <10% auto / 10-20% manager / 20%+ VP
- 10-20% manager / 20-40% VP / 40%+ desk review / multi-year to Finance+Legal

Ranking these two against each other would be false precision - neither is evidence, both are stand-ins.

- Distribution percentile == placeholder on effort: at order-of-magnitude granularity both are near-zero, one query against data the desk already pulls, versus none.
- Distribution percentile == win-rate derivation on reversibility: both leave an audit trail that can be re-derived and re-defended. The placeholder cannot be defended, so it gets renegotiated deal by deal and only ever ratchets down.

Deleted, not demoted: the circulating 15% / 25% / above-25%-to-CRO+CFO ladder. Treat it as fabricated, not as a placeholder to rank below the others.

What this order starves: the win-rate derivation, the only defensible method, loses whenever the data is not there yet - and two quarters is the stated minimum. Promote it the moment 2+ quarters of closed-won and closed-lost carry discount fields, whatever the deadline. Every quarter run on a placeholder floor sets the level reps come to expect, and raising a floor later costs political capital that setting it right never did.

Escalation overrides bypass the % ladder wherever the floor sits: deal size above a set band, any custom terms, public-reference or marquee-logo commitments [illustrative].

## Hard floors

- In most B2B software the binding hard floor is a policy margin floor, not a cost floor: marginal cost is near zero, so the cost floor sits far below any price anyone would accept, and only a declared minimum-margin policy actually binds [practitioner].
- Exception: AI/inference-heavy and other usage-scaling-COGS products have real, growing marginal cost - there the cost floor rises and binds again [single-source but economically sound; verify against the user's own unit costs].
- The floor is approver-independent: no tier waives it. Set it per product family when COGS differs by line; a company-wide number is [derive], never the circulating "75% gross-margin floor" (a repeated number, not a benchmark).

## Prohibited regardless of approver

No tier may approve these; they can only be considered at all with an explicit give-get trade, and then only by Legal plus the commercial lead jointly [practitioner]:

- MFN / best-price guarantees, retroactive rebates, broad benchmarking-publication rights.
- Open-ended price holds without defined scope, term, and expiration.
- Uncapped liability or consequential damages outside a pre-approved carve-out list.
- Commitments to build: net-new functionality, integrations, or timelines not pre-approved by Product and Delivery.

The give-get discipline generalizes: never concede anything without getting something priced in return (longer term, larger volume, upfront payment, a reference).

## Strategic vs tactical

Classify discounts:

- Tactical: routine competitive pressure, stays inside standard bands.
- Strategic: market entry, marquee logo, named-competitor displacement, executive-approved and logged with its rationale.

Caution from practitioner discussion: if 40% of deals claim to be strategic, nothing is [illustrative phrasing; the mechanism is sound].

## Threshold calibration and recalibration

- Initial anchors must be observable at quoting time and reflect true economics: deviation from the price corridor, pocket-margin floor, total concession value across all levers [practitioner].
- Derive, don't import [derive]:
  - Pull 2+ quarters of closed deals.
  - Plot discount distribution by segment and win rate by discount band.
  - Set the auto-approve floor where extra discount stops buying win rate.
  - Set tier boundaries at natural breakpoints in the distribution.
  - Sanity-check that the top tier catches the deals leadership actually wants to see.
- Recalibration inputs [practitioner]:
  - Exception analytics: which types drive cycle time and rework, and what should become standard.
  - Leakage events: policy vs executed-outcome deviations, tagged by cause.
  - Late-discovery rate: non-standard terms surfacing after proposal, an intake gap.
- Cadence [practitioner]:
  - Daily: queue management.
  - Weekly: cycle-time percentiles and exception volume.
  - Monthly: exceptions forum producing a change backlog with owners and dates.
- Two quarters of data minimum before judging approval-pattern changes [practitioner].

## Circulating numbers to refuse

Never present as fact; each circulates unattributed:

- 75% gross-margin floor
- 1 deal-desk FTE per $40M ARR
- 35% mid-market / 70% enterprise deal-desk hit rates
- Stripe-attributed "customers at 30%+ discount churn at 4.2x"
- Gartner-attributed "90% of B2B purchases AI-intermediated by 2028"

A related but distinct claim, discount-negotiating customers churning at roughly 2x, is a practitioner claim (ProfitWell lineage), usable only when labeled as such.

# Exception Taxonomy

Group exceptions by what triggers them [practitioner - Umbrex playbook synthesis]. Route each type to the function that owns its risk: the matrix decides how high, the taxonomy decides who.

1. Economic thresholds: discount beyond band, non-standard payment terms, free services above a cap, deal value above a band. Easiest to automate.
2. Structural complexity: multi-year ramps, usage commitments and true-ups, cross-product bundles, price holds, unusual termination rights.
3. Risk and precedent: contract-standard deviations, security/privacy changes, roadmap commitments.

## Type-by-type: owner and escalation trigger

**Non-standard payment terms** (net-60/90, monthly billing on annual contract, deferred start)

- Treat it as a concession even when presented as an administrative request; translate it into an equivalent price concession so approvers can compare.
- Required trade: smaller discount, longer term, partial upfront, or a security mechanism.
- Owner: Finance.
- Non-delegable escalation to Finance leadership for extremely long terms, multi-year deferrals, and "pay when paid" clauses in channel deals - these shift the vendor toward being a lender [practitioner].

**Multi-year ramps**

- Ranking: entitlement ramp > discount ramp on value and effort together, so no split axis is needed - more units over time is easier to invoice and enforce, while a price that steps up later carries the risk of the step never landing.
- Control: anchor renewal pricing to the last contract period's price so early ramp concessions cannot reset the future.
- Owner: Finance/Pricing.
- Escalate when renewal uplift falls below the corridor [practitioner].

**Custom SLAs and service credits**

- Changes both operating cost and downside exposure.
- Stays non-escalated only if credits are capped at the standard tier, the SLA matches real operational capability, and credits are the exclusive remedy.
- Owner: Security/Ops validates feasibility.
- Escalate to leadership on uncapped credits, penalties beyond credits, or an SLA beyond capability [practitioner].

**MSA/legal redlines** (liability cap, indemnity, IP, data residency, auto-renewal removal)

- Ranking: fallback library > per-deal counsel review. A one-off week of Legal's time on 15-25 pre-approved positions [illustrative] moves most redlines off counsel's desk permanently, and it is the only one of the two that gets cheaper every quarter.
- Maintain the library so an analyst, not a lawyer, handles redlines within it; only novel terms reach counsel.
- Three-track pattern [illustrative single-source; the concept is corroborated, the exact SLA hours are not]. The tracks rank A > B > C on redlines cleared per hour of legal time, a routing goal (push volume toward A) rather than a per-deal choice:
  - Track A: standard paper signed as-is, zero review.
  - Track B: redlines against the fallback library, analyst-handled on a short SLA.
  - Track C: novel/regulated terms to counsel on a longer SLA.
- Liability-cap removal or uncapped consequential damages outside pre-approved carve-outs is prohibited-class, not an exception.
- Owner: Legal for any deviation from the library.

**Security and privacy commitments** (audit rights, custom data-processing terms, residency, incident timelines, compliance attestations)

- Triage: Standard (library answer exists) / Clarify (needs input) / Exception (genuinely new commitment).
- Escalation triggers: customer-defined incident timelines, dedicated environments, unique audit support, custom logging.
- Owner: Security for feasibility.
- Owner: Privacy for residency/sub-processor/transfer asks.
- Owner: Legal only when new operational obligations are created [practitioner].

**MFN, best-price guarantees, open-ended price holds**

- Prohibited-class (see the matrix reference); listed here because reps will submit them as ordinary exceptions.
- Owner: Legal + commercial lead jointly, give-get mandatory even to discuss [practitioner].

**Roadmap/product commitments**

- Prohibited by default.
- An exception path opens only after Product and Delivery pre-approve feasibility.
- Legal caps any attached penalty structure [practitioner].

**Termination for convenience**

- Owner: Legal, with mandatory Finance input; the accounting consequence (contract term shrinking to the notice period absent a substantive penalty) is usually bigger than the legal one. See the accounting reference.
- Common negotiated fallback: allow it only with full upfront payment and no clawback right [practitioner].

**Free periods, pilots, POCs**

- Time-box; beyond roughly 90 days prefer a paid pilot [illustrative].
- Controls:
  - State "at no charge" explicitly (prevents an implied-payment claim).
  - Settle foreground-IP ownership up front.
  - Finance signs off the ARR/revenue treatment of the eventual conversion.
- Owner: Legal (terms/IP) + Finance (fee/ARR) + Product (scope), a default split to confirm with the user, not a standard RACI.

**Reseller/channel/MSP pricing**

- No published framework governs channel deal-desk approval the way discount-threshold matrices are documented for direct deals; decide the actual thresholds as house policy with the user, not adapted best practice.
- Vendor partner-program policies (AWS Partner Network, Microsoft Partner Center/CSP, Google Cloud Marketplace, Salesforce AppExchange) solve a different problem: they govern the wholesale discount or margin the vendor extends to the partner, not case-by-case approval of what the partner charges the end customer. Do not import their tier structures as a deal-desk approval matrix [practitioner].
- GitLab's public Deal Desk Handbook documents the one concretely differentiated practice available: separate quote templates per channel type (Authorized Reseller, MSP, and Distributor Order Forms versus the Standard Order Form), and an intake routing decision - "route to market: direct, channel, marketplace" - that sends channel and marketplace deals to Partner Territory Managers or Partner Account Managers instead of the standard deal-desk analyst lane [practitioner].
- Deal registration - a partner submitting a lead or opportunity for protected pricing and margin before working it - is the channel-specific intake gate with no analog in the direct motion. CompTIA's recurring State of the Channel research documents deal registration and its rules of engagement as a recurring source of partner friction [practitioner].
- The one documented escalation datum is that "pay when paid" channel clauses escalate non-delegably to Finance leadership.
- If the user has a channel motion, design the actual thresholds explicitly with them and label the result as house policy.

## Routing summary

| Exception type               | Owner                                   | Non-delegable escalation                                          |
| ---------------------------- | --------------------------------------- | ----------------------------------------------------------------- |
| Payment terms / billing      | Finance                                 | Multi-year deferrals, pay-when-paid                               |
| Ramps / renewal constructs   | Finance/Pricing                         | Renewal uplift below corridor                                     |
| Custom SLA / credits         | Security/Ops                            | Uncapped credits, penalties beyond credits                        |
| Legal redlines               | Legal (analyst inside fallback library) | Novel terms, regulated asks                                       |
| Security/privacy             | Security, Privacy                       | New operational obligations -> Legal                              |
| MFN / price holds            | Legal + commercial lead                 | Always (prohibited-class)                                         |
| Roadmap commitments          | Product + Delivery                      | Always (prohibited by default)                                    |
| Termination for convenience  | Legal + Finance                         | Penalty-free walk-away rights                                     |
| Free periods / POCs          | Legal + Finance + Product               | Unbounded duration, unowned IP                                    |
| Reseller/channel/MSP pricing | Partner management (routing) + Finance  | Pay-when-paid clauses; always routes off the standard three lanes |

# Intake, Routing, SLAs, and Precedent Control

Sourced primarily from the Umbrex deal-desk operator series [practitioner] unless tagged otherwise.

## Intake fields

Require these field groups on every request:

- Identity and routing: account (and parent account), opportunity ID, seller, seller's manager, segment, region, channel.
- Commercial basics: list price, proposed price, requested discount or target price, currency, expected close date.
- Offer essentials: products/SKUs, quantities, term length, start-date assumption, deal type (new/renewal/expansion).
- Context: use case in one or two sentences, customer decision date, primary competitor or alternative.
- Non-standard flags: structured tags per lever - pricing, payment terms, services scope, contract terms, security/privacy, delivery commitments.
- Justification, split into separate fields:
  - Economic upside: revenue, term, margin, cash.
  - Strategic upside: reference value, target-vertical entry, named-competitor displacement, credible expansion path.

  Each field ties to the specific exception requested - a strategic logo does not justify every concession. State what the company gets in exchange for this ask.

- Impact of denial - the highest-weight field: what changes if the exception is refused. "The customer asked for it" is not sufficient justification.
- Prior exceptions granted to the same account.

## Completeness gate and bounce protocol

Work starts only when required fields are present; incomplete submissions bounce, they never queue.

The bounce is structured:

- List the missing items.
- Explain the business impact.
- Name the responsible party.
- Give resubmit instructions.

Quality dimensions to enforce:

- Completeness
- Validity (numeric/logical checks)
- Consistency (deal record, quote, and contract systems must agree)
- Timeliness
- Auditability (rationale recorded against each decision)

## Routing lanes

Structural risk, not deal size, forces the lane: a large deal at list price with standard terms needs no review, while a small deal with a custom indemnity clause does [illustrative example].

The design goal is to move volume down this list, not to staff it evenly - the fast lane clears deals per analyst hour by an order of magnitude over the other two.

- deals cleared per analyst hour: fast > complex > exception
- concession value and risk governed per case: exception > complex > fast
- analyst load per case: exception > complex > fast
- compliance cost: exception > complex == fast

**Fast lane** - one lever changed, within guardrails, standard terms, no novel risk. Near-zero analyst load (a completeness check and a rule match), same-business-day decision, and it should carry the bulk of volume.

**Complex lane** - two or three lever changes, or delivery dependencies needing confirmation, within risk appetite. About an hour of analyst work plus one cross-function confirmation; one to two business days.

**Exception lane** - below-floor economics, prohibited terms, novel security obligations, or high-precedent structures. Several hours of package assembly against several approvers' calendars, and a week of elapsed time.

Complex == fast on compliance cost by construction, not coincidence: anything on the accounting/legal routing table, in the prohibited class, or setting precedent is exception-lane by definition, so neither of the other lanes may ever carry that exposure.

What this order starves: the exception lane. It is high value and high effort, so a desk measured on cycle time quietly widens the fast lane's guardrails until below-floor and precedent-setting structures slip through - the failure the lanes exist to prevent. Promote a request to the exception lane on structure alone, however simple it looks and however close the quarter-end is.

## Two SLA clocks

- Response SLA: within a few business hours for every lane.
  - Acknowledge.
  - Validate completeness.
  - Assign the lane.
  - Communicate next steps.
- Decision SLA, per lane:
  - Fast lane: same business day.
  - Complex lane: one to two business days.
  - Exception lane: several business days, with an interim milestone of a complete decision package within one day.
- Both clocks run in business hours. The clock starts when required fields are complete in the system of record and stops when the decision is recorded and communicated - not when a reviewer replies with a clarifying question.
- A circulating claim that win rate degrades materially past a 48-business-hour ceiling (sometimes attributed to revenue-intelligence data) is [unverified] - the named revenue-intelligence vendors' own published research contains no such finding, and no named study backs the number anywhere it circulates. Use the mechanism (slow approvals lose deals and breed bypass), not the number.

## Elapsed-SLA auto-escalation: 50 / 80 / 100

- 50% of SLA elapsed: case owner confirms next steps and checks blockers.
- 80% elapsed: escalate to the approver's delegate or manager with a decision window; at quarter-end peaks, apply this trigger to top-tier approvals with a complete decision memo attached.
- 100% elapsed: formal escalation path, decision package attached.

## Approver absence and delegation

- Every approver names a delegate with an explicit delegation window (start and end dates).
- An expiring delegation with a pending item escalates rather than deadlocks.
- Define a break-glass role for the case where the delegate is also absent.
- Design the absence protocol explicitly with the user and record it as house policy.

## Quarter-end peak mode

Peak mode adds capacity and clarity, never relaxed rules; the completeness gate and the approval matrix stay intact:

- Extended coverage where available
- Published completeness cutoffs for same-day handling
- Dedicated executive escalation windows

Period-end discount spikes are the signature of undisciplined (not strategic) discounting. The durable fix is earlier deal shaping upstream, not crunch-time exceptions.

## Precedent control

- "This is a one-time exception" is not self-enforcing - customers cite it as precedent the following year. Precedent is a first-class risk dimension alongside margin, revenue-recognition, legal, and deliverability; the register is the desk's institutional memory.
- Time-box every granted exception (30-60 days is the typical published window [practitioner]); a quote without an expiration date is itself a precedent risk.
- Exception register - treat this field list as a suggestion to adapt to the user's systems: request ID and deal ID, requestor, exception type (by lever), justification and impact-of-denial as submitted, approver and tier, decision and reason string, expiry/sunset date, renewal-exposure flag, later-cited-as-precedent tracking.
  - Umbrex's own toolkit publishes a second, per-lever variant instead of one universal register - separate field sets per exception type:
    - Discount: ask, baseline, category, evidence, give-get, economics delta, precedent control, fallback.
    - Payment terms: ask, invoice trigger, cash impact, give-get, credit trigger, expiration.
    - Free/discounted services: ask, assumptions, timeline, feasibility, give-get, change control.
    - Competitive match: competitor and evidence, comparability, requested response, trade required, validity, escalation.
    - Approval record (standalone, closes every type): decision, approved package, conditions, expiration and triggers, links - makes conditions enforceable in CPQ/CLM.
  - Either shape works: a per-lever register fits a desk where each lever routes to a different owner; one universal register fits a single desk owning all five.
- Pattern-to-policy loop: a monthly exceptions forum reviews recurring exceptions and produces a change backlog with owners and dates. Trigger question: "we approve this same exception routinely - should it become standard for this segment?" Promote or explicitly reject; never let a de facto precedent persist undocumented.

## Renewal treatment of a granted exception

Decide this at grant time, per exception class, never at the renewal itself. The treatment chosen becomes the template every future renewal argues from, which makes it the least reversible decision on this page.

The ordering below reasons from margin, renewal risk, and standing effort rather than from renewal data; the treatment is house policy either way. One adjacent published datum: ramp-deal renewals anchor to the last period's price.

Lead with sunset - it recovers the most margin for the least standing effort.

- margin recovered at renewal: sunset > step-up > grandfather-on-re-approval
- renewal risk carried (churn or escalation at the snap-back): sunset > step-up > grandfather-on-re-approval
- analyst effort: step-up > sunset == grandfather-on-re-approval
- compliance cost: grandfather-on-re-approval > sunset == step-up

**Sunset** - the exception expires at term end and price returns to standard. One dated clause written into the original approval, near-zero standing effort, recovers the whole concession, and stays reversible: nothing was promised, so grandfathering stays available later. Default treatment.

**Step-up** - staged return to standard over one or two renewals. Recovers the concession a year or two late and costs per-account tracking across two renewal cycles - a standing job for whoever owns the register - in exchange for removing the snap-back cliff.

**Grandfather on re-approval** - the concession carries into renewal, but only after a fresh approval at the tier that granted it. Near-zero effort at renewal and it buys the least: the account keeps the discount and cites it again the following year.

- Sunset == grandfather on effort: both are minutes of register work at renewal, what separates them is the price on the quote, not the hours.
- Sunset == step-up on compliance cost: both write a dated end state into the original approval, so neither creates an open-ended commitment, only the schedule differs.
- Grandfather ranks worst there because a renewal that re-grants the same term is exactly the evidence a customer cites at the next one.

Deleted, not demoted: **silent grandfather** - carry-over with no re-approval. An exception with no expiry is the defect the register exists to prevent, so it is not a treatment to weigh against the others; parked at the bottom of a menu it returns as the path of least resistance.

What this order starves: step-up. It is the only treatment that recovers margin without a cliff, and it loses every round because its tracking never ends. Promote it above sunset when a full snap-back has already driven churn or an escalation in that segment, or when the account is the reference or expansion base later deals depend on.

# Worked Examples

All numbers below are illustrative constructions for a fictional company, tagged the way the real spec must tag them:

- `[derived]` - computed from that company's own deal data.
- `[illustrative]` - a stand-in to replace with a derived value.
- `[policy]` - a deliberate house decision, not a benchmark.

## Example 1 - B2B mid-market SaaS (sales-led, $30K median ACV, near-zero COGS)

```
DEAL DESK APPROVAL SPEC - Northbeam CRM (fictional), 2026-08-25
Scope        : new, renewal, and expansion deals with any non-standard element across the
               five levers. Out of scope: list pricing/packaging, expense/procurement approvals.
Levers       : all five governed; every non-price concession converted to discount-equivalent
               value at intake (net-90 on a $60K annual deal booked as ~1.5% [derived from
               internal cost of capital]; free implementation booked at its list price).
Matrix       : dimensions = discount % x ACV band x motion, fenced per segment.
               Tier 0 auto-approve: <8% new business [derived - win rate flat beyond 8% in
               6 quarters of win-rate-by-discount-band data]; <3% renewals [derived].
               Tier 1 (manager + desk analyst): 8-18% [derived, p75 of discount distribution].
               Tier 2 (VP Sales + Finance): 18-30%, or any 2+ lever change, or ACV > $150K
               [policy - leadership visibility band].
               Tier 3 (CRO + CFO jointly): >30%, below-floor economics, marquee-logo terms.
               Floor: 78% gross margin per deal [policy - set from this company's own COGS
               and target model; NOT the circulating "75%" number]. No tier waives it.
Prohibited   : MFN/best-price, price holds without scope+term+expiry, uncapped liability
               outside the carve-out list, roadmap commitments without Product+Delivery
               pre-approval. Give-get mandatory even to table one.
Intake       : full field set; impact-of-denial mandatory and weighted highest; requests
               missing fields bounce with a structured return; clock starts at completeness.
Routing      : fast lane (1 lever, in guardrails) / complex lane (2-3 levers) / exception
               lane (below floor, prohibited terms, novel security, high precedent).
SLAs         : response 4 business hours all lanes [policy]; decision same day / 2 days /
               5 days by lane [policy]; 50/80/100 elapsed escalation; every approver has a
               named delegate with dated windows; peak mode: quarter-end completeness
               cutoff at T-5 business days, exec escalation window daily 4-5pm [policy].
Precedent    : register in the system of record with expiry on every exception (default
               60 days [policy]); monthly exceptions forum with change backlog.
               Renewal treatment [policy, decided in interview]: discounts sunset at term
               end; step-up over one renewal for exceptions >20%; nothing grandfathers
               silently - carry-over requires a fresh Tier 2 approval.
Constraints  : line-item-steered discounts, future-discount promises, termination-right
               changes, >1-year payment tails -> Finance/Legal per the routing table.
Calibration  : thresholds re-derived quarterly from discount distribution + win rate by
               band; exception analytics monthly; late-discovery rate tracked per rep.
KPIs         : cycle time (median + p90, complete-submission to communicated decision),
               win rate, discount rate, per-deal margin, leakage - reported together.
```

## Example 2 - PLG / self-serve and B2C: the rules-driven equivalent

No human chain exists below the sales-assist line; the "desk" is a published rule set.

```
DISCOUNT POLICY SPEC - Flowkit (fictional PLG, $29-99/mo self-serve; sales assist > $10K/yr)
Published bands : annual prepay -17% [policy, published]; education/nonprofit -30% with
                  eligibility verification [policy, published]; no other self-serve discounts.
Promo governance: promo codes single-use, expiring, capped per campaign budget [policy];
                  stacking prohibited by the promo engine, not by support judgment;
                  win-back and save offers fixed-menu (2 months -20% max), logged per
                  account, once per 12 months [policy].
Exception rules : support may not invent discounts; every published rule states its own
                  exception path ("if X, then Y"), so the answer to an unlisted ask is no.
Human line      : > $10K/yr or 25+ seats -> sales-assist, where the B2B matrix (Example 1
                  shape) takes over [policy].
Creep monitoring: monthly - % of revenue on any discount, average realized discount,
                  save-offer redemption vs churn saved, coupon-leakage check (codes on
                  coupon aggregators), refund-policy abuse rate.
```

The transferable core is identical to B2B: bands are defined in advance, every exception is logged, and creep is monitored - only the enforcement mechanism changes (promo engine and published terms instead of a human chain). Present the equivalence as reasoning about the two motions, not as a documented finding.

## Example 3 - Negative example: the matrix that erodes itself

A spec like this fails even though it looks like governance:

- Governs discount % only. Reps stop asking for 25% off and start asking for net-120, free onboarding, an uncapped SLA credit, and a price hold "for the co-sell" - none of which route anywhere. Concession value leaves through the four ungoverned levers.
- Single top approver (the CFO) with no delegate and no elapsed-SLA escalation.
  - Requests sit for a week in a mailbox checked daily.
  - The buyer's procurement window closes.
  - Reps learn to close "verbally" first and seek approval after; the desk is now decorative.
- Approvals happen in chat threads. A year later nobody can distinguish an approved exception from an informal precedent, so every rep cites "the deal we did for Acme" and every customer cites last year's "one-time" discount - which had no expiry date and no register entry.
- The one hard rule is a "75% margin floor" imported from a blog post, unrelated to the company's actual COGS or target model - so it binds nothing real, while actual leakage happens above it.
- Cycle time is reported as a mean, which looks fine at 6 business hours while the p90 sits at 4 days - exactly the tail that drives the bypass behavior nobody can see.

Fix path:

- Govern all five levers.
- Delegate + 50/80/100 escalation.
- Move approvals into the system of record with a register and expiry dates.
- Derive the floor and tiers from own data.
- Report median + p90.

---
name: deal-desk-approval
description: Design the deal desk approval chain and exception-handling process for non-standard B2B SaaS deals - a tiered discount approval matrix and delegation of authority across five concession levers (price, payment terms, services, contract risk, security), margin floor policy, exception intake, two SLA clocks with a sales escalation path, and precedent control. Includes the rules-driven promo/discount-policy equivalent for PLG, self-serve, and B2C. Use whenever the user mentions deal desk, discount approval, quote approval, approval matrix, delegation of authority, non-standard deals, concessions, margin floors, or discount creep - even if they never say "deal desk". Covers deal-level commercial approvals only, not general business-process approval workflows.
license: MIT
metadata:
  author: Maya-Beth Finotti
  version: "1.3.8"
---

# Deal Desk Approval

Design who may approve what on non-standard deals - discounts, custom terms, risky structures - and deliver it as a spec: an approval matrix across five concession levers, a prohibited-terms class, exception intake with SLA clocks and escalation, and precedent control. This skill covers deal-desk approvals only: general business-process approvals (expense, procurement, HR, engineering change) are out of scope - say so and stop when asked for them.

Deal-desk thresholds are not standardized: every number in circulation comes from practitioner blogs and consultancies, several from content farms. The skill's core discipline is therefore provenance: label where each threshold comes from, and derive the real ones from the user's own deal data, not from an imported "industry" number.

## Ground Rules

- Tag every numeric threshold with its provenance. Never present a vendor heuristic as an industry constant.
  - Published practitioner source
  - Single vendor blog (illustrative only)
  - Derived from the user's own deal data
- Never state these circulating numbers as fact. Each is repeated across content without attribution. Omit them, or name them as circulating and unverified:
  - "75% gross-margin floor"
  - "1 deal-desk FTE per $40M ARR"
  - "35% mid-market / 70% enterprise deal-desk hit rates"
  - Stripe-attributed "4.2x churn at 30%+ discount"
  - Gartner-attributed "90% of B2B purchases AI-intermediated by 2028"
- "The customer asked for it" is not a justification. The highest-weight intake field is impact of denial - what changes if the exception is refused.
- Treat accounting and legal constraints as design constraints routed to Finance, Legal, Security, or Product. Never give legal or accounting advice.
- State the negative finding plainly where relevant: pricing-discrimination law barely constrains a non-dominant SaaS vendor's differential discounting (see [references/accounting-legal-constraints.md](references/accounting-legal-constraints.md)). Do not manufacture that compliance risk.
- Be honest where public practitioner guidance is thin. Design these explicitly with the user instead of presenting invented practice as standard:
  - Renewal treatment of granted exceptions
  - Reseller/MSP pricing governance
  - Approver-absence protocol
- Treat every option ordering in this skill and its references as a default, not a law. It shifts with context and with who executes it, so re-rank it against what you already know about the user before recommending anything.
- Concretely:
  - A deal desk of one analyst cannot fund a step-up register or a quarterly re-derivation.
  - A sales leader with veto over policy raises the political cost of tightening any floor, which promotes floors derived from data they cannot argue with.
  - A renewal book already full of grandfathered terms makes sunset a re-negotiation rather than an expiry, and step-up the realistic first move.
- Express effort as analyst review hours, approval-chain latency, the political capital of tightening a policy sales relies on, and reversibility - never as a currency amount. Discount percentages, margin floors, and win-rate arithmetic are the subject matter and stay as they are.

## Interview

Ask before designing anything. One question per message; multiple-choice where possible; skip anything already answered.

- GTM motion: sales-led, PLG with sales assist, hybrid, or pure self-serve/B2C?
- Segment mix and ACV bands - what does a small, typical, and large deal look like?
- Who approves discounts today, and through what channel: nobody, manager ping, email chain, quote tool, formal desk?
- What deal data can be queried: discount distribution by segment, win rate by discount band, per-deal margin, approval cycle time?
- Margin structure: near-zero marginal cost (classic software), or usage-scaling COGS (AI/inference, data, infra-heavy)?
- Which non-price concessions show up today: payment terms, free services, legal redlines, custom SLAs, security/privacy addenda, roadmap asks?
- Deal volume per quarter, and roughly what share needs any exception today?
- Where does the pain sit: speed (deals stuck in approval) or leakage (margin erosion, unlogged concessions) - or both?
- Which functions exist to route to: Finance, Legal, Security, Product/Delivery?
- Renewals: who owns them, and do prior discounts silently carry over today?
- Does discounting spike in the final weeks of the quarter?
- Deadline: what date must this spec be live by - before this quarter closes, next quarter, or no fixed date?
- One-off win or compounding asset: fix this quarter's discounting, or set the policy every future renewal and every new rep argues from? Compounding is literal here - a concession granted once is argued from forever.
- Effort ceiling: how many analyst hours per week can the desk fund, who holds veto over tightening policy, and how much political capital can you spend with sales?

Re-rank the reference menus against those last three answers, and say out loud which answer moved which option:

- A hard deadline promotes the fast-acting options - a placeholder auto-approve floor and sunset renewal treatment both land in a day - and demotes anything needing a data pull.
- A compounding mandate promotes the win-rate-derived floor over any placeholder even at the cost of a quarter's delay, because the placeholder becomes the discount level reps expect.
- A low effort ceiling deletes step-up renewal treatment, whose per-account tracking is a standing job, and pushes the exception lane's package assembly onto fewer, larger batches.

## Workflow

1. Run the Interview; collect every answer the spec depends on.
2. Confirm the scope boundary: this desk governs non-standard deals. If the request is really pricing strategy (list price, packaging, tiers) or a non-deal approval process, say so and route out.
3. Establish the five governed levers from [references/approval-matrix-design.md](references/approval-matrix-design.md):
   - Price/discount
   - Payment terms and billing
   - Services and delivery commitments
   - Contract risk
   - Security/privacy commitments

   A matrix that governs only price pushes concessions into the other four levers.

4. Design the matrix from the same reference:
   - Dimensions beyond discount %: deal size, segment, motion, term, product line, margin impact.
   - 3-4 tiers with an auto-approve floor at the bottom.
   - A policy margin floor underneath every tier.
   - The prohibited-regardless-of-approver class: MFN/best-price, open-ended price holds, uncapped liability outside carve-outs, unapproved roadmap commitments.
5. Map each exception type to its owning function and escalation trigger using [references/exception-taxonomy.md](references/exception-taxonomy.md).
6. Design intake, routing lanes, the two SLA clocks, elapsed-SLA escalation, approver-absence delegation, and quarter-end peak mode from [references/intake-routing-and-precedent.md](references/intake-routing-and-precedent.md). The completeness standard gates the SLA clock: incomplete requests bounce with a structured return, they never queue.
7. Design precedent control from the same reference:
   - Exception register, expiry on every granted exception, the pattern-to-policy review, and a renewal treatment per exception class.
   - Default to sunset: it recovers the whole concession for near-zero standing effort and stays reversible. Promote step-up only where a price snap-back has already driven churn in that segment.
   - Silent grandfathering is not one of the options.
   - Public guidance is genuinely thin here: decide it with the user and record it as house policy.
8. Encode accounting and legal constraints as routing rules from [references/accounting-legal-constraints.md](references/accounting-legal-constraints.md): which deal structures must reach Finance or Legal before any tier can approve, and why.
9. Handle B2B and B2C explicitly per the section below - asymmetrically, not with fake symmetry.
10. Calibrate thresholds in that reference's priority order:
    - Derive the auto-approve floor from win rate by discount band where the data exists.
    - Fall back to a percentile of the user's own discount distribution where win-rate data is thin.
    - Use an illustrative ladder only as a one-cycle placeholder that never ships as policy.

    Expect to need roughly two quarters of data before patterns are judgeable (RevOps Co-op); if it does not exist yet, say so in the deliverable.

11. Emit the spec (Output Shape below) one section at a time for user validation; ground it in a matching worked example from [references/worked-examples.md](references/worked-examples.md).
12. Attach the KPIs and Pass Threshold below and iterate until the pass conditions hold.
13. If your harness has persistent memory, memorize the decided tiers, floors, prohibited list, and renewal treatment so a later recalibration starts from them instead of re-interviewing.

## B2B and B2C

A human deal desk is a B2B/enterprise construct: B2B prices per customer - quoted and negotiated - while B2C prices per product - published and taken. No B2C deal desk exists; do not invent one.

- PLG, self-serve, and high-volume transactional SMB: the equivalent is a rules-driven discount policy - an automated promo engine, published discount bands, coupon governance, and exception rules published in the terms, with no human chain. A human enters only above the deal size where sales assist begins.
- B2C commerce: promo/markdown calendar governance, coupon issuance and stacking rules, and a published price-adjustment policy play the deal desk's role.
- What transfers identically to all of it: the erosion-by-exception dynamic, undocumented precedent as its root cause, and the discipline of defining bands, logging every exception, and monitoring creep.

State this contrast as reasoning about how the mechanics carry across the two motions, not as a documented industry finding.

## Output Shape

Deliver every engagement as this artifact. Every threshold line carries a provenance tag; every approver has a named delegate.

```
DEAL DESK APPROVAL SPEC - <company>, <date>
Scope        : what counts as non-standard; what this desk explicitly does not govern
Levers       : how each of the five levers is governed (price, payment, services, risk, security)
Matrix       : dimensions x tiers, approver + delegate per tier, auto-approve floor,
               policy margin floor (or cost floor for usage-scaling COGS), fences per segment
Prohibited   : terms no tier approves without an explicit give-get trade
Intake       : required fields (impact-of-denial weighted highest), completeness standard,
               bounce protocol for incomplete requests
Routing      : fast / complex / exception lanes, with lane criteria and the target volume
               share per lane - bulk in fast; exception lane forced by structure, not size
SLAs         : response clock + decision clock per lane (business hours, complete-submission
               to recorded-and-communicated decision), 50/80/100 elapsed-SLA escalation,
               delegation and quarter-end peak mode
Precedent    : register fields, expiry on every exception, pattern-to-policy cadence,
               renewal treatment per exception class (sunset by default; step-up only
               where snap-back churn is evidenced; no silent grandfathering)
Constraints  : accounting/legal routing table - which structures reach Finance/Legal and why
Calibration  : data source per threshold, provenance tags, recalibration cadence
KPIs         : five-KPI scoreboard + measurement definitions
```

## KPIs

- Track the five-KPI scoreboard together, never one alone (Umbrex):
  - Cycle time
  - Win rate
  - Discount rate
  - Margin
  - Leakage

  Speed-only approves bad deals fast; margin-only produces gridlock, and reps route around the desk.

- Measure cycle time from complete submission to recorded-and-communicated decision, in business hours; report median AND 90th percentile, never the mean - the p90 tail is what fuels bypass behavior.
- Also watch:
  - Exception rate by type: the pattern-to-policy trigger.
  - Late-discovery rate: non-standard terms surfacing after proposal, an intake gap.
  - Price realization: pocket price / list price (SBI Growth).
  - End-of-period discount spikes.

## Pass Threshold

The spec passes only when all completeness conditions hold, then iterates on the calibration loop.

Completeness - iterate the spec until every item holds:

- All five levers governed; a prohibited class exists; the margin (or cost) floor is stated and approver-independent.
- Every tier names an approver and a delegate; both SLA clocks and the 50/80/100 escalation are defined per lane.
- Every numeric threshold carries a provenance tag, and none of the warned-off numbers appears as fact.
- The register has expiry dates, and a renewal treatment is decided and recorded.

Calibration - iterate the matrix on the exceptions-review cadence until both hold (RevOps Co-op heuristic):

- Approvals near-instant: too many things require approval, raise the auto-approve floor.
- Decision time slow (p90 beyond the exception-lane SLA): the tiers are wrong, re-cut them.
- No recurring exception older than two review cycles remains: promote it to standard policy or reject it explicitly, while discount rate and margin hold on the scoreboard.

## Common Failure Modes

| Defect                                                 | Consequence                                                          | Fix                                                                        |
| ------------------------------------------------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| Matrix governs only discount %                         | Concessions migrate to payment terms, services, legal, security      | Govern all five levers in one matrix                                       |
| One executive as the top approval point                | Deals sit for days while buyer procurement moves on                  | Named delegate per approver + 50/80/100 escalation                         |
| Approval logic living in chat threads and spreadsheets | Context does not travel; breaks at quarter end; no audit trail       | Route and record in the system of record, log every decision               |
| No completeness gate on intake                         | Clock burns on incomplete requests; rework loops                     | Gate the SLA clock on required fields; structured bounce                   |
| "One-time exception" with no expiry                    | Customer cites it as precedent the following year                    | Time-box every exception; register it; decide renewal treatment            |
| Relaxing rules under quarter-end pressure              | Period-end discount spikes; precedent set at the worst moment        | Peak mode adds capacity and cutoffs, never relaxed rules                   |
| Reporting mean cycle time                              | Tail pain hidden; reps bypass the desk                               | Median + p90, from complete submission to communicated decision            |
| Cost floor treated as the binding floor                | Near-zero software COGS makes it meaningless; margin erodes above it | Policy margin floor - except usage-scaling COGS products, where cost binds |
| Every deal labeled "strategic" to justify concessions  | If 40% of deals are strategic, nothing is                            | Separate strategic (executive-approved, logged) from tactical bands        |

## Invocation Examples

- "Our AEs discount whatever it takes and everything routes to the CFO by email - design a real discount approval chain with tiers and SLAs."
- "We're formalizing a deal desk at $30K median ACV. Build the approval matrix and the exception process for non-standard terms: net-90, custom SLAs, security addenda."
- "Discounts spike every quarter-end and last year's 'one-time' exceptions are all back at renewal. Fix our exception handling and precedent control."

## Reference

- [references/approval-matrix-design.md](references/approval-matrix-design.md) - Matrix dimensions, tiers, floors, prohibited class, and threshold calibration
- [references/exception-taxonomy.md](references/exception-taxonomy.md) - Exception types and routing to owning functions
- [references/intake-routing-and-precedent.md](references/intake-routing-and-precedent.md) - Intake fields, lanes, SLAs, escalation, and exception register
- [references/accounting-legal-constraints.md](references/accounting-legal-constraints.md) - Revenue-recognition and legal routing rules
- [references/worked-examples.md](references/worked-examples.md) - B2B spec, PLG/B2C equivalent, and negative example
- See `mbfinotti/revops-skills@revenue-leakage` to detect margin erosion
- See `mbfinotti/revops-skills@sales-pipeline-hygiene` for stage discipline and pipeline integration
- See `mbfinotti/revops-skills@sales-forecast-diagnostic` for period-end deal slip