Ask the Vendor About Their Worst Customer

By Matt Wampler, CEO of ClearCOGS

There is a moment in most software evaluations that decides the outcome, and it does not happen on a demo call. It happens later, in a room with no vendor in it, when three or four people from the same company sit down and try to answer a plain question: is this worth more than it costs?

If the answer is fuzzy, the project dies. Not dramatically. It just does not make the list for next year, because four other initiatives had cleaner numbers attached.

I watch this happen from the other side of the table constantly, and the pattern is consistent enough to be worth writing down. The evaluations that stall are almost never the ones where the buyer decided the product did not work. They are the ones where the buyer believed it worked and could not build a number they were willing to defend in front of their CEO.

So this is a piece about building that number. Some of it is uncomfortable for a vendor to write.

Why software business cases have a credibility problem

Start with the reason your CFO is skeptical before you open your mouth. They have been burned, and the research says they are right to be.

Work on IT benefits realization found that most organizations focus on implementing the technology rather than on realizing the expected business benefits, so the benefits do not arrive even when the project is technically successful. The same work notes that few companies conduct post-implementation reviews at all, partly because they already suspect the benefits in the original business case were never realistic. Success gets measured as delivered on time, on budget, to spec, rather than as benefits actually collected (Peppard, Ward, and Daniel, MIS Quarterly Executive, 2007).

There is a blunter finding buried in that literature. In a survey of large UK companies, nearly half openly admitted to overstating benefits in order to get approval for IT investments.

Your finance team may not have read the research, but they have lived it. Which means the first job of a good business case is not to be optimistic. It is to be believable.

Size the prize from your own variance, not the vendor’s case study

The most common mistake is anchoring on a number someone else produced.

A vendor case study tells you what happened at a brand with a different menu, different volume, different labor market, and a different starting level of discipline. It is evidence the thing can work. It is not a forecast of your result.

The number you want is already in your own P&L. For a prep and ordering decision, the honest place to start is the gap between your theoretical food cost and your actual food cost. That gap is, roughly speaking, the size of the pool you are fishing in. Not all of it is recoverable, and some of it is portioning or shrink that no forecast will fix. But it bounds the conversation.

A worked example, with entirely illustrative numbers:

Whatever your real figures are, running that arithmetic does two things. It tells you quickly whether the project is even in the right order of magnitude, and it produces a number your CFO can interrogate, because every input came from your own books.

If your variance is not measured with any confidence, that is itself the finding. You cannot build a credible case on a quantity nobody tracks, and you have just discovered a more urgent problem than the software decision.

Ask for the worst outcome, not the best

The single best question I have been asked by a prospective customer was this: what did your least successful customer get?

Not the average. Not the flagship. The floor.

Most buyers never ask, which is a shame, because the answer tells you far more than a success story does. A vendor who cannot answer it either does not measure their own results or does not want to say. A vendor who answers it honestly is giving you the number your business case should actually be built on, because a case that survives the floor survives.

Build the case at the pessimistic end. If the project clears the bar on the worst realistic outcome, the approval conversation becomes short. If it only clears on the best outcome, you are asking your CEO to fund a hope.

Give every benefit an owner

Here is the failure mode specific to operations software, and it is the reason so many of these projects die quietly after approval.

The benefits land in different places. Reduced waste shows up in cost of goods. Time returned to a general manager shows up in labor, or in nothing at all if that time gets absorbed. Fewer stockouts show up in revenue. Better consistency shows up in guest feedback months later.

Four benefits, four different lines, and frequently no single person accountable for any of them. The benefits management research is direct about this: each expected benefit needs a named owner who is responsible for the value assigned to it in the business case, and who commits to the changes required to deliver it. Where organizations have made that ownership explicit, benefits get realized at a much higher rate.

So before the approval meeting, write down each benefit, how it will be measured, and whose name is next to it. If you cannot find a name for a benefit, take it out of the business case. It is not going to happen, and including it weakens everything else on the list.

Split the hard numbers from the soft ones, out loud

Some benefits are measurable and some are real but not measurable, and mixing them is what makes a business case feel like a sales deck.

Put the quantifiable items in the ROI calculation: food cost movement, waste, hours. Put the rest in a clearly separate section: manager quality of life, reduced dependence on one person’s institutional memory, fewer end-of-night judgment calls, better consistency when a location changes managers.

Those second-category benefits are frequently the ones operators care most about a year in. They just should not be doing arithmetic in your business case. Naming them honestly as unquantified makes the quantified part more credible, not less.

Capture the baseline before anything changes

This is the practical detail that sinks the most evaluations, and it is completely avoidable.

You cannot prove an improvement without a before. If you are mid-migration on a back office or inventory platform, or about to be, the historical data that constitutes your baseline may not survive the move intact. If you switch systems first and turn on a forecasting tool second, you will spend the following year unable to answer whether it worked.

Pull and preserve the baseline before you change anything. Food cost by period and location, waste where you track it, hours by location. Store it somewhere that does not depend on the system you might be leaving. This costs almost nothing and preserves your ability to measure, which is the entire point.

Sometimes the answer is that you do not need the software

The most useful thing in that benefits research is an example that argues against buying.

A health system with five hospitals was evaluating a new scheduling system to improve capacity. Working through the business case, they discovered that all five sites already ran the same software and simply used it differently. By making their practices consistent, they hit their capacity target without the new system, and spent the money on equipment instead.

The restaurant version of this exists and you should test for it. If your locations have wildly different food cost and they are all running the same tools, some of your gap is process drift rather than a missing capability. A structured pass at recipe accuracy and prep standards might recover a chunk of it for free.

Do that test first. If the gap closes, you saved the money. If it does not, you have just built a much stronger case, because you can show your CEO you already tried the cheap version.

What to bring to the approval meeting

A business case that tends to survive contact with a skeptical executive has five parts:

1. The size of the pool, derived from your own variance rather than a vendor’s case study.
2. A conservative recovery assumption, built on the vendor’s worst outcome rather than their best.
3. A named owner for every quantified benefit.
4. Unquantified benefits listed separately and labeled as such.
5. A baseline captured and stored before anything changes, with a specific date for the review.

Notice that four of those five are your work, not the vendor’s. That is the uncomfortable part. A vendor can supply evidence, honest floor numbers, and help with measurement design, but the case has to be built out of your numbers by someone inside your company, because that is the only kind of case that holds up when someone pushes on it.

Let’s Talk

Sources

• Peppard, Joe, Ward, John, and Daniel, Elizabeth. Managing the Realization of Business Benefits from IT Investments. MIS Quarterly Executive, 6(1), 1–11. 2007. oro.open.ac.uk