Put your own numbers in. See what the Cantilever catalog gives back.
A parametric model, not a benchmark. Enter the provisioning, change, incident and audit volumes you already run, adjust every assumption behind them, and watch capacity, cost and cycle time recalculate as you type.
* Realisation accounts for ramp, imperfect capture, and capacity reinvested in delivery rather than removed from budget. Methodology is set out under the questions evaluators actually ask.
Your volumes. Your assumptions. Your number.
Pull one quarter of ticket, change and incident data and multiply by four. Rough is fine — this is about order of magnitude, not decimal places.
What your organisation does in a year. These are the only figures that have to come from you.
The hours leaving your process, set to platform reference values. Override any of them with a number your own team will defend in a room. Changed fields are outlined in brass.
Two discounts, kept separate on purpose. Adoption is how much work actually flows through the catalog. Realisation is how much freed capacity a finance team will recognise as value.
The same model, as Cantilever would report it.
Every governed run on the platform emits an evidence trace. So does this model — the difference being that this one is an estimate, and says so on its last line.
Three costs that never appear on an invoice.
Nothing in this model comes from new capability. It comes from removing work that exists only because the toolchain does not answer to a single policy.
Work that waits
A standard environment takes three to ten business days, most of it queueing behind a platform engineer who has to translate a ticket into engineering work. Catalog self-service removes the translation step, not the engineering.
Work that repeats
The same Day-2 change, the same triage path, the same new service pattern built from scratch by a different team. Reuse compounds: the marginal cost of the next automation falls every time one is published.
Work that reconstructs
Audit evidence assembled after the fact from logs, threads and retroactively completed change tickets. When lineage is a by-product of execution, weeks of senior engineering time stop being spent on archaeology.
The same number reads differently depending on what you own.
Capacity persuades engineering leadership. Lead time and provable control persuade everyone else in the approval chain.
Self-service your team can actually approve
The audit line in the model is the smallest number on the page and the easiest one to defend. Roughly 400 hours a year stop being spent reconstructing evidence, because lineage is produced as a by-product of execution rather than assembled afterwards.
- Identity federated through your existing provider on every run
- Just-in-time credentials — no standing access left in pipelines
- Your standards enforced as a gate, before anything changes
- Permanent lineage mapped to SOC 2, FedRAMP and ISO 27001 evidence
The bottleneck stops being a person
Provisioning and new-pattern build together account for roughly half the modelled hours. Both are the same cost in different clothing: work only the platform team can do. The Cantilever Service Catalog moves it, safely, to the teams who wanted it done.
- Versioned catalog entries with mandatory inputs
- The Cantilever Stack Framework for multi-step reference architectures
- Existing Ansible, Terraform and CI/CD onboarded without rewriting
- Tenant-isolated catalog scopes for multi-business-unit delivery
Triage stops starting from zero
The incident line is the one most sensitive to your own data, so it is worth replacing the default first. The saving is not fewer incidents — it is less time spent assembling context the platform already holds.
- Standardised runbook execution with full traceability
- SLO-aware change gates wired to your deploy monitors
- Event-driven remediation triggered from Datadog, Splunk and Elastic
- AI-assisted root cause correlating logs, telemetry and execution history
Nothing in this model requires re-platforming
The estimate assumes your current engines keep executing the work. It is an overlay case, which is why it can be argued on operating cost rather than on a migration programme nobody has budget for.
- One governed control plane across a fragmented toolchain
- Existing licences, contracts and skills preserved
- Landing zones and platform patterns shipped as versioned Stacks
- Speed and governance stop being a trade-off you have to price
Cost data you can actually allocate
Tag remediation is the smallest line here and the most misleading. Its real value is not the sweep hours removed — it is that every downstream cost report becomes trustworthy, which is a benefit this model does not attempt to price.
- Required metadata enforced at provisioning, not reconciled later
- Estimated spend evaluated before approval
- Budget policy gates that stop overruns at the gate
- Tag-driven allocation that makes chargeback possible
The argument that usually lands harder than hours.
These targets follow from the same design as the capacity model, and they are the ones worth writing into a pilot. They are also the ones a business stakeholder feels without being shown a spreadsheet.
| Standard environment lead time | 3–10 days → under 1 day |
| New capability time-to-catalog | 3–6 weeks → 3–5 days |
| Access grant | 1–3 days → minutes |
| “What do we run, and who owns it?” | 2–5 days → minutes |
| Audit evidence package | 2–4 weeks → 1–2 days |
| Mean time to restore | 4–8 hrs → 2–4 hrs |
The things evaluators actually ask about the model.
Are these numbers measured or estimated?
Why are adoption and realisation two separate discounts?
Does this double-count anything?
Why is risk-avoidance value excluded?
Which default should I replace first?
What should we govern the programme with?
Send me this model
We will email the numbers exactly as you have set them, alongside the assumptions sheet your finance team will ask for. No drip sequence — one email, from a person.
Bring your volumes. We will pressure-test the model with you.
One quarter of provisioning, change and incident data is enough. In thirty minutes we will populate this with your numbers, agree the adoption metric that will govern the programme, and scope a pilot that settles it either way.
30 minutes · tailored to your stack · no slideware