From Visibility to Real Savings: Turning FinOps Insights into Measurable Cost Reduction

In this joint session, Tangoe and Kubex come together to bridge that gap. Tangoe brings deep expertise in spend management and FinOps discipline, while Kubex delivers infrastructure-level optimization across cloud, Kubernetes, and the AI and GPU workloads that are rapidly becoming the next frontier of cost pressure.

 

What you’ll learn:

• Why visibility alone isn’t enough, and where the real gap between awareness and action lives
• Where most organizations get stuck between identifying waste and eliminating it
• How to connect FinOps discipline with infrastructure-level optimization to drive real reduction
• What a combined approach looks like in practice — across cloud, Kubernetes, and AI/GPU workloads
• Concrete takeaways you can bring back to your team, whether you come from FinOps, finance, or infrastructure

If you’re responsible for cloud cost outcomes, this session is built for you. Learn how leading teams are turning visibility into measurable cost reduction. 

 

 

[Video transcript]

 

Good morning, good afternoon, or good evening, depending on where you are joining us from today.

 

My name is Chuck Tatham, Chief Marketing Officer at Kubex. With me today is Paolo Sellari, Product Management Lead for Cloud at Tangoe.

 

Together, we’re going to cover today’s topic. We’ll include a demo and discuss the increasingly important topic of closing the gap between visibility, observability, governance, and actual infrastructure optimization for measurable cost savings.

 

This has been a hot topic for some time, and it’s evolving rapidly as AI adoption grows and Kubernetes becomes the preferred way to deploy modern infrastructure. While these trends introduce additional challenges, they also create tremendous opportunities to improve efficiency.

 

David Chase is also joining us from Kubex. He will cover the Kubex demo, while Paolo will demonstrate the Tangoe platform.

 

Without further ado, today’s agenda is straightforward. We’ve already covered introductions. We’ll discuss how we see FinOps evolving, including both new challenges and some that have existed for quite a while. We’ll explore how to close the gap between traditional FinOps disciplines and actual infrastructure optimization.

 

We’ll explain how Tangoe and Kubex address these challenges in a highly complementary way. We’ll introduce how Kubex works from an infrastructure optimization perspective, provide a short demonstration, and conclude with some thoughts on how to introduce these concepts within your organization. Finally, we’ll share options for learning more and taking the next steps.

 

That’s the agenda. I’ll hand things over to Paolo, who will talk a little about what Tangoe sees in the world of FinOps.

 

Paolo, over to you.

 

Thank you, Chuck, and hello, everybody. Thank you for joining us.

 

I’m not going to spend too much time here, but I do want to set the stage regarding the current state of FinOps.

 

You hear the term FinOps a lot, especially over the last five years. Tangoe has embraced it extensively and dove headfirst into helping customers solve FinOps challenges.

 

For better or worse, we’ve noticed that the scope of FinOps is expanding rapidly, with more and more areas falling under its umbrella. It started with infrastructure costs, and as you can see over the past few years, it has evolved to include SaaS, AI, UCaaS, CCaaS, and many other areas.

 

As a result, the responsibilities of a FinOps administrator continue to grow.

 

Unfortunately, each of these domains is a major discipline in its own right. Each requires deep expertise, governance, and organizational alignment. For example, SaaS management is often owned by a completely different group than infrastructure management. Different leadership teams are involved, while the FinOps team is expected to bring everything together. Tangoe’s role is often to help customers accomplish exactly that.

 

AI cost management has now become the dominant priority. Ninety-eight percent of organizations are actively managing AI spend, a dramatic increase from 2024. It’s one of the fastest-growing areas in FinOps today, and it touches nearly every other domain. It impacts SaaS, infrastructure, and broader business strategy. It’s becoming increasingly aligned with executive priorities.

 

Fortunately, over the past several years, FinOps has evolved from a small specialized team into an organization-wide discipline. The more companies embrace FinOps as a culture rather than a function, the greater success we see in managing cloud environments and cloud costs.

 

