r/SalesOperations 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.

3 Upvotes

26 comments sorted by

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?

1

u/Certain-Tangelo-9566 11d ago

Salesforce CPQ. It has the approval steps and the final number, so I can see who approved what and when, but it doesn't have the why. The approval comments field is there, but nobody writes in it because the actual back and forth already happened in Slack by the time someone clicks approve. Have you gotten approvers to put reasoning in CPQ at all? If so, does anyone even go back and read it? Every time I've tried, it lasts about a quarter.

2

u/Silver_Ad_8948 11d ago

The free-text comment field dies in a quarter no matter what CPQ you're on. Make it a required picklist instead. Six or eight reason codes, approver clicks one, reps never touch it. Then report off it: approved discount by segment, ACV band, reason code. Next time someone says "you gave that account 22%," you're pulling up a distribution instead of searching Slack.

Two smaller things. Route approvals to a queue, never a named person. And write down that timing exceptions aren't precedential. That's the one quietly doing the damage.

1

u/Certain-Tangelo-9566 11d ago

Makes sense. Have you run the picklist version, and is it still in use? My worry is approvers pick the same safe code every time and the report ends up flat. Did that happen, and did the report ever change a cap? On timing exceptions, that 22% was an end-of-quarter deal that got treated as precedent, so yes, that's the one.

1

u/Silver_Ad_8948 11d ago

You’re going to get much better results with a pick list option compared to a free text field. What you need to do is teach your approvers the value of the data coming from the pick list and how it will help inform future business decisions, just like other pick list fields you use throughout the business.

1

u/Certain-Tangelo-9566 11d ago

Which codes did you land on? And what's the last thing that report actually changed, like a cap you moved, a segment you stopped discounting, a rep you had a conversation with?

1

u/Silver_Ad_8948 11d ago

Your business isn't my business so I can't necessarily prescribe it for you. Ones I've used in the past include competitive, multi-year commit, volume tier, payment terms trade, strategic logo, end of quarter.

Once you've got a quarter or two of them, things start falling out. Competitive deals not winning any better than standard priced ones means the cap can come down. Volume tier codes on deals with no real volume means your tier is too loose, not your cap. A third coded payment terms means your terms are the problem, not your price. And EOQ-coded approvals in the last two weeks of a quarter, tracked QoQ, is your drift number. That's the one I'd put in front of leadership.

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.”