Is it another platform, or does it replace one?

Is it another platform, or does it replace one?

A head of people and culture at a furniture retailer did the count.

"I had over 20 different logins with different passwords to different platforms."

Incident reporting is one platform. Audits are in that one too. Maintenance requests, same one. Write-offs are somewhere else again:

"And that's another platform again. Write-offs , another platform again, where we upload photos. We've got so many platforms."

Meanwhile, at a fashion retailer of around 60 stores, a general manager opened a vendor call with the question that vendor was going to be asked for the rest of the year:

"My question to you is , is it another platform? Does it replace a couple of platforms? Like, we're just really hesitant to have any more platforms in our life."

That isn't a procurement question. It's now the only question. Across eighteen months of conversations with retail operators, tool sprawl came up as a problem in two dozen of them , and in almost exactly as many, "it has to replace something" came up as the reason not to buy. It's the same sentence pointed in two directions.

"Does it replace something?" is the first question now, not the last

It used to be the last slide. What does it integrate with, what does it cost, and by the way what goes away.

Now it arrives in the first ten minutes, in near-identical language, from buyers in categories that share nothing else. One operations manager stated it as a standing rule:

"Looking at what it can replace in our business rather than an additional tool. Providing the team with another thing to access is not what we want to do."

Retail software used to be sold on capability. It's now sold on subtraction. Any vendor still leading with everything their product adds is answering a question nobody in the room is asking.

Sprawl costs the support office money. It costs stores the answer.

Two different problems wear the same word, and they have different fixes.

The P&L version is the one that gets a line in a board pack:

"Our problem is when we have too much tech and the cost of these SaaS programs in my P&L just build up , and being able to even quantify the multitude that exist."

Read the second half again. Not "they're expensive." We can't count them.

The floor version is worse, and it never appears in a board pack at all. A group operations manager at an apparel business:

"Unless one product is going to replace a field, they go: where do I go for the information? Is that in the team room? Is that in the email? Is that in Piing? Is that in the KPI tool?"

That's a store person, mid-shift, with a customer waiting, running a decision tree about where an answer might live. Every login you add extends that tree by one branch , and none of the branches are wrong, which is precisely what makes it slow.

Another operator described what it looks like from the desk side: anyone on their team would have "four or five different platforms of software open that are all trying to talk to each other."

So a business with sprawl pays twice. Once in licences. Once in the seconds between a question and an answer, multiplied by every person on every shift in every store. Only one of those two ever shows up in the P&L, and it isn't the expensive one.

Retailers don't love the tools they have.

Here's the part most vendors mishear, and it's in the same breath as the objection.

The general manager who said "we're just really hesitant to have any more platforms in our life" kept talking. Unprompted:

"We don't think that every single one of our platforms is the bee's knees. So if our VM tool could be replaced, then that's something that might be of interest to us."

Both halves, one breath. We won't take another one. We're not happy with the ones we have.

That's not resistance to change. It's resistance to addition. They are completely different objections, and most vendors spend their energy answering the wrong one , building a case for why their product is better, to a buyer who never disputed it.

Others in the same eighteen months: one retailer describing their current priority as "getting some platforms and consolidating as much as we can." Another had already collapsed five separate HR and rostering products down toward one.

The appetite is there. The tolerance isn't.

"Replace" has three honest meanings

Most of the confusion in these conversations comes from a single word doing three jobs.

Retire , a contract ends, the old tool is switched off. This is what "replace" means to a CFO, and it's the only version that shows up as a saving.

Absorb , the workflow moves but the source system stays. The traffic sensor changes; the POS doesn't.

Remove a step , nothing is switched off, but someone stops doing a thing twice. Double handling ends.

All three are worth having. Only one of them is what your finance director heard.

So be specific about which is which. Here's the honest version for an execution platform.

Genuinely retired: a standalone traffic counter. An intranet-based tasking or checklist system. The spreadsheet-and-email loop for directives and weekly report chasing. The chat group that exists purely to ask whether things are done.

Genuinely not retired: your POS. Your payroll. The intranet where policy documents live. Your product and range data, if the new platform doesn't hold it.

That last one is not hypothetical. One prospect asked directly whether a platform could replace their incumbent tool, worked through it, and established that it couldn't , because the incumbent held product data. The honest answer was no, and the honest answer was given.

Name what you don't replace. It's the only thing that makes the rest of the list believable to a buyer who has been oversold before, which is all of them.

The one-basket objection is legitimate.

Two buyers, independently:

"My only concern would be , because everything is in the one spot , if you guys had a technical issue, an outage, and all the devices go down and they can't access anything."

"I'm kind of hesitant about being the same thing for the whole business… way too many eggs."

Both are right, and the buyers who raise this are the sophisticated ones. Consolidation genuinely does concentrate risk.

The answer isn't reassurance; it's design. What degrades gracefully. What works with no network. What a store falls back to at 8am on a Saturday when the connection is down and the doors open in five minutes. One operator's readiness benchmark was exactly that unforgiving: everything done and the shop open on time, consistently, or you may as well not have opened.

There's a related trap worth naming. From a retailer mid-implementation:

"That's the whole reason we've just put the links in the wiki at the moment, because we don't want to be updating in two places all the time."

Any consolidation that creates a second place to update has already failed. It hasn't reduced anything , it's added a synchronisation job and given it to a person.

Run the replacement audit before you take the demo

This takes about an hour and it changes how every subsequent vendor conversation goes.

1. Count the logins. Not systems the support office owns , logins a store team member is expected to hold. Do it literally, on paper. The operator quoted at the top of this piece got past twenty and stopped counting.

2. For each one, write the single question it answers. Where's the signage. What did we sell. Who's on tomorrow. What's broken. One line each.

3. Mark every question answered in more than one place. That's your double handling. It's also where the actual savings are , not in the licence line, which is the smaller number.

4. Mark every question answered in no place at all. That's your gap, and it's usually the same three: did the work get done, what did it cost, and what did it earn.

5. Now make the vendor map onto that list , and make them say out loud which rows they can't take.

The fairest standard anyone proposed came from a buyer, and it's more generous than most vendors deserve: "unless one product is going to replace a field." A field. Not a clean sweep. The bar is a column of your audit, not the whole spreadsheet.

The short version

Nobody is asking whether your next platform is good. They're asking what leaves the building when it arrives.

Count the logins first. Work out which questions are answered twice and which aren't answered at all. Then make anyone selling you something tell you which rows they can't take , because the ones who can't answer that haven't understood what you're actually buying, which is one less place to look.