Executive alignment is particularly important. CIOs and CTOs have significant influence over both technology decisions and investment strategies. Being able to clearly demonstrate spending, unit economics, and cost-to-value ratios is critical.

 

Ultimately, what we want to see is broader adoption. At the same time, maturity levels remain uneven. Some organizations are highly advanced, while others are just beginning their FinOps journey. It’s the classic crawl, walk, run progression.

 

FinOps continues to evolve every day—not only in how it’s practiced, but also in the growing number of domains and technologies that must be managed under its umbrella.

 

Thanks, Paolo.

 

We always like to refer back to the FinOps Foundation membership surveys. For a number of years, workload optimization and waste reduction have consistently ranked among the top priorities. That’s where we’re going to focus the rest of this conversation because, although it’s a top priority, it’s also an area where many organizations continue to struggle.

 

The good news is that as organizations become more comfortable with automated infrastructure management, the potential for success increases significantly.

 

One interesting observation is that we’re not going to focus exclusively on AI in this discussion. If you’re involved in IT in any capacity, AI is everywhere. It’s not surprising that it has risen to the top of many FinOps priority lists. However, AI hasn’t displaced workload optimization and waste reduction. Instead, it has become part of the same overall challenge.

 

From our perspective, AI is simply another layer of infrastructure complexity that must be optimized alongside everything else.

 

Those survey results are always interesting.

 

From a functionality standpoint, we’re two vendors discussing our respective capabilities. You can think of Tangoe as being focused on FinOps visibility, governance, and insight into spending at scale. Kubex, on the other hand, focuses on infrastructure resources and workload optimization.

 

When these two disciplines work together effectively, organizations can optimize cloud infrastructure, Kubernetes environments, and AI workloads, resulting in better performance and lower costs.

 

That’s how the two solutions complement each other.

 

As we walk through the demonstrations, you’ll see Tangoe focused heavily on dollars, spend visibility, and governance. Kubex focuses on workloads, infrastructure, and resource efficiency.

 

Paolo, would you like to talk a bit more about that financial visibility side?

 

Absolutely.

 

Tangoe’s cloud journey originally started with visibility. In fact, I sometimes feel like we overused that word in the early days.

 

The reason is simple: we’re deeply focused on data. We excel at collecting data, cleansing it, organizing it, and ultimately presenting it in a way that provides what we consider true visibility and a true understanding of total cost of ownership.

 

When we think about what FinOps teams are trying to achieve, much of it centers around two foundational principles: cost transparency and cross-team accountability.

 

Cost transparency is relatively straightforward. You need to visualize costs and understand where money is being spent.

 

However, we’ve always tried to go beyond basic visibility by providing real-time visibility that aligns with organizational structures, business units, allocations, and chargeback models. Everything needs to align with the financial realities of the business.

 

Ultimately, that’s what enables cross-team accountability.

 

Until an organization can establish true accountability across teams, it’s difficult to make meaningful progress.

 

FinOps gives organizations a framework for having those conversations. It provides proven principles and best practices that have been adopted successfully by thousands of organizations. AWS, Azure, GCP, and other major vendors have all embraced these principles.

 

Once accountability is established, decision-making becomes much easier.

 

You can begin identifying optimization opportunities and, more importantly, taking action on them. Governance and compliance become shared responsibilities rather than isolated IT concerns.

 

No longer is optimization solely the responsibility of a FinOps team or an infrastructure engineer. It becomes something the entire organization participates in.

 

That alignment leads to better decision-making and greater maturity.

 

When teams understand their own costs and have ownership over them, organizations become much more successful.

 

However, there’s still one major challenge: execution.

 

This is where Tangoe and Kubex come together.

 

Organizations can visualize costs all day long. They can identify optimization opportunities. But the question remains: how do you actually execute on those opportunities?

 

Many FinOps initiatives struggle at this stage.

 

It’s not because people lack expertise. Usually, the issue is that ownership isn’t clearly defined, accountability isn’t fully established, and organizational workflows slow down decision-making.

 

