CCaaS and UCaaS Sourcing: How to Compare Offers, Not Stories

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 Julie Gardner from TC2 and we’re talking about cloud communications sourcing—specifically CCaaS and UCaaS—and why enterprise customers need to compare offers, and not just supplier stories.

On paper, these projects sound pretty straightforward. Move from legacy voice, contact center, or collaboration platforms to a modern cloud model. Improve customer experience and support distributed employees. Make the environment easier to scale and manage.

Sounds good, right?

But here’s the thing: once the sourcing process starts, the proposals can get messy fast. 

Guest:
Very fast. And it’s usually not because the suppliers are being unclear on purpose. It’s because each supplier is telling the story through its own product platform, its own commercial model, and its own delivery assumptions.

Everyone says they can deliver the solution. Everyone has a roadmap. Everyone has a demo that looks polished.

But underneath that, the offers may be built on very different assumptions.

Tony:
Right. One supplier offer includes migration support while another treats migration as a separate professional services workstream. One solution may bundle managed services while another assumes the customer will handle more internally. One supplier includes certain features in its licensing model, while another prices them separately.

Guest:
Exactly. And that’s where sourcing discipline matters. The goal isn’t just to collect proposals. The goal is to force comparability.

Why Comparability Matters

Tony:
Let’s stay with that word: comparability. Because in cloud communications, I think that’s where a lot of sourcing events either succeed or start to unravel.

Guest:
They do. CCaaS and UCaaS decisions affect cost, user experience, customer experience, security, operations, and long-term flexibility. These aren’t simple software purchases. They’re operating model decisions.

Tony:
That’s the part that can get missed. A great demo doesn’t tell you who’s going to manage the platform after go-live. A low license price doesn’t tell you whether AI features, API usage, recording, analytics, integrations, or support are included.

And a migration estimate doesn’t tell you whether the supplier has really accounted for number porting, testing, training, legacy retirement, or global rollout complexity.

Guest:
Right. And if those details aren’t made explicit during sourcing, they usually show up later. As change orders, operational gaps and internal frustration.

Tony:
And by then, it’s harder to unwind.

Guest:
Much harder. Once a preferred supplier is selected, the customer still has leverage, but it’s different. The competitive tension has changed. So the cleaner the process is before selection, the better the outcome tends to be.

Where Offers Get Hard to Compare

Tony:
Let’s talk specifically about where these offers get hard to compare. Licensing feels like the obvious place to start.

Guest:
It is. But licensing is rarely just “price per user.” Customers need to understand user types, feature bundles, minimum commitments, ramp rights, consumption-based charges, overage rules, and how users can move between roles or business units.

Tony:
And different user populations matter. A contact center agent, a supervisor, an executive, a field employee, and a back-office employee probably don’t all need the same package.

Guest:
Exactly. If the sourcing process doesn’t define those populations clearly, suppliers will make their own assumptions. And those assumptions may make the proposal look better than it really is.

Tony:
For CCaaS, scope can expand quickly. You start with routing and agent functionality, and before long you’re talking about workforce management, quality management, analytics, recording, bots, AI agent assist, integrations, and customer journey data.

Guest:
And some of those capabilities may be very valuable. That’s not the issue.

The issue is whether the customer knows what’s required now, what’s optional, what’s included, and what creates incremental cost.

Tony:
UCaaS has its own version of this, especially around voice.

Guest:
Yes. Calling model, number management, emergency calling, international requirements, devices, rooms, legacy PBX retirement, and network readiness all matter. If voice is treated as an afterthought, the customer can end up with unexpected cost or implementation risk.

Tony:
So the RFx can’t just ask, “Can you provide CCaaS or UCaaS?”

Guest:
Ha, no. That question is perhaps too broad.

Tony:
And it invites slideware and a sales answer.

Guest:
Exactly. The RFx has to make suppliers show their work.

Tony:
So what does “show your work” look like in practice?

Guest:
It means structured response templates, pricing workbooks, assumption disclosures, and responsibility matrices. Suppliers should have to identify what’s included, what’s excluded, what’s optional, what depends on a third party, and what will be priced later.

Tony:
That responsibility matrix is a big one. Because in these deals, the customer isn’t just buying technology. They’re deciding who does the work.

Guest:
That’s right. Who handles administration? Who manages incidents and supports integrations? Who owns reporting? Who coordinates with carriers? Who handles platform changes? Who manages escalations?

