Tony:

Hello, I’m Tony Mangino from TC2, and this is Staying Connected—the podcast where we talk about what really matters to enterprise buyers navigating today’s technology and sourcing decisions.

I’m joined today by my colleague Brent Knight and we’re talking about benchmarking across cloud, software, and network services.

On paper, the question is simple: is this offer competitive, and should we sign it?

But a cloud agreement, a SaaS renewal, and a global network services deal don’t behave the same way. They all sit under the technology umbrella, but the economics, risks, and supplier playbooks are different.

Guest:

That’s the practical challenge. Everybody wants an apples-to-apples comparison, but the apples are not always apples.

A cloud deal might look attractive because of credits. A software deal might look attractive because of a big discount off list. A network deal might look attractive because certain unit rates improved.

But each of those can hide something: commitment risk, renewal exposure, transition cost, scope gaps, or flexibility you thought you had but don’t.

Tony:

Right. So the real question is not just, “Which deal is cheaper?”

It’s, “Which deal creates the right long-term value, with the right flexibility, and with risks we actually understand?”

Why the Comparison Gets Hard

Tony:

Let’s unpack the apples-to-apples idea, because buyers hear that phrase all the time.

Guest:

They do. And it’s useful, but only if you define it correctly.

Apples-to-apples, or “like-for-like” doesn’t mean forcing every deal into the same format. That can distort the analysis. A cloud agreement shouldn’t be evaluated exactly like a network contract. A software renewal shouldn’t be treated like a benchmark for network circuits.

Tony:

So it’s not about making the deals look the same. It’s about making the decision fair.

Guest:

That’s it. You normalize what matters.

What are we buying? How will we use it? What are we committing to? What happens if the business changes? And where might cost show up later in a way that is not obvious in the supplier’s proposal?

Tony:

Take cloud. Credits and migration incentives can be valuable, no question.

But the commitment is the thing you live with. If the forecast is too aggressive, or if workloads don’t move as planned, the deal can become expensive even though it looked smart at signing.

Guest:

Software has the same kind of trap, just in a different form.

A supplier may bundle several products together and show a healthy discount. That sounds good. But then you have to ask whether you’re actually using the bundle, whether you can reduce later, and what happens at renewal when the initial incentives are gone.

Tony:

And network services bring their own complications. You have different site types, diversity considerations, revenue commitment and individual circuit terms.

A single rate improvement won’t tell you whether the overall deal is strong.

What the Benchmark Needs to Test

Tony:

So when a benchmark is done well, what should it actually test?

Guest:

Start with the basic economic question: what does this deal really cost?

Not just the year-one cost. Not just the unit rate. The full economic picture.

Where are the recurring charges? What are the PMO or LCM charges, if any. What one-time costs are required to get there? What is the surcharge applicability? Are credits guaranteed or conditional?

Tony:

That already gets you past the headline.

Guest:

It does. But then you have to look at structure.

And I don’t mean structure in an academic way. I mean the terms that decide whether the deal still works after the ink is dry.

Can the customer adjust commitments if usage changes? Is there price protection? What happens at renewal? Do you have a meaningful backend transition period? Are audit rights balanced?

Tony:

That’s where organizations get caught. They may win on price and lose some of the value back in the mechanics.

Guest:

Yes. A supplier can sharpen the price and still protect itself through the structure. That’s not unusual. It’s how sophisticated suppliers manage margin.

Tony:

And then there’s operating reality. A benchmark can be mathematically clean and still miss how the business actually works.

Guest:

That’s a great way to put it.

For cloud, can the enterprise really consume at the level it is committing to? For software, does the license model match how people use the platform? For network services, does the proposal reflect the actual footprint and migration path?

If the benchmark doesn’t connect to those realities, it becomes a spreadsheet exercise. Interesting, maybe. But not decision-ready.

Benchmarking as a Strategy Tool

Tony:

One of the points we’ve been emphasizing at TC2 is that benchmarking is not just a data point. It’s a strategy tool.

Guest:

Yes. The benchmark should help the customer decide what to do next.

Maybe the offer is strong, but renewal protection is weak. Maybe the price is still off market. Maybe the economics are fine, but the commitment is too aggressive. Or maybe the supplier’s position tells you it’s time to run a competitive process.

Tony:

So the benchmark shouldn’t just sit in a report.

Guest:

No. A useful benchmark changes the conversation. It gives the team a market position, a target, and a clearer sense of what to push, what to trade, and what not to concede.

Tony:

It also helps internally. IT, finance, sourcing, legal, and operations all look at these deals through different lenses.

Guest:

Right. The benchmark gives those groups a common fact base before the supplier starts creating urgency. It doesn’t eliminate tradeoffs, but it makes the tradeoffs more productive.

Practical Buyer Questions

Tony:

For an enterprise customer looking at a major cloud, software, or network deal right now, what should they ask before deciding whether the offer is competitive?

Guest:

Start with scope. What are we actually buying, and what are we not buying? Exclusions are where surprises often begin.

Tony:

Then demand. Are we committing to what we realistically expect to use, or to a growth story that may not happen?

Guest:

Then lifecycle cost and flexibility. What does the deal cost over the full term? What makes the cost go up? Can we reduce, shift, right-size, or move away if the strategy changes?

Tony:

And risk. What happens if migration takes longer, usage is lower, products change, sites close, users leave, or renewal pricing resets?

Guest:

Finally, what is the benchmark analysis telling us to do? If it doesn’t lead to a decision, a negotiation position, or a better set of tradeoffs, it hasn’t gone far enough.

Common Mistakes

Tony:

Let’s call out a few mistakes, because these show up a lot.

The first is just treating a discount as proof of competitiveness.

Guest:

Yes. A discount can be real and still not be enough. It depends what it’s measured against. A discount from list is not the same thing as a market-leading outcome.

Tony:

Another mistake is benchmarking the easy parts.

Guest:

Right. In cloud, the easy part may be the rate card. In software, it may be the discount percentage. In network services, it may be the recurring rate. The harder questions are usually about commitment, renewal structure and transition costs.

Tony:

And timing matters. Benchmarking is most useful before the strategy is set.

Guest:

After that, it may still be informative, but the leverage is different.

Closing Remarks

Tony:

The key takeaway is that benchmarking cloud, software, and network deals is not about forcing unlike deals into one simple comparison.

It’s about understanding the variables that actually drive value. Price matters. But so do commitment, flexibility, operating reality, renewal structure, transition exposure, and supplier leverage.

A good benchmark should help answer a practical question: are we making the right technology decision, at the right price, with the right terms, for the operating future we actually expect?

Brent, any final thoughts?

Guest:

Enterprise customers don’t need more numbers for the sake of numbers. They need context.

They need to know what the market supports. They need to know where the supplier’s offer is strong and where it’s exposed. And they need to know what changes would make the deal better.

That’s when benchmarking becomes useful. Not as a report on the shelf, but as a strategy tool the customer can actually use.

Tony:

That is a great place to leave it.

To our listeners, if you would like to discuss benchmarking cloud, software, network services, or how to compare complex supplier proposals without losing sight of lifecycle value and commercial risk, or if you’d like to discuss other technology strategy, sourcing and cost reduction needs with Brent, me, or any of our TC2 and LB3 colleagues, please give us a call or shoot us an email.

You can also stay current by subscribing to Staying Connected, by checking out our websites, and by following us on LinkedIn.