FinOps teams often operate centrally, while the engineers responsible for generating cloud spend operate elsewhere. The challenge is eliminating that disconnect between ownership and outcomes.

 

When incentives become misaligned, organizations struggle.

 

For example, a team might say:

 

“We had to launch this project quickly to meet market demand.”

 

The project succeeds, but costs increase dramatically.

 

No one evaluated the long-term financial impact because speed was the priority.

 

As a result, executive leadership, product teams, engineering teams, and business stakeholders all need to align around how cloud resources are being used.

 

FinOps provides the framework to have those conversations.

 

Eventually, organizations reach a point where they say:

 

“Our costs have increased. We need to reduce them.”

 

Or:

 

“We’ve reduced costs, but now we need to maintain that efficiency over time.”

 

That’s where execution becomes critical.

 

Data quality must be maintained. Accountability structures must remain intact.

 

This is where Tangoe plays an important role.

 

We help organizations maintain visibility, accountability, and governance on an ongoing basis. As cloud environments become increasingly complex—with multi-cloud deployments, SaaS sprawl, and AI workloads—strong governance becomes even more important.

 

Recently, a customer reached out and said:

 

“You’ve done a great job helping us manage our cloud costs over the last few years. Now we have a new type of spend entering the business. Can we incorporate that as well?”

 

That’s exactly the type of conversation that leads to success.

 

When governance and visibility are already established, organizations can confidently expand their FinOps practices to new technologies and new cost categories.

 

Chuck, you mentioned earlier that you’ll show how Kubex helps automate optimization and execution. That’s where things get really interesting.

 

Exactly.

 

Let’s take a look at that visibility side of things.

 

I’ll try to keep this section concise because we have a lot of information to cover.

 

What Paulo described around allocation, chargeback, and visibility is incredibly important. Organizations need to understand not just what they’re spending, but where costs are being incurred and who is responsible for them.

 

That foundation is essential before you can begin optimizing infrastructure effectively.

 

Let’s jump in and take a look at the visibility side of things.

 

I’ll try to keep this section concise because we have a lot of information to cover. I narrowed it down to a few specific dashboards that I wanted to show.

 

When we talk about visibility, we’re really talking about allocation, chargeback, showback, and understanding the true cost of cloud operations. Customers come to us asking questions like:

 

“I want to see weighted distribution of my cost allocations.”

 

“I have Reserved Instances and Savings Plans. Can I see those allocated according to actual usage?”

 

Those sound like simple requests, but they’re actually quite complex to execute behind the scenes.

 

The reports themselves may appear straightforward, but the logic required to generate them accurately is where Tangoe provides value.

 

For us, FinOps begins with data.

 

We’re focused on collecting, cleansing, organizing, and normalizing cloud data so that customers can see the true cost of ownership across their environments.

 

Our goal is to provide an overall view of cloud spending, broken down by service categories aligned with the FinOps Foundation’s latest normalized data schema.

 

Customers can see costs by cost center, business unit, department, or organizational structure. We spend a significant amount of time understanding how customers organize their businesses—how HR structures map to cost centers, who owns different resources, what visibility different teams should have, and how cloud providers fit into the broader picture.

 

Once that structure is established, we can show customers exactly where costs originate, how they change over time, and how they are allocated throughout the organization.

 

Behind the scenes, we support a variety of allocation methodologies. Some customers require tax allocations. Others need profit-sharing models or internal markup structures where departments charge one another for services.

 

All of these scenarios can be modeled within the platform.

 

At the most granular level, Tangoe works directly with the underlying data to create a complete FinOps utility for customers.

 

Our dashboarding capabilities allow users to drill down from any level of detail. Dashboards can be customized and built dynamically.

 

For example, a customer may want to see only AWS spend. They may want to focus on a specific business unit, project, cost center, or region.

 

As filters are applied, the entire dashboard updates dynamically.

 

Once customers understand what they want to manage, they often ask another question:

 