The answers to all these questions matter.

Tony:
And “we’ll figure that out later” is not really an answer.

Guest:
No. It’s a warning sign.

Tony:
Migration scope is another place where two proposals can sound similar but mean very different things. Discovery. Design. Migration planning. Testing. Number porting. Training. Cutover support.

Those are not minor details.

Guest:
They’re not. Two suppliers can both say “implementation included” and mean completely different things. One may be offering a full migration workstream. Another may be offering basic platform configuration and expecting the customer to carry a lot of the load.

Tony:
And if the customer doesn’t catch that early, the more enticing proposal may not actually be the better deal.

Guest:
Exactly.

Tony:
Same story with managed services. Some enterprises want the supplier to run the platform day to day. Some want a lighter support model. Some want a hybrid model. But if the operating model isn’t defined in the process, the pricing comparison is incomplete.

Guest:
That’s the key. A sourcing event shouldn’t just answer, “Which platform do we like?” It should answer, “Which solution can we operate, at what cost, with what responsibilities, and under what commercial terms?”

Practical Questions for Enterprise Customers

Tony:
For listeners preparing for a CCaaS or UCaaS sourcing event, let’s make this practical. What should they answer before proposals come in?

Guest:
Start with the basics. Who are the user populations? What use cases are in scope? Which features are required at launch, and which are future-state?

Tony:
Then I’d add migration. What do we expect the supplier to include? What work stays with the customer? What work might sit with a third party?

Guest:
Yes. And for UCaaS, how will voice be handled? Calling plans, numbers, emergency calling, international requirements, devices, rooms, and legacy platforms all need to be clear.

Tony:
For CCaaS, customers should also ask how AI features are licensed, priced, and governed. There’s a lot of interest in those capabilities right now, but the commercial model can vary widely.

Guest:
And they should ask what costs are usage-based or subject to overage. API usage, storage, recording, analytics, bots, and support tiers can all affect the long-term cost profile.

Tony:
Think about it this way: the customer needs to know not only what the platform costs on day one, but what makes the cost move over time.

Guest:
Exactly. That’s where a lot of the risk sits.

Tony:
And then there’s the operating model. Who runs the platform after go-live? If the customer assumes the supplier owns that work, and the supplier assumes the customer owns it, everyone is going to have a bad day.

Guest:
And probably more than one.

What the Final Decision Needs to Prove

Tony:
As the process moves toward selection, what does the final decision need to prove?

Guest:
It needs to prove that the customer understands the full cost picture, the operating model, and the key risks. Not perfectly—there will always be some unknowns—but clearly enough to make a defensible decision.

Tony:
So not just, “Supplier A had the best demo,” or “Supplier B had the lowest license cost.”

Guest:
Right. The decision should reflect licenses, usage, migration, professional services, managed services, voice components, integrations, devices, support, service levels, future growth, and contract flexibility.

Tony:
And then the contract has to match that decision.

Guest:
Yes. Pricing, service scope, migration responsibilities, support obligations, service levels, governance, change control, and renewal terms all need to be captured clearly.

Tony:
That’s often the last mile where value gets lost. The sourcing process can be strong, the negotiation can be strong, and then the final agreement slowly pulls things back toward supplier-standard language.

Guest:
Exactly. And if that happens, the customer may not get the deal it thought it negotiated.

Tony:
So the goal isn’t just to pick a platform. It’s to land a deal the enterprise can actually run.

Guest:
That’s exactly right.

Closing Remarks

Tony:
The key takeaway is that cloud communications sourcing is not won by collecting impressive proposals. It’s won by structuring the process so suppliers have to respond on equal footing.

If the customer doesn’t force comparability, the decision can become a contest of narratives. If the customer does force comparability, the process creates clear economics, better stakeholder alignment, stronger contract terms, and a more executable operating model.

Guest, final thought?

Guest:
CCaaS and UCaaS can create real value, but only if the deal reflects how the enterprise will actually use and operate the platform. The sourcing process should expose cost, scope, responsibility, and risk before the supplier is selected. That’s how enterprise customers move from a good presentation to a good deal.

Tony:
That is a great place to leave it.

To our listeners, if you would like to discuss CCaaS, UCaaS, cloud communications sourcing, or how to structure a sourcing process that produces comparable offers, or if you’d like to discuss other technology strategy, sourcing and cost reduction needs with Julie, 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.