Before the summer break, I wrote about what pricing looks like when it lives in spreadsheets. Four Excel files, two with the same name, none of them matching the ERP, and the "current one" sitting on Mildred's laptop, to be forwarded later. Sort of.
When I share that picture with pricing, finance, and sales leaders at mid-sized manufacturers and distributors, the reaction is almost always the same: a laugh of recognition, followed by some version of "We know. We've kind of known for years." It's that second part that sticks with me. At most companies, nobody needs to be convinced the pricing spreadsheet is a problem anymore, and yet the folder is still there, still growing a new "FINAL v3" every quarter.
The pain also goes well beyond version chaos, and a lot of it comes down to plain speed. Two of the companies we're working with right now are replacing spreadsheet-based pricing for exactly this reason. When a supplier cost change comes in, it takes them at least a week, sometimes two, to turn it into updated prices on the website and in the hands of the field sales team. Someone has to find every file the change touches, update each one by hand, check the math, and push the results out to the systems and people who need them. In their words, it's "drudgery".
That lag has a very real and quantifiable cost. Every day between a cost increase and a price update, you're selling at yesterday's price on today's cost. Put some simple numbers on it: if a 5% cost increase touches $50M of annual revenue, each week of delay gives away roughly $48,000 of margin, so two weeks is close to $100,000 on a single cost change. Most companies absorb several of those a year, and the spreadsheets don't get any faster the next time. (And that's before counting what the drudgery costs in people. The analysts stuck doing the updating are usually the same people you'd want doing the analysis and higher-value things.)
So admitting the spreadsheet is broken turns out to be the easy part. Most pricing teams already know it's a liability. Very few of them can describe what would actually replace it, and that gap is where a lot of good intentions quietly stall out.
The meeting that keeps happening
You've probably been in this meeting… It tends to show up at budget season, or right after a quarter where margin slipped and nobody could fully explain why. Someone puts the version chaos on a slide, the VP of Sales says the reps need better tools, the CFO says finance needs better visibility, and eventually someone says, "We really need a better way to manage our pricing." The action item gets written down as "Explore options." Usually teams get busy and don't follow-up. Or, they do, and up until lately, they find out that a pricing solution will cost them $400k/year and $2M to implement.
Part of the reason this loop keeps repeating is that the pain is chronic rather than acute. Nobody gets a 2 a.m. phone call because the pricing folder is a mess. Margin leaks in little drips and drops, a few basis points at a time, across thousands of transactions, while a plant outage or a failed ERP upgrade gets everyone's attention by lunch. Even that week or two of lag after every cost change eventually stops feeling like a problem and starts feeling like "just how pricing works here." Slow leaks tend to lose the budget fight to loud fires. It doesn't help that the problem is spread across the whole company, as we talked about earlier in the series. Sales feels the spreadsheet at the quote, finance feels it at quarter-end, and customer service feels it when a customer disputes an invoice. Everyone sees their own slice, and nobody is on the hook for the whole thing.
The bigger blocker, though, is one that rarely gets said out loud: nobody can write down what "fixed" looks like. "We need a real pricing system" is a feeling, and you can't hand a feeling to IT or to a vendor. Without a clear picture of what the replacement has to do, "Explore options" has nowhere to go, so it goes nowhere.
The fixes everyone reaches for first
When companies do try to break the loop, they usually reach for one of four things. Each one is reasonable on its face and has a real place in the business, but none of them, on its own, replaces the folder.
- A better spreadsheet. A master file with locked tabs, data validation, a naming convention, and a stern email about local copies. I covered this last time, so I'll keep it short. Excel is a wonderful single-user calculator, and you're asking it to behave like a multi-user, audited business application. A better spreadsheet usually buys you a quarter or two of hygiene before the copies start multiplying again.
- Customizing your ERP or CPQ. This feels like the responsible, "use what we already paid for" option, and your ERP really is the right home for transactions. The trouble starts when pricing logic gets bolted in as custom tables and one-off code that only one IT person understands. Every pricing change becomes an IT ticket, and the IT backlog always has something more urgent. CPQ has a similar catch. It's excellent at configuring products and producing clean quotes, but it consumes prices more than it decides them. If the guidance feeding it is weak, CPQ just helps your reps quote the wrong number faster, with a nicer PDF.
- A BI dashboard on top. Now the mess is visible, and I'll admit that's real progress (I'm a fan of good BI). But a dashboard is read-only by design. It can show you that a customer's pocket price drifted below target last quarter. It can't set the target, enforce the floor at the quote, or expire the special pricing agreement that caused the drift, so you end up with a very clear view of a problem you still can't act on.
- Having your sharpest analyst build something. Most companies have this person. Years ago they built it in Access/Excel with VBA, more recently in Python, and today they can vibe-code a surprisingly capable pricing app over a weekend with an AI coding tool. These tools are often genuinely useful, and they almost always become a single point of failure the day that person takes a vacation or another job. (We'll spend real time on this path in a few weeks, because it deserves a fair hearing.)
Look at the four together and a pattern shows up. Each one starts with a tool the company already has, or already knows, and asks, "Can this do pricing?" That's asking the question in the wrong order.
Start with the job, then pick the tool
Think about how you'd hire for an important role. You wouldn't post a job listing that says "Must be proficient in Excel" before you'd written down what the person actually needs to accomplish. You'd start with the responsibilities and what good performance looks like, and the skills and tools would come after.
Your pricing system deserves the same treatment. Before anyone looks at a demo, write a one-page job description for it.
Start with the decisions it has to support: setting list prices, deriving customer and segment pricing, guiding the rep before the negotiation starts (your Target, Stretch, and Floor), approving exceptions, responding when a supplier or tariff pushes costs up, and explaining after the fact why margin moved.
Then note who makes each of those decisions and where they're sitting when they make it. The rep is in the quote screen, probably with a customer waiting. The category manager is in the middle of an annual price update. The e-commerce team needs the new prices on the website, and the finance partner is trying to close the month. A pricing system that works beautifully for one of these people and is invisible to the rest hasn't really done the job.
Finally, write down what "good" looks like, in plain and testable terms. For example: "A rep can see target, stretch, and floor for any customer and SKU, inside the screen where they quote, in seconds." Or: "When a cost increase is approved, every affected price is updated in the field and on the website within a day." That second one alone would have saved our two clients a couple of weeks every time a supplier letter showed up.
Once that page exists, hold every option up against it, including the spreadsheet. You'll probably find the spreadsheet handles one or two of the jobs well enough and fails the rest in ways that are now easy to see and easy to put a number on.
Writing the page also changes the conversation inside the company. "Which tool should we buy?" invites opinions and a lot of stalling. "Which of these jobs are we failing today, and what's that costing us?" is a question your CFO will actually lean into, and one you can answer.
Where to start tomorrow
Pull the last five pricing decisions that went sideways or took far too long. Maybe it was a quote that went out at the wrong price, a special pricing agreement that kept getting honored a year after it should have expired, a cost increase that took weeks to reach the website and the field, or a margin miss nobody could explain in the quarterly review.
For each one, trace where it broke. Was the data wrong? Was there no clear owner? Did the right number exist somewhere, just not where the rep was looking? Could anyone explain what happened afterward?
Patterns usually show up quickly, and most companies find the same couple of failure points repeating. Those are the first lines of your job description.
You'll know what to do next.
Next week, I'll put some structure around that job description: the six things a real pricing system has to do. If you read the "Excel Hell" piece, some of them will look familiar. A couple are new, and they're the ones companies most often forget to ask for until they've already signed a contract.
Revomo is built around exactly these jobs, from the quote moment to the month-end margin conversation. If you've started drafting a job description for your own pricing system (or tried and got stuck), we'd be glad to compare notes. The first look is on us.