It’s Not a Feature. It’s an Operating Model.

QUICK ANSWER. No single use case in coffee service pays for itself on its own. Remote resolution, usage-based intervals, replenishment and warranty evidence each return something modest alone. The return comes when they run on the same data and feed each other. So what you buy is a coffee service operating model, a change in how the operation decides. Judge it that way.

Every article in this series argued for one thing. Fix more faults on the first visit. Stop sending trucks for faults that need no truck. Service machines on usage instead of the calendar. Trigger deliveries from consumption. Send the next technician to the account with the most revenue at risk.

Each argument stands on its own. But each one, bought on its own, tends to disappoint. That pattern says something about what an operator buys when they buy operational intelligence.

Why doesn’t any single use case justify the investment?

Because each use case needs the same foundation, and the foundation costs more than the use case.

Take the strongest single case in the series. Support can resolve more than 25% of downtime without a technician, once they can see the machine. The figure comes from public operator experience, and we covered it in A Quarter of Your Downtime Doesn’t Need a Truck. Now try to build the business case on that alone. First you need connectivity across a mixed fleet. Then you need a support process that trusts the data. Finally you need technicians whose schedules change as a result. By then you have built most of the platform, and you use it for one thing.

Every use case in coffee service is cheap to justify and expensive to deliver on its own. Together they are expensive to justify and cheap to deliver.

So that is the trap. Priced feature by feature, nothing clears the bar. Priced as a change to how the operation runs, the same money looks like an easy decision. The unit of value is the whole operation, never the module.

What does a coffee service operating model mean in practice?

Four things, and none of them is software:

• Which decisions. Which machine to visit today, which contract to renegotiate, which model to stop buying, which site to move a machine out of.
• Who makes them. Whether dispatch priority sits with the person who answered the phone, or with the person who owns revenue at risk.
• On what evidence. Whether the answer comes from memory and the loudest customer, or from fault frequency per model, normalised by usage, and margin per account.
• How often. Whether someone reviews the fleet once a month, in arrears, or watches it every day. That gap is the difference between reporting and control.

Software changes none of those by arriving. It only makes a new set of answers possible. The operators who get value then change the answers. The ones who do not end up with a dashboard and nothing else, which is the argument in Telemetry Is Not an IT Project.

How do the pieces pay for each other?

One loop shows it. When support sees the fault before the customer calls, fewer incidents become visits. The visits that remain arrive with the root cause and the history, so first-time fix rises. Each avoided repeat visit frees technician hours. Those hours let preventive work land on schedule, on the machines whose usage calls for it. Then fewer machines fail, so fewer emergencies push the plan aside. Each step makes the next one cheaper.

Meanwhile the same data does commercial work. Consumption triggers replenishment before a stockout. The gap between cups brewed and coffee delivered exposes revenue leakage. Margin per machine finally answers which machines make you money.

That is one dataset and six decisions. We showed why the effect grows with fleet size in At 10,000 Machines, Small Improvements Become Large Outcomes. This article is about what the loop means for the buyer.

What goes wrong when you buy it as a feature?

Three failures, and each one is predictable enough to plan around.

1. The pilot that proves nothing. One use case, one region, six months. Its result comes out too small to separate from normal variation. So the pilot was honest, but the unit of measurement was wrong.
2. The dashboard nobody opens. Here the data is correct and available. But no route plan, no dispatch meeting and no renewal review has a step that consults it. So the week runs the way it always did.
3. The business case that always loses. Each module has to justify itself alone, and each returns a modest number. Then the programme dies on the sum of its parts, and nobody ever prices the compounding effect.

All three come from the same mistake. They treat an operating model as a purchase instead of a change.

What should you ask a supplier instead?

Change the question. “What does the platform do?” invites a feature list. Instead, ask which decisions your people will make differently on the first Monday after go-live, and who will make them. If nobody can name the person, the decision, the evidence and the cadence, the value will not arrive. That holds however good the technology is.

The answer also sets what has to be true underneath. The loop above only works if the whole fleet reports in one language, and almost no operator of scale runs a single manufacturer. EVA, the European Vending & Coffee Service Association, counts roughly 4.5 million installed machines across 24 European markets, in a market worth €22.67 billion. Mixed estates are the rule there. So normalising data across brands comes first. It is the floor the whole model stands on, and we described that problem in Why Every Coffee Machine Brand Gives You Different Numbers.

The full nine-step model, its sequence and what each step needs, is the substance of our office coffee service report. This article makes the case for why it is a model and never a menu.

Key takeaways

• No single use case pays for itself on its own. Each is cheap to justify and expensive to deliver alone. Together they are expensive to justify and cheap to deliver.
• A coffee service operating model is which decisions, who makes them, on what evidence, and how often. Software changes none of those by arriving.
• The value is a loop. Fewer dispatches free technician hours, preventive work lands, failures fall, and each step makes the next cheaper.
• Three failures follow from buying it as a feature: the pilot that proves nothing, the dashboard nobody opens, and the business case that always loses.
• Ask a supplier which decisions change on the first Monday after go-live, and who makes them. Then check the fleet can report in one language.

Request the white paper. From Coffee Machines to Profit Machines: a step-by-step model for a more profitable office coffee service operation.

Which decision in your operation would you most like to stop making from memory?