A while back, I was sitting in my home office, laptop open, trying to sequence my day before the mad dash for the school run. I had a customer exec call coming up. Neat agenda, tightly timeboxed, lots of polite nodding.
Five minutes in, the CFO cut through the slide deck and turned to his team.
“What does it actually cost us to serve the payment gateway to our customers?”
There was a pause, not an awkward one. A dangerous one.
The team had dashboards. They had 90+ tagging coverage. They could tell exactly how many resources were tagged in each account, and there were a lot of resources. But they couldn’t answer his question.
And I’ve seen this pattern play out too many times to pretend it’s rare. A one off. In fact, Gartner found that only 43% of organisations track cloud costs at the unit level (Gartner, 2025). Less than half. Yet, tagging coverage remains one of the most tracked FinOps metrics in the industry, with even the FinOps Foundation calling out 90%+ overall compliance as a measure of success.
Something doesn’t add up here. Organisations are measuring the mechanism and missing the outcome. They have great compliance. They don’t have decision quality.
The issue isn’t your tags. It’s that you tagged first, then tried to invent the questions
Tags are the mechanism. Allocation is the strategy
The FinOps Foundation’s framework get’s the sequencing spot on. It talks about three distinct strategies under the Allocation capability: an allocation strategy, a tagging strategy and a shared cost strategy. The allocation comes first. It defines how an organisation wants to see its cots, which dimensions matter, and which decisions those dimensions need to support.
Yet the practitioner conversation and specially those from the cloud service providers, flattens all three into just one slogan: “get your tagging sorted”.
Why does this keep happening? My take on it is because tag coverage is easy to measure. It fits neatly on a dashboard, gives leadership a vanity KPI that trends up and in the right direction.
Allocation models are messier. It forces answers to questions that sit between finance, product and engineering: which cost dimensions drive investment decisions? Which costs are shared, and what’s the rule for splitting them? What does “cost per customer” even mean to us as an organisation? Should we be measuring something else?
Those are not dashboard questions. They are strategy questions, requiring cross functional thinking. Technology driven policies like an SCP or Organisational Tag Policies that block untagged deployments can’t answer them. They can’t even surface them. And no dashboard will generate them for you.
So teams fall back to the tractable problem, the one they can see and measure. Easily. They tag everything, report on coverage and assume insights will follow. They don’t.
Allocation first: What it looks like in practice
Before you tag a single resource, I want you to answer one (not so simple) question: what business decisions will this cost data support? And no, optimising cost or its variants is not one of the right answers.
Even if I take the example of a growth stage SaaS company spending $50k - $150k a month on public cloud costs, the answer will usually be some variation of margin by product line, spend by team for accountability, cost to serve by customer segment. These aren’t tagging requirements. They are allocation questions.
Now, this is the part people skip.
In a multi tenant SaaS setup, tags alone will never get you cost to serve data. Not when customers share infrastructure. You cannot tag a database cluster as “Customer A” when it’s serving hundreds of tenants. Tags can push costs to the right product and component buckets. However, the jump from component cost to customer level costs needs an attribution layer that blends tagged cost data with usage signals from your application layer, i.e. API calls per tenant, storage consumed, transactions processed.
Tags feed the model. Tags are NOT the model.
I find most teams skip a crucial step. Before tagging a single resource, you need to map your business questions to the cost dimensions, data sources and attribution rules required to answer them. A one page matrix is a good starting point and something you can evolve over time. Set up three to five questions down the left side, the dimensions and rules across the top. Without it, teams tag in the dark. They capture data they cannot connect to business decisions.
The constraints are generally the same: shared infrastructure with multiple tenants, product, or teams consuming the same resources. All this results in is twelve months of tagging effort that produces dashboards that look pretty, but with minimal business value since the tags were never designed to feed an allocation model.
This is where the cloud providers’ own guidance seems to lead teams astray. AWS, Azure and GCP each publish tagging best practices that describe in great detail a tagging schema (environment, cost centre, application, owner, and so on) without forcing a discussion on what the organisation actually needs to know. That advice certainly gets you started, and to be fair to them, it’s not possible to have “general guidance” that is specific to a business’s needs.
The trap however, is the implied promise: good tagging coverage equals unit economics.
It doesn’t. Patterns designed for organisations with dedicated FinOps teams with a multi million dollar annual cloud spend don’t fit a 40 person engineering team running three products on AWS. And they still don’t answer that organisation specific customer level questions, without the attribution layer sitting above it.
When I run tagging strategy workshops, I am strict on sequencing, and this is the order of operations you should enforce. First, ask yourself what questions do I want this data to answer. Then build your allocation model that answers those questions. Define the dimensions before you touch a tag policy. Second, your tags need to express the first layer of that allocation model. Third you build the attribution rules for shared infrastructure.
In that order. No exceptions
Minimum viable tagging (and why five tags beat 12)
Let’s look at an example, if your allocation dimensions are product margin, team accountability and component level cost drivers, you don’t need twelve mandatory tags. Five will do.
For a SaaS setup from my previous example, product, component, environment, team, cost-centre. That’s it.
Don’t miss out on including component. It’s the tag that turns “Product X costs us $18k a month” into something you can drill down into. With component tagging, you can trace whether auth is cheap and payments are expensive to run for your platform. You can attribute costs to architectural choices. Ranking components by cost, specially as your customer base grows allows you to have grown up conversations with product owners about where to invest, where to optimise and where to eliminate.
These won’t give you cost per customer or any of the higher order analytics. That requires an allocation model that connects your cloud costs to how each customer actually uses the product. But they do give you the foundation that the model needs: costs in the right production buckets, broken down by component and environment or team. You can’t build the second layer without it.
Remember that Gartner figure from earlier? 43%? That’s the number of organisations that can track costs at the unit level. The consensus on the fix is consistent: fix tagging fatigue. If most organisations can’t get the basics right, adding more tags won’t fix it. Fewer tags, chosen with intent, will. And I’m going to say the quiet part out loud:
If your tags don’t support business outcomes, your “tagging program” is admin.
Start with the smallest tag set that enables the first layer of your allocation model. Prove the value. Let the business see, for the first time, what each product and component actually costs to run. That visibility shifts the conversation from “how do we reduce costs” to “which components should we invest in, which need architectural attention, and which should we eliminate.” That’s the shift from cost management to capital allocation. From chasing smaller numbers to improving decision quality. You don’t get there by chasing tag compliance.
The three-question test
Here’s how I test if a team has allocation, or just tidy tagging. Three questions, with escalating difficulty.
1. Can you tell me what it costs to serve your top 10 customers or customer segments? Not roughly. Not “we think it’s about this much”. Exactly, and broken down by the infrastructure each one consumes. This needs tags and an attribution layer that distributes shared costs using consumption data. If you have component level costs but no way to attribute those back to customers, you are stuck at the halfway point
2. Which of your product lines has the best cloud margin? And which has the worst? Your minimum viable tags should answer this one. If you can’t rank by infrastructure profitability, pricing decisions are guesswork. (More on this to follow in the next article)
3. If you lost your largest customer tomorrow, how much cloud spend could you eliminate within 30 days? This the “let’s act on the data” question. Can you trace spend to a customer , quantify the exposure, and make a capital reallocation decision inside a week? Or will you be guessing? Or worse still, keep running as is?
If you are drawing blanks, more tag coverage is not the silver bullet. The first question needs an attribution model, that most organisations don’t have. That’s a visibility gap. The second needs tags chosen with intent. That’s a governance gap. The third needs both. That’s a capability gap.
What changes when you get the sequencing right
Late last year I worked with a SaaS platform running on AWS. Monthly spend was climbing. They had strong tagging discipline, with over 85% coverage. For all intents, their FinOps reporting seemed healthy. They failed all three questions
They couldn’t tell me the cost to serve by customer segment, nor rank by cloud margin. When I asked them what would happen to their bill if their largest enterprise customer churned? The room went deathly quiet.
The tags were there. The allocation model wasn’t. But tags can only label resources. They cannot split a shared Kubernetes cluster across customers or customer segments. They can’t attribute platform costs to the enterprise deals consuming them. The team had the mechanism, but were missing the layer that turns tags to cost to serve.
We started with a matrix: five business questions the CFO needed answered, mapped to the cost dimensions and the attribution rules required to answer them. Agreeing on the attribution rules was the hardest, consensus is never easy. That exercise took us over a week with multiple workshops. It surfaced that 40% of their spend sat in shared platform services.
They replaced their twelve tag schema with five. That’s just the starting point. Then they built a simple attribution layer for shared costs, splitting by API call volume per product per customer segment.
In six weeks, they could see cost to serve across their customer base for the first time. Custom pricing quotes for enterprise deals had been based on gut feel, competitive pressure and “this is what we did for the other customer”. Now they tightened their pricing model on custom quotes. Margins improved without cutting a single dollar.
That’s not a cost saving insight. That’s business insight. The tags didn’t change the business. The allocation model did. Tags just made it possible.
Get the questions right first
I am not anti tag. Anything but! I am, however, anti false confidence.
Tags matter. They’re the mechanism that makes the first layer of allocation work, and the CUR deep-dive I published earlier shows exactly how tag-based billing analysis operates at the technical level.
But in shared infrastructure environments, even perfect tagging leaves you short of the unit economics answers your business needs. Getting from component-level costs to customer-level costs requires an allocation model that most organisations haven’t designed because they’ve been too busy chasing tag compliance.
I wrote in FinOps Isn’t a Cost-Cutting Project that the organisations getting the best outcomes from cloud economics treat spend as a capital allocation problem. That thinking has to extend to how you structure visibility into that spend.
So start here. Design your allocation model around the investment decisions your business needs to make. Tag to implement the first layer. Then build the attribution that connects costs to customers.
Stop chasing tag coverage as a trophy KPI. Start asking a sharper question:
Can our tags feed an allocation model that improves the quality of a capital allocation decisions?