Defining Colocation Requirements That Create Leverage

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

Today we’re discussing colocation from a strategic sourcing perspective. A lot of colocation discussions start with the obvious questions: which provider, which geographic market, and what’s the price? Those questions matter, but they are not usually where real value is won or lost.

In our experience, the biggest difference between an average sourcing outcome and a strong one is how well the enterprise defines its requirements before sourcing really gets underway.

To help unpack that, I’m joined today by my TC2 colleague Larry York.  Larry welcome back to Staying Connected.

Larry:
Thanks, Tony. Glad to be here.

Tony:
Let’s start here. Why are defining your specific requirements critical in colocation sourcing?

Larry:
If the enterprise is not specific enough, suppliers will invariably come back with different assumptions around power, support, interconnection, flexibility, and operating responsibilities. At that point, you are not really comparing equivalent offers that are aligned with your requirements. You are comparing supplier narratives.

Why It Matters for Enterprise IT Buyers

Tony:
And that is an important distinction, because a lot of teams assume that simply running a sourcing process creates leverage.

Larry:
Right, but activity is not the same as leverage. Leverage comes from making suppliers respond to the same requirement set in a way that exposes the real tradeoffs.

That matters a lot in colocation deals because the visible monthly rate is not the whole story. The long-term economics and the day-to-day operating experience are shaped by details that are easy to gloss over — how power is measured, what support really includes, how cross-connects are priced, what transport vendors are available at the site, how expansion works, and what remedies apply if something goes wrong.

If those things are not defined clearly, the provider’s standard model fills in the blanks. And usually that works better for the provider than for the customer.

Main Discussion / Analysis

Tony:
Let’s get into the specific requirement areas. Where do you usually want the most clarity first?

Larry:
I usually start with the deployment model itself.

A buyer may say, “We need colocation space,” but that can mean very different things. Are we talking about cabinets, cages, suites, or some phased combination? Is this a steady-state requirement, or is there likely growth? Does the enterprise expect to expand, consolidate, or otherwise evolve the footprint over time? Is there a strategic geography required?

That sounds basic, but it affects pricing, flexibility, and how the provider structures the deal. If the buyer is too generic, the provider has room to optimize around its own utilization objectives rather than the customer’s actual roadmap.

Tony:
And from there, power becomes one of the biggest issues.

Larry:
Without question. Power is one of the most important places to be precise because it often becomes the biggest long-term cost driver.

It is not enough to say, “We need this much power.” Buyers need clarity around committed power, density expectations, redundancy assumptions, how usage is measured, how overages are billed, and what happens if there is a dispute over measurement. Two proposals can look similar at a headline level and behave very differently over time because the power construct is different.

Tony:
That is a great example of how a requirement that sounds technical is really commercial too.

Larry:
Exactly. And the same is true for interconnection.

If the enterprise cares about carrier-neutrality, cloud on-ramps, exchange access, or partner connectivity, those needs have to be explicit. Otherwise, a facility can look strategically attractive because of ecosystem value, but the economics around cross-connects and related fees may not become visible until later.  Interconnection requirements are not just an operational detail. They are part of the business case.

Tony:
Another area that seems to create confusion is support.

Larry:
Yes, and remote hands is probably the clearest example. Buyers often assume everyone means the same thing, but they don’t.

What is included versus billable? What are the response expectations? What happens after hours? Are escorts included? What about simple tasks like reboots, visual checks, cable moves, receiving equipment, or incident support?

If those expectations are loose, providers can describe support in a way that sounds reasonable during the sourcing process but can become a liability once the environment is live.

Tony:
And that ties directly into the broader operating model too.

Larry:
It does. Access procedures, security requirements, visitor handling, vendor access, logging, maintenance notifications, and incident escalation all need to reflect how the enterprise actually expects to run the site.

A provider may have a perfectly reasonable standard operating model, but if it does not align with the customer’s real operating needs, that mismatch creates friction very quickly.

Tony:
Let’s talk about accountability. When you look at a colocation deal, which SLAs do you really want to press on?

Larry:
First, facility availability — understand how availability is defined, how it is measured, what exclusions apply, and whether the remedies are strong enough to matter.

Then I would go straight to power availability and environmental conditions like cooling. In colocation, this is fundamental. Power and cooling policies directly affect downtime risk, thermal shutdown risk, and stranded capacity.

Tony:
So that is where reliability and accountability really meet.

Larry:
Exactly. I would also focus on incident response and communication timing. If something goes wrong, how quickly is the provider acknowledging it, escalating it, and keeping the customer informed?

Then there is maintenance notice. Planned maintenance is normal, but the customer needs enough advance notice and enough detail to assess risk and prepare.

Tony:
And remote hands can matter a lot too.

Larry:
Absolutely. If the customer will rely on provider support, then remote-hands response time should be clear — what is covered, what counts as response, and what changes after hours or by request type.

And if connectivity is part of the business case, then cross-connect availability and provisioning should be on the list too. If cloud access, carrier access, or ecosystem value matter, those service levels should be addressed.

Key Questions & Actionable Takeaways

Tony:
So if you’re in IT procurement and are preparing for a colocation sourcing event, what would you want to pressure-test internally before going to market?

Larry:
I’d want to be sure that you’ve really defined the things that will matter after move-in, not just the things that matter on day one.  Things like:

• Have we been specific enough about the footprint and likely growth path?
• Have we defined power in a way that exposes the real economics?
• Have we made interconnection important enough in the requirement set if cloud, carrier access, or hybrid architecture matter?
• Have we defined our SLAs, support and operating expectations clearly enough to avoid surprises and drive accountability?
• Have we addressed flexibility early enough, instead of assuming we can negotiate it later?

If the answer is yes, the sourcing process is much more likely to produce a favorable outcome.

Tony:
That is a strong way to frame it. The real question is not just, “What facility do we want?” It is, “Have we defined the requirements that create leverage and support the business over time?”

Larry:
Exactly. That is where better outcomes start.

Tony:
That’s a great place to end. In colocation deals, (not unlike other technology and IT services) leverage is not created simply by going to market. It is created by defining requirements clearly to force comparability, expose hidden cost drivers, and force providers to respond to the your actual operating reality.

To our listeners, if you would like to discuss colocation strategy, sourcing, benchmarking, or how to define requirement sets that drive leverage in the market, or if you’d like to discuss other technology strategy, sourcing and cost reduction needs with Larry, 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.