evals/evals.json
{
"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 }
]
}
references/intake-routing-and-precedent.md
# 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. An hour or two 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.
SKILL.md
---
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.9"
---
# 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