How to Tell Whether a Software Rollout Will Pay Before You Sign for It

The problem: A six-figure software decision gets made on a demo and a reference call, and nothing you looked at beforehand would have told you whether it was going to work here.

The solution: Test the decision against the numbers the tool will have to act on, so you know before you sign whether the return is available at all.

The math

An $8M retailer that writes off a failed rollout at roughly $150k in licenses, staff time, and cleanup has spent about the cost of two full-time buyers on a decision nobody was ever in a position to evaluate.

There is a decision an owner at this size makes every couple of years, and it is one of the largest they make. A system goes in. Inventory, ordering, point of sale, something that touches how the business runs. The quoted license is $30k or $40k, the real cost with staff time and disruption is several times that, and the case for it is a demo, a reference call, and a strong feeling that the current way cannot continue.

Compare that to how the same owner buys a truck. They know what the last one cost to run, what routes it covered, what it did to delivery times. The technology decision is bigger and gets less scrutiny, not because owners are careless, but because nobody has ever shown them what there was to look at.

The demo is not evidence

A demo tells you what the software can do with clean data in a controlled environment. That is genuinely useful information about the product. It is close to useless as a prediction about your business, because the product is almost never the thing that fails.

What fails is the fit between the tool and the numbers it has to act on. A reorder system is only as good as your stock counts. A pricing tool is only as good as your cost records. A scheduling tool is only as good as knowing who is qualified for what. In the demo, all of that is perfect. In your business, the online store, the back room, and the supplier each have a different count for the same item, and none of them is wrong on purpose. They were simply never reconciled, because until now nothing was forced to choose between them.

Software forces the choice. It picks one number, because it has to pick something, and then acts on it hundreds of times before anyone notices. That is the mechanism behind most write-offs at this size. Not a bad product, a product asked to act on numbers that disagree.

Four questions that predict the outcome

The useful part is that this is checkable in advance, cheaply, before anything is signed. Four questions do most of the work.

What numbers does this tool have to be right about? Name them specifically. Stock on hand, unit cost, customer history, whichever the tool will act on. If the vendor cannot answer this, that is a finding on its own.
Where does each of those numbers live today, and do the copies agree? Pull the same twenty items from every system that holds them. The disagreement rate you find is the single best predictor of whether the rollout holds.
What decision will change because of this, and who makes it now? If the answer is that nobody makes the decision today, the tool is not replacing work, it is adding it.
What would tell us in ninety days that this is working? Pick the measure before you buy, while you can still walk away, rather than after, when the sunk cost argues for you.

None of that requires technical knowledge. It requires an afternoon and a willingness to hear an answer you do not like.

What makes a project likely to fail

Rollouts at this size fail in patterns, and the patterns are visible before the contract.

The first is sequence. When the numbers underneath disagree and the tool goes in anyway, the tool does the wrong thing quickly and at scale, and the cleanup consumes the time the tool was bought to free. Connecting and reconciling those numbers first is unglamorous and considerably cheaper than doing it after a failed launch, when it has to be done anyway plus the write-off.

The second is that nobody owns the numbers. If no one is responsible for what a product's cost is, then within a quarter the system holds the same disagreements the spreadsheets did, and it holds them with more authority.

The third is scope. A rollout that changes six things at once cannot be evaluated, because when the result is ambiguous nobody can say which part worked. One clear job, measurable in ninety days, is worth more than a platform, and it is the only version of the decision you can learn from.

A look at a specialty retailer

Take a specialty retailer doing about $8 million a year across a store and a growing online channel. Demand is strong, the back room is chaotic, and the owner is looking at an inventory and reorder system with a $35k license and an implementation quote on top.

Run the failure case first, because it is the one worth pricing. Suppose the counts feeding the tool come from three places that were never reconciled. You would expect it to reorder products they were already deep on, and let a bestseller sell past zero into oversells and refunds. After a few months of cleanup the rollout would be a write-off: licenses, implementation, and staff time on the order of $150k, before the lost sales and the customers who do not come back. Nobody would be able to say afterward whether the product was any good, which means the next purchase would be made just as blind.

Now suppose the owner spends an afternoon on the four questions first. Pull twenty items and compare the counts across the store system, the online store, and the last supplier statement. If a meaningful share disagree, that is the answer: the reorder tool cannot work here yet, and buying it would be paying $150k to find that out. The sensible sequence is to connect the products, counts, and costs into one picture where a change in one place is true everywhere, name an owner for each, and only then put the tool on top of it, scoped to one job with a ninety-day measure agreed in advance.

What the retailer gains is not mainly the avoided write-off, though you would expect that. It is that the decision becomes repeatable. The next system, and the hire and the location competing with it for the same money, get judged the same way, and being wrong costs a quarter instead of a year.

How to start

Name the numbers the tool must be right about. Write them down before the next demo, and make the vendor speak to them specifically.
Test twenty records across every system that holds them. The disagreement rate is your risk, and it takes an afternoon to measure.
Fix the sequence if the test fails. Connect and reconcile the numbers first, with a named owner for each, and let the routine matching run on its own so they stay reconciled.
Scope it to one job with a ninety-day measure. Agree what success looks like while you can still say no, and buy the next thing on what you learn.

The takeaway

The reason technology decisions at this size go wrong is not that owners buy bad products. It is that they buy on a demo, which cannot tell them the one thing that determines the outcome: whether the numbers the tool depends on agree with each other today. That is checkable in an afternoon. Check it, connect what does not line up before the tool goes in rather than after, scope the first rollout to a single job you can measure, and a six-figure decision stops being an act of nerve. Then the money can be argued against a hire or a location on the same terms, which is the comparison you actually wanted to make.