“Can you just notify me when something changes?”

 

At that point, alerts become extremely valuable.

 

Customers don’t necessarily want to review reports every day. Instead, they want to know when spending deviates from expectations.

 

That’s where anomaly detection and automated alerts come into play.

 

Users can create alerts based on spending thresholds, percentage variances, budget overruns, or any number of custom conditions. As new cloud billing data arrives each day, those alerts are evaluated automatically.

 

From a usage allocation standpoint, this area might seem less exciting, but it’s incredibly important for finance teams.

 

When we talk about accountability, finance leaders often need to provide executive leadership with detailed explanations of where cloud costs are being incurred.

 

They need to answer questions such as:

 

• Which business units are consuming resources?
• Which environments are driving costs?
• How are costs allocated across projects?
• What are the largest areas of spend?

 

Our platform helps answer those questions.

 

We allow organizations to allocate costs by usage, cost center, department, business unit, project, environment, or any custom tagging structure they choose.

 

Customers can see their top areas of spend, understand how costs are distributed across sub-accounts, and analyze trends over time.

 

This enables meaningful accountability discussions throughout the organization.

 

Instead of debating cloud invoices at a high level, teams can have informed conversations about specific projects, workloads, and business initiatives.

 

The final area I’d like to highlight is data management.

 

The dashboards are powerful, and every element can be drilled into for deeper analysis. Users can examine hundreds of FinOps-controlled values, service categories, and resource subtypes.

 

But none of that happens automatically.

 

Behind the scenes, we provide extensive capabilities for ingesting and managing data.

 

Customers can load cloud invoices directly into the platform, allowing us to perform penny-for-penny reconciliation and allocation.

 

They can also import their own metadata, including:

 

• Projects
• Tags
• Cost centers
• Organizational hierarchies
• Business structures

 

We combine all of that information with the FinOps framework to create a unified financial model.

 

Customers can also build custom allocation rules based on their specific business requirements.

 

These rules determine how chargeback and showback calculations are performed and how costs are presented throughout the organization.

 

Organizations that are highly engaged with Tangoe tend to take full advantage of these capabilities.

 

We work closely with them to build dashboards, configure analytics, and customize reporting so that they can view and manage costs exactly the way they need to.

 

Ultimately, that’s what enables successful FinOps adoption.

 

The depth and configurability that Paolo just demonstrated are incredibly important.

 

Accuracy is equally important.

 

When you’re showing costs back to departments, teams, or business units, the data must be accurate. If people don’t trust the numbers, the entire process becomes difficult.

 

Trust is easy to lose and very difficult to regain.

 

Exactly.

 

Now let’s transition from visibility into the next challenge:

 

Once you understand where costs are coming from, how do you actually optimize the infrastructure that’s generating those costs?

 

That’s where the execution gap comes into play.

 

If we transition to the idea of impacting those large buckets of spend, this is where Kubex helps organizations address what creates much of the execution gap that Paolo discussed.

 

In almost every large enterprise, there is an execution gap. Optimizing the infrastructure that drives cloud bills often requires participation, approvals, risk assessments, and oversight from multiple groups. Many of those stakeholders are not measured on efficiency.

 

The primary responsibility of application owners is to ensure that applications run reliably, perform well, and remain available. That’s exactly how it should be. However, that reality creates a culture of caution around change.

 

Over time, organizations build layers of change control, approval processes, maintenance windows, and governance mechanisms. These are important, but they can also slow down optimization efforts.

 

As a result, organizations need a way to increase confidence in infrastructure optimization so that teams feel comfortable accepting and allowing change.

 

The second challenge is that technologies like Kubernetes and modern cloud-native infrastructure make traditional ticket-based processes increasingly impractical.

 

When you’re managing individual servers or virtual machines, manual intervention is possible. But once you’re managing containers and highly dynamic workloads that scale continuously, it’s simply not feasible to optimize infrastructure manually.

 

The environment changes too quickly.

 

The third challenge—and one we believe will become even more important—is AI.

 

