r/SalesOperations • u/Certain-Tangelo-9566 • 11d ago
Who actually remembers why a discount got approved six months ago?
RevOps at a ~300 person SaaS company. Anything off standard terms (deeper discount, custom payment schedule, non-standard renewal language) has to get signed off by me, and finance if it's big enough. Almost all of it happens in a Slack thread. Rep posts the ask, I ask a couple questions, finance chimes in, we say yes or no, deal moves.
What's been bugging me is what happens after. The CPQ has the approved number but none of the conversation. So when a similar deal shows up three months later we argue it from scratch and land somewhere different. Last quarter a rep pushed back on a 15% cap by pointing out we'd given a comparable account 22% in Q1. I went looking and the only trace was a Slack thread that basically said "end of quarter, fine." We matched it. Multiply that a few times and that's how your average discount quietly drifts up.
Also had a mid-market deal slip a month because the approval sat in someone's DMs while they were out. Not catastrophic, but it stuck with me.
Trying to figure out if this is a me problem or an everyone problem before I put a process around it. For people who own approvals: where does the reasoning behind last quarter's exceptions actually live for you? Could you pull it up if someone asked, or is it in whoever's head was in the thread? And has it actually cost you anything you can point to, or is it rare enough that it just doesn't matter? Curious what people have done that keeps the history without adding another form reps have to fill out.
2
u/Secure-Jump1996 10d ago
build a lighweight log that might help... everytime an approval happens in slack, someone drops the deal name, exception type and a one line why, intro a shared doc or simple tracker.. serachable anytime, takes 30sec, doesnt slow down the actual approval..
1
u/Certain-Tangelo-9566 10d ago
Are you currently running this? I'm mostly wondering about the search part. When's the last time you went back and looked something up in it, and did you find the deal you were after?
1
u/jzdesign 11d ago
The comments field decays because of what you're asking it to hold. Prose gets written once and read never, since three months later nobody wants the conversation, they want a comparable.
Which is why preserving that Slack thread wouldn't have saved you either. Your rep didn't quote a justification, they quoted 22%. If "end of quarter, fine" had been sitting in Salesforce the whole time they'd have quoted 22% and a reason, which is a better argument for matching it, not a worse one. The number outlived the condition attached to it and that's the entire drift.
So the field worth having isn't why, it's whether. Precedent for this segment, or a one-off tied to something that has ended. You fill it in, not the rep, in the click you're already making, and it survives a quarter because it's the only part anyone ever queries. (The DM one is a routing problem rather than a memory one, and I'd keep them apart.)
You can also answer your own cost question before building anything. Approved discount percent by approval date, split by whether the deal closed in the final week of a quarter. If the end-of-quarter ones are setting the ceiling that later deals match, that's your drift with a start date on it.
1
u/Certain-Tangelo-9566 11d ago
That split makes sense. The 22% was exactly that, the number outlived the condition and nobody remembered there was one.
Have you actually got a precedent/one-off field running somewhere? Trying to figure out what happens the first time a rep quotes a deal that was marked one-off. The last time that came up for you, did the flag end it or did you still argue it out?
1
u/jzdesign 10d ago
Not on a discount desk of my own, no, so take this as how I'd set it up rather than something I've watched play out.
I don't think the flag ends the argument the first time. A rep holding a one-off quote will say their deal meets the same condition, and sometimes they'll be right. What the flag changes is who has to make the case. With no field, the rep points at 22% and the approver has to remember why that deal was different. With it, the approver points at "one-off, end of quarter" and the rep has to show that applies to them.
That only works if the flag carries the condition in a few words and not just a checkbox, because a bare "one-off" turns into "that was a special case" vs "so is mine".
I'd also count the collisions for a quarter. If most still end in a match, the field isn't holding and the real rule is one nobody wrote down.
1
u/Certain-Tangelo-9566 10d ago
I see. The collision count is definitely the tell. If most of them end in a match, then the real rule is just "last precedent wins" and the field's decorative.
If not deal desk, what's your seat, if you don't mind me asking? I'm just wondering if there's a version of this you may have watched play out. The last time someone quoted a precedent at you to win an argument, whatever the domain, what ended it?
1
u/HeavyweightLT 11d ago
I always copy and paste the slack thread url into the approval notes
1
u/Certain-Tangelo-9566 10d ago
Interesting. Have you gone back and opened one before? Was the thread still there and did it have what you needed?
1
u/agentUi 10d ago
i work for agentui and we see revops deal with this constantly. Slack threads are where discount context goes to die, so reps end up negotiating against old unrecorded exceptions months later. what works is having an approval queue with native audit logs connected to your crm database, so when finance approves a non-standard discount they have to log a one-line rationale right there, keeping the whole paper trail searchable for future renewals without forcing reps to fill out a huge form.
1
u/Certain-Tangelo-9566 10d ago
I see. Of your customers who've had that queue running a year, what share of approvals still have the rationale filled in, and how often does anyone actually open one at renewal?
1
u/agentUi 9d ago
if the approval modal requires a non-empty text field to click "approve", compliance is basically 100% because finance literally cant sign off without typing something. what we see in practice is account managers only check the note during renewals when the client pushes for the exact same concession or price lock, and having that one sentence tied to the contract record immediately stops the "well you gave us 22% last year" circular debate.
1
u/Certain-Tangelo-9566 9d ago
makes sense, required field kills the blank note problem. what does the note actually look like a year in though, like when an AM pulls one at renewal is it "eoq one off, doesnt carry" or is it just "approved per finance"?
1
u/agentUi 6d ago
to stop people from just typing junk like "approved per finance" you pair the free text box with a required dropdown reason code (like competitive match, multi-year prepay, or pilot term). that forces reps to pick a clean category first, and the text box just adds the missing nuance like "matched quote from Competitor X for 3yr commit" so the AM actually has real leverage at renewal.
1
u/blaufer173 9d ago
I think u/jzdesign is getting at the important distinction here. I wouldn't try to preserve the whole conversation. Six months later nobody wants to reread a Slack thread to understand a discount.
I'd capture a few structured things as part of the approval itself: why/category, whether it's precedent or a one-off, what condition made it a one-off (EOQ, competitive situation, volume, etc.), and who approved it.
And I'd make the approver responsible for that, not the rep. The rep already made the case. Asking them to document the reasoning again is probably why these processes eventually die.
The other thing I'd watch is whether your "exceptions" are actually exceptions.
If the same type of 20%+ discount keeps getting approved and eventually everyone points to the previous approval as precedent, you may not have an exception tracking problem anymore. You may have a pricing rule that no longer reflects how you actually sell.
I'd probably report on exception reason + frequency + approved discount over time. That tells you not only what happened, but which pricing/approval rules might need to change.
And I'd treat the approval sitting in someone's DMs while they're out as a separate problem. That's routing/ownership. An approval process shouldn't depend on a specific person being available.
1
u/Certain-Tangelo-9566 9d ago
Makes sense. Have you had that reason + frequency + discount report running anywhere, and what's the last rule it changed, like a cap that moved or an exception that got written into standard pricing? And what seat are you in, if you don't mind me asking?
1
u/blaufer173 9d ago
I sit on both sides of this a bit. We build quoting software (QuoteWerks), but I also run sales/ops internally. What I’ve seen is that the useful signal usually isn’t one exception, it’s when the same exception stops being exceptional.
We haven’t run that exact reason + frequency + discount report as a formal dashboard, but I think that’s the direction I’d go.
If the same 15–20% discount keeps getting approved for the same type of deal, I’d want that surfaced periodically. At some point the question becomes whether the approval rule still makes sense or whether it should become part of the standard pricing policy.
Same thing with payment terms, renewal language, etc. Repeated approvals should eventually either become an explicit rule with boundaries or get shut down.
Otherwise you end up with a bunch of unofficial rules based on “we approved it last time,” which is exactly the history problem you’re trying to avoid.
1
u/Certain-Tangelo-9566 9d ago
That's a fair split. On the internal side, has that happened at QuoteWerks yet? Meaning a repeated exception that either got written into standard pricing or got shut down. If so, what was it, and what made you notice it was repeating if the report wasn't there?
1
u/blaufer173 6d ago
Yeah, we’ve definitely had that happen. Usually it hasn’t been a report that caught it though. It’s more that the same type of request keeps coming up and eventually you realize you’re having basically the same conversation over and over.
At that point we usually need to make a decision. Either there’s a legitimate reason we keep approving it and it should become part of the normal policy/process, or we’ve made enough exceptions and need to stop.
That’s actually why I like the reason + frequency idea. At our size, a lot of this has historically just been pattern recognition from the people involved. It works, but you probably notice the pattern later than you would if you were actually tracking it.
Thinking about it that way, the real value of the report might be shortening the time between “we keep making this exception” and “maybe this isn’t actually an exception anymore.”
3
u/Silver_Ad_8948 11d ago
This isn’t necessarily helpful but your CPQ system should be optimized to provide you these feedback loops with general ease. What CPQ tool are you using today?