A look at the bill before anyone promises a number.
A cost assessment attributes cloud and model spend to the environments, teams and workloads that cause it, then names the reductions somebody would actually be willing to make. It does not open with a saving, because that figure does not exist until the estate has been looked at.
The self-serve intake for this assessment is still being built. Today an assessment starts as a conversation.
What has to be in place for this to be worth doing.
Most of the delay in a cost assessment is not analysis. It is waiting for access, for an account list, and for somebody on your side who is allowed to answer a question about a workload.
Read access, scoped to cost and usage. Nothing about this work requires the ability to change a resource.
AskWho grants that in your organization?
The gaps in this list are themselves a finding, and we would rather see the real one than a tidied version.
AskIs there a single list?
We are not grading it. We need to know what the data will support before we promise an attribution.
AskDoes it match what is deployed?
This is often held by finance rather than by the platform team, which is itself worth knowing early.
AskWho holds that list?
Without that, the assessment becomes a document rather than a conversation, and documents do not resize anything.
AskWho would that be?
Agreed in writing before work starts rather than discovered in the third week.
AskIs model spend in scope?
Five stages, and what each one needs from you.
The stages are sequential because each one depends on the last. The table states what you have to supply, because the common failure mode is an assessment that stalls waiting for an answer nobody was told to prepare.
| Stage | What happens | What it needs from you |
|---|---|---|
| Access and inventory | Read access established, accounts enumerated, scope confirmed in writing, and the gap between the account list you have and the accounts that are billing you made visible. | Whoever can grant read access, and the account list as it actually stands rather than as it is documented. |
| Attribution | Spend mapped to environments, teams and workloads against the tagging model that exists. Unattributable spend reported as its own line rather than distributed by a rule that would make the report tidy and the conclusion wrong. | The tagging model, the team structure it is meant to map to, and a decision on how shared cost should be apportioned. |
| Drivers | Each layer of the bill examined against what drives it: compute sizing and schedules, storage tiers and retention, data transfer, managed data services, cluster utilisation, and model routing where it is visible. | Access to utilisation data, and someone who can explain why a workload is shaped the way it is when the metrics do not say. |
| The argument | Candidates put to the teams that own the workloads. Some are accepted, some are refused for reasons that turn out to be good, and both outcomes are recorded with the reason attached. | Time from the workload owners. This is the stage that decides whether the assessment produces a list or a document. |
| The list | Candidates ordered by how likely the owning team is to accept them, each with a named owner, and the refusals kept on the list with their reasons for the next cycle. | A decision on what happens next, which may be nothing. |
Cloud spend and model spend, on the same terms.
Inference is part of the bill now. Reporting it apart from cloud makes the total easier to defend and harder to act on.
Nothing is re-sized, re-committed or turned off during the assessment. It reads, attributes and recommends. Changes are made by the people who normally make them.
Unattributable spend is reported as its own line. A rule that spreads it would make the report tidier and the conclusion wrong.
We need to know what the data will support before promising an attribution. Whatever exists, including the abandoned parts, is the input rather than the subject.
It produces a list with owners. Each candidate names the team that would have to agree to it, because that is what decides whether it ever happens.
All three are acceptable, including the two where you do not hire us.
An assessment designed so that only one ending is acceptable is not an assessment. This one produces a list you own, and what happens to it is a separate decision taken afterwards with the list already in your hands.
What we run, what you run.
Written down before anything is deployed, so the boundary is a document rather than a discovery.
| Who | What they hold |
|---|---|
| Reign Ops, automated | Establish read access, enumerate the accounts, attribute the spend, examine the drivers, put candidates to the workload owners and produce the ordered list. |
| Customer authored | Read access, the account inventory, the tagging model, the commitment inventory, a named owner who can convene people, and agreement on scope in writing. |
| Operating partner engagement | The whole assessment. It is an operating partner engagement by construction, because the stage that decides whether it produces a list or a document is the one where a person sits with your workload owners. |
The questions that arrive every time.
How long does it take?
How much will we save?
Do we have to hire you afterwards?
Which deployment shapes can we have?
What does it cost?
Start with the bill, not with a number.
Which providers, roughly how many accounts, and whether anyone can attribute the spend today. If the answer to the last one is no, that is the finding and the assessment is where it gets fixed.