Specifically, we’re talking about inference-based workloads rather than model training.

 

As organizations become increasingly agentic and deploy more inference workloads onto Kubernetes environments, utilization patterns and infrastructure variability will continue to increase dramatically.

 

That growth will create a new wave of cost concerns.

 

It’s inevitable.

 

As AI adoption accelerates, infrastructure consumption grows alongside it. At some point, organizations must optimize that infrastructure if they want to maintain efficiency.

 

In many ways, Kubernetes optimization serves as a training ground for what organizations will eventually need to do with AI and GPU resources.

 

So what does the problem actually look like when infrastructure is managed primarily by humans without automation?

 

Typically, environments end up looking something like this.

 

The amount of infrastructure requested and provisioned often differs dramatically from what workloads actually require.

 

In the chart we’re showing:

 

• The blue line represents actual utilization.
• The orange line represents requested resources.
• The gray line represents the amount of node capacity provisioned to support those requests.

 

The gaps between those lines represent opportunity.

 

Those gaps exist because people are cautious.

 

Developers and operators tend to allocate more resources than they need because they’re trying to avoid performance issues. The problem is that those decisions often remain untouched for months or years.

 

As a result, organizations accumulate significant amounts of unused capacity throughout their environments.

 

That excess capacity becomes a major source of waste and a significant opportunity for optimization.

 

So what does Kubex do?

 

Kubex continuously observes the detailed behavior of infrastructure components.

 

We apply machine learning to understand utilization patterns, workload behavior, and scaling characteristics.

 

We also allow organizations to define policies that determine how different types of applications should be treated.

 

For example, a customer-facing mission-critical application may require different optimization policies than an internal overnight batch process.

 

The platform combines all of these factors to determine what actions should be taken.

 

At the container level, Kubex identifies the precise resource requirements of workloads and determines how those workloads should be placed across nodes, GPUs, and other infrastructure resources.

 

Those recommendations are then passed through a highly controllable automation framework.

 

Organizations can choose to keep humans involved in the decision-making process, or they can enable fully autonomous optimization.

 

The ultimate objective is optimized infrastructure.

 

When recommendations are accurate, policy-aware, and highly precise, engineering teams begin to trust the system.

 

As trust increases, teams become more comfortable allowing automation to make changes.

 

The result is infrastructure that more closely aligns with actual requirements.

 

Requested resources converge toward true workload needs.

 

Node capacity is reduced accordingly.

 

And that’s where meaningful cost savings are achieved.

 

Dave is going to show you what that looks like in practice.

 

Thanks very much, Chuck.

 

What we’re going to do now is walk through a quick demonstration of the product and user interface.

 

We’ll look at some of the concepts Chuck discussed and see how they apply in a real-world environment.

 

What you’re looking at now is the primary landing screen for Kubex.

 

Here, you can see summary information about the environment.

 

One thing you’ll immediately notice is that Kubex supports multiple Kubernetes clusters, providing visibility across the entire Kubernetes estate.

 

You’ll also notice two prominent charts that Chuck referenced earlier.

 

These charts display resource utilization in several different ways.

 

First, we have separate charts for CPU and memory, which are the two primary compute resources organizations need to manage.

 

Within each chart, we’re displaying three key dimensions.

 

The blue line represents actual workload utilization. This reflects the resources your applications are actively consuming.

 

The orange line represents resource requests. These are the guaranteed resources allocated to workloads.

 

In most cases, you’ll want this line to sit above actual utilization because it provides a buffer that ensures application stability.

 

This is a fairly typical customer environment.

 

Finally, the gray line represents total node capacity—the infrastructure provided by your cloud service provider and the infrastructure you’re actually paying for.

 

Ideally, you want to minimize the gaps between these lines.

 

Some buffer is necessary, but large gaps represent waste.

 

In this example, you can see substantial gaps between utilization, requests, and node capacity.

 

The memory chart is particularly revealing.

 

