Podcast: do you actually need retail pricing software?

Nobody wakes up thinking they should buy a new pricing tool. You get there because something stopped working - a file that takes minutes to open, a competitor list maintained by hand, a price nobody can explain. Which makes "do I need retail pricing software?" the wrong first question. The better one is what job your current setup is failing at.

In episode 2 of the Retailgrid Podcast, Retailgrid founder Maxim works through that decision the way a buyer should: the four jobs pricing work is actually made of, the specific signs a spreadsheet has stopped doing them, the four levels from spreadsheet to enterprise suite, and the one thing worth asking any vendor for before signing. Including the case where the honest answer is to keep the spreadsheet you already have.

Pricing is four jobs, not one product

Before evaluating any tool, it helps to separate what pricing work actually consists of. There are four steps, and most retailers only need help with one or two of them at first.

• Collect. Getting the data on the table - current prices, cost information, sales performance, stock, product and category data - plus external data like competitor prices and market data, all in one place.
• Decide. Working out whether the current price is optimal, using sales performance, margin rules and competitor rules to calculate a new one.
• Apply. Pushing the accepted prices back to the commerce platform or the ERP.
• Audit. Being able to answer when a price changed, why, and who changed it.

A spreadsheet does all four perfectly well for a small business with one store and a limited catalog. The episode is clear on this point: for many companies, keeping the spreadsheet is the best return on investment available. The question is what changes that.

The signs a spreadsheet has stopped working

They are boring and specific, which is what makes them useful:

• Speed. With thousands of products, it takes minutes just to open the file and update the data. Repricing that used to take minutes with simple rules no longer happens fast enough.
• Competitor matching by hand. Maintaining the match between internal and external data becomes a constant job of its own as the catalog and the competitor set grow.
• No audit trail. Someone changed a price two months ago and nobody can reconstruct why, who, or on what basis. It turns into a collaboration problem, not just a data problem.
• Too many copies. When pricing is shared across departments, versions multiply and have to be merged. Discrepancies creep in, and pricing mistakes cost money.

There is a strategic version of the same point. If you sell mass-market categories rather than luxury or premium, repricing monthly on a small share of the assortment is a real competitive risk. Being dynamic - and matching price to demand, which means understanding price elasticity - is something a spreadsheet cannot support at scale.

The four levels, from spreadsheet to enterprise

Rather than a binary between spreadsheet and software, the episode frames the choice as four levels, each of which is the right answer for someone:

• Spreadsheet. Small catalog, stable prices, one clear owner. Still a good tool.
• Spreadsheet plus price monitoring. When competitor data updates daily or weekly and you need to be more dynamic, adding monitoring or a dynamic pricing tool is the next step.
• Pricing platform. When you already have monitoring, pricing and margin rules, a big assortment, and enough sales history to model elasticity.
• Enterprise suite. Big departments and many people, where the conversation is about SLAs, security and stability at scale rather than pricing functionality.

The warning attached to that last level is worth repeating: if you are not enterprise today, an enterprise platform is overkill. It is feature-rich but very expensive, can take years to implement, and the binding constraint is usually not cost but your own resource availability to support it. We have written more on that trade-off in retail pricing software versus enterprise suites.

Ask for a sandbox, not a demo

The most practical advice in the episode concerns how to evaluate a shortlist. Do not judge a vendor on generic dashboards. Ask for a sandbox with your own data and your own data model, and reproduce part of your existing spreadsheet in it - the same calculation - to see how fast it is, how accurate it is, and how quickly the data goes in.

The reasoning is blunt. If pushing data in is not possible at the pre-sales stage, the same problem appears right after signature, except by then you are paying and locked in. Ask for sandboxes and test trials, and prove it works at small scale before committing to the whole project.

There is no silver bullet

The recurring mistake is treating software as something you can outsource the problem to. A tool is a tool: good results are possible in a spreadsheet, and bad results are possible with sophisticated, expensive software. The episode is candid that vendors, Retailgrid included, tend to overpromise here.

The second half of that mistake is internal capacity. A familiar pattern is the top level buying an expensive tool while the middle level has no time to use it and IT has no resource for data integration. The project stalls, the money is spent, and neither side gets what they wanted - the client sees no benefit and the vendor gets no reference.

Where this leaves pricing teams

Our view at Retailgrid: the useful question is not spreadsheet versus software, but which of the four jobs you want to stop doing by hand, and in what order. Collection usually comes first, because optimization built on stale or hand-matched data is not worth automating. That is why we build pricing as explainable, auditable, rules-based decisions inside an interface that behaves like the spreadsheet teams already use - so the next step does not require a learning curve or a long project. You can see how that works on our AI Workspace page.

Watch the full episode on YouTube, and subscribe to the Retailgrid channel for future episodes on pricing strategy and AI in retail.