There’s a significant amount of memory capacity available within the environment, but only a small fraction of it is actually being used.

 

That represents a major optimization opportunity.

 

In addition to identifying waste and excess capacity, it’s important to recognize that optimization is only one side of the equation.

 

You can also have workloads that aren’t receiving enough resources.

 

When that happens, risk is introduced into the environment.

 

What we’re looking at here is a view of the risks within the environment. I won’t go too deeply into the technical details, but the key takeaway is that insufficient resource allocation can cause significant problems.

 

For example, applications may be terminated unexpectedly due to memory constraints, or CPUs may become throttled because insufficient resources were allocated.

 

When those situations occur, application performance suffers.

 

As a result, it’s important to approach optimization from both directions:

 

• Reduce waste and excess capacity.
• Reduce operational risk caused by undersized workloads.

 

What Kubex does is continuously collect detailed information about workload behavior and resource consumption.

 

Using that data, the platform generates actionable recommendations that help fully optimize the environment.

 

You can see that represented here in the cluster breakdown view.

 

Expanding a cluster reveals detailed information about:

 

• Current spending
• Existing waste
• Optimization opportunities
• Potential savings

 

At any point, users can drill down further to see application-level recommendations.

 

This provides a detailed view of every workload running within the cluster and the specific actions required to optimize it.

 

For the sake of time, we won’t go through that level of detail today, but it’s important to understand that the platform can surface extremely granular recommendations.

 

One of the biggest advantages of the platform is automation.

 

While Kubex generates workload-level recommendations, it also has the ability to automate remediation.

 

Importantly, organizations maintain complete control over what gets automated.

 

For example, you may have a mission-critical application where you don’t want automatic changes being applied.

 

In those situations, you can exclude specific applications, namespaces, or entire environments from automation.

 

The controls are highly flexible.

 

However, automation is often where organizations realize the greatest value because it allows optimization to happen continuously and consistently.

 

To illustrate this, let’s compare an unoptimized environment with an optimized one.

 

What you’re seeing here is a fairly typical environment before optimization.

 

There are large gaps between:

 

• The resources you’re paying for
• The resources you’re reserving
• The resources you’re actually using

 

These gaps represent waste.

 

Now let’s focus on a specific Kubernetes cluster where automation has been enabled.

 

Looking at the historical data, you can see that around May 29th, the environment was operating in a typical, unoptimized state.

 

The gaps between utilization, requests, and node capacity were substantial.

 

Then, around May 30th, automation was enabled.

 

As automation began making adjustments, resource requests started decreasing.

 

At the same time, node capacity also began decreasing.

 

This happened because the platform was automatically right-sizing workloads and improving placement efficiency.

 

As workloads required fewer resources, fewer nodes were needed.

 

Node scale-downs occurred naturally, and the workloads were packed more efficiently onto the remaining infrastructure.

 

The important point is that application utilization remained unchanged.

 

Performance was maintained.

 

The difference was simply that waste was removed from the environment.

 

There’s another important benefit as well.

 

Before optimization, the environment contained both node-level and container-level risks.

 

After optimization, those risks disappeared.

 

This is one of the most powerful aspects of the platform.

 

Organizations often assume that reducing costs introduces risk.

 

In reality, when optimization is performed intelligently, you can achieve both outcomes simultaneously.

 

You can:

 

• Reduce waste.
• Reduce cost.
• Improve reliability.
• Eliminate performance risks.

 

As I often say, it allows you to have your cake and eat it too.

 

And just to add to that, one of the most effective ways to gain trust from engineering teams and application owners is by demonstrating that optimization doesn’t simply remove resources.

 

It also identifies workloads that aren’t running properly.

 

Many organizations discover hidden performance issues once they begin analyzing resource allocation in detail.

 

The same problem that causes waste—human estimation and static resource allocation—also causes under-provisioned workloads.

 

Most environments we encounter contain both significant excess capacity and workloads that aren’t performing as intended.

 

By continuously analyzing and optimizing the environment, you’re addressing both sides of that equation.

 

Thanks very much for the demo, Dave.

 

As we begin wrapping up, we’d like to share some practical thoughts about implementing these concepts within your organization.

 

One of the most important success factors we’ve observed is executive sponsorship.

 

Organizations need senior-level commitment to optimization initiatives.

 

There is almost always some resistance to change.

 

People are understandably cautious when it comes to modifying infrastructure.

 

However, once teams begin to see that applications continue to run properly—or even perform better—while costs decrease, confidence starts to build.

 

That positive feedback loop is critical.

 

Without executive support and organizational alignment, it’s very difficult to achieve lasting success.

 

Automation is another key enabler.

 

That doesn’t mean organizations need to adopt fully autonomous optimization immediately.

 

It doesn’t have to be all or nothing.

 

Many successful organizations start with a human-in-the-loop approach.

 

Recommendations are reviewed, approved, and then implemented.

 

Over time, as confidence increases, more automation can be introduced.

 

There are also innovative ways to integrate optimization into DevOps workflows.

 

Some advanced customers retrieve optimization recommendations through APIs and apply them automatically during deployment processes.

 

In those environments, infrastructure is corrected continuously as new releases are deployed.

 

Another important consideration is building confidence among engineering teams and application owners.

 

One of the most effective approaches is to start in development or test environments.

 

Organizations can:

 

• Observe the data.
• Review recommendations.
• Implement a subset of changes.
• Enable automation gradually.
• Watch the environment improve.

 

When teams see the results firsthand, adoption becomes much easier.

 

Finally, in larger organizations, there is often one department or team that is particularly motivated to reduce costs.

 

Maybe they’re facing budget pressure.

 

Maybe they’re responsible for a particularly expensive workload.

 

Whatever the reason, these groups often volunteer to go first.

 

Those early adopters frequently become examples of what success looks like for the rest of the organization.

 

If you can identify those opportunities, they often provide the fastest path toward broader adoption.

 

Thank you, Chuck.

 

To bring everything together, the partnership between Tangoe and Kubex exists because both organizations recognized that successful FinOps requires more than visibility alone. It requires execution.

 

Each of our platforms specializes in different parts of that journey, but together they help organizations close the gap between identifying optimization opportunities and actually realizing savings.

 

From the Tangoe perspective, there are several key takeaways.

 

The first is multi-cloud visibility and cost control.

 

This is where we focus our efforts. We provide a single pane of glass across cloud environments and, beyond traditional cloud providers, extend visibility into SaaS, UCaaS, and other technology spend categories.

 

Our goal is to provide granular cost allocation and management capabilities that allow organizations not only to visualize costs but also to process, allocate, and manage them according to their financial requirements.

 

For example, we can generate general ledger files or accounts payable files that are already aligned with an organization’s allocation and chargeback rules.

 

The second area is governance and policy enforcement.

 

By providing comprehensive visibility into cloud spend, budgets, and resource usage, we help organizations enforce governance standards and maintain compliance.

 

Whether it’s budget tracking, policy enforcement, tagging compliance, or auditability, Tangoe helps organizations ensure that accountability remains intact.

 

The third area is actionable FinOps insights.

 

Customers can configure alerts, anomaly detection, and variance monitoring based on virtually any KPI they choose.

 

As cloud billing data arrives, customers gain immediate insight into unexpected changes in spend and can respond quickly.

 

This allows organizations to make informed business decisions rather than reacting after costs have already escalated.

 

Finally, there is chargeback and showback enablement.

 

By aligning cloud costs with teams, departments, projects, locations, and cost centers, organizations create accountability throughout the business.

 

That accountability is one of the strongest drivers of successful FinOps adoption.

 

When we combine that visibility with Kubex, we move into optimization and execution.

 

You heard Chuck discuss Kubernetes and GPU optimization, and you saw David demonstrate how automation enables organizations to continuously optimize their environments.

 

One of the most common concerns we hear from customers is trust.

 

People naturally ask:

 

“How do I know the recommendations are accurate?”

 

“How can I be sure the system won’t negatively impact my environment?”

 

That’s where guardrails become essential.

 

Organizations need confidence that changes are happening safely and predictably.

 

The controls and governance built into Kubex help establish that trust.

 

As Chuck mentioned earlier, customers don’t want constant ticketing cycles, endless manual tuning, or configuration drift.

 

They want optimization that works continuously and reliably.

 

Most importantly, they want real outcomes.

 

Working together, Tangoe and Kubex help customers achieve measurable results.

 

We help organizations identify opportunities, understand where costs exist, determine what should be optimized, and then actually execute those optimizations.

 

To me, that’s the biggest takeaway from today’s discussion.

 

Everything we’ve talked about ultimately leads to one goal: turning visibility into action and action into measurable savings.

 

Workload-level attribution is another area where our partnership becomes increasingly important.

 

As organizations adopt AI and GPU-intensive workloads, understanding utilization at the workload and team level becomes critical.

 

Customers are increasingly asking questions such as:

 

“Which teams are consuming GPU resources?”

 

“Which workloads are driving AI costs?”

 

“How should those costs be allocated?”

 

These are areas where both Tangoe and Kubex continue to invest heavily.

 

Together, we’re working to provide not only the visibility customers need, but also the ability to act on that information and continuously optimize those environments.

 

Thank you.

 

Thanks, Paolo.

 

At this point, we’d like to leave up the QR code for anyone who would like to continue the conversation.

 

You don’t need to know whether your questions are more relevant to Tangoe or Kubex. Through that process, we’ll route you to the appropriate team based on your interests.

 

Please feel free to reach out.

 

Now let’s move on to a few questions.

 

Q&A

 

Question:
Do customers get the most value when they implement chargeback and cross-charging models?

 

That’s a great question.

 

The organizations that tend to be most successful are those that involve multiple stakeholders from the beginning.

 

When finance teams, FinOps teams, executive leadership, and technology teams all participate in the process, chargeback becomes much more effective.

 

When customers share their financial rules and organizational structures with us, we’re able to provide extremely detailed visibility into cloud spending.

 

Instead of simply showing a large cloud invoice, we can break costs down by team, project, business unit, location, cost center, or any other dimension that’s important to the organization.

 

The conversation shifts from:

 

“How much are we spending?”

 

to:

 

“Why are we spending it, and who owns it?”

 

That’s where accountability is created.

 

And when accountability exists, organizations are much more successful at managing costs.

 

The dashboards, reporting, and automation make those conversations easier because the information is presented in a way that everyone can understand.

 

You don’t need to be a cloud expert to understand that a specific project, team, or department is consuming a specific amount of budget.

 

Once everyone understands their own costs, accountability naturally follows.

 

And ultimately, that’s what leads to action.

 

Thanks, Paolo.

 

David, here’s a workload-related question.

 

How long does Kubex need to observe a workload before it can begin optimizing it?

 

Great question.

 

The answer depends on whether we’re increasing resources or decreasing resources.

 

If we identify a workload that doesn’t have enough CPU or memory, we can begin making recommendations very quickly.

 

Typically, we can identify and recommend changes within about an hour of collecting data.

 

However, when we’re removing resources, we take a much more cautious approach.

 

We never want to trade savings for risk.

 

In those situations, we typically observe workloads for approximately one week before making downsizing recommendations.

 

That observation period gives us enough history to understand workload behavior and ensure that we’re not removing resources that may be needed later.

 

The exact timing is configurable, but one week is generally our standard recommendation.

 

Thanks, Dave.

 

And with that, I’d like to thank everyone for joining us today.

 

Paolo, thank you for your excellent insights.

 

David, thank you for the demonstration.

 

And thanks to everyone who attended.

 

If you’d like to continue the conversation or take a deeper dive into any of the topics we discussed today, please don’t hesitate to reach out.

 

Have a great day, everyone.

 

Take care.

 

Thank you.