# How to calculate the ROI of an enterprise multi-cloud transformation

Time the hours and the rework in the process you mean to change. A list of clouds is a footprint, not a return.

**Published:** 2025-11-25
**Canonical:** https://synconai.com/roi-multi-cloud-transformation
**Author:** SynconAI Architecture Team

## In short

Calculate the return by timing the process you intend to change, in hours and in rework, before the programme starts. Licences, add-ons, and implementation time are costs you can name. A count of clouds is a footprint. Publish the baseline, recount it after go-live, and leave out any percentage you did not derive from those hours.

## Sources

- **About Salesforce Data 360** (retrieved 2025-10-14)
  https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5
  > Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs.
- **Agentforce: How much does Agentforce cost?** (retrieved 2026-10-10)
  https://www.salesforce.com/agentforce/
  > Our pricing options include Flex Credits, Resolutions, or per-user licensing, designed to fit how and where you deploy AI.

## What to take away

- Baseline the process in hours and rework, with a date and the person who counted.
- A cloud count is a footprint. The return is a shorter process or less rework.
- Name licence, add-on, and implementation costs. Do not borrow a percentage.
- Recount the same way after go-live. If the hours got worse, publish that.

## The guide

The steering pack lists five clouds and a percentage taken from a conference slide. Nobody has timed the quote. After go-live the quote still takes a first pass and a second pass, because the price is typed again from the price list into the opportunity. The cloud count has gone up. The hours have not moved. Finance asks for the percentage again, and the programme answers with the footprint. That answer is not a return. It is a list of what you pay for.

A return is a change against a baseline you wrote down before the programme. The baseline is the process you mean to change, counted in hours and in rework. How long to produce a quote. How long to raise an invoice. How long to close a case. How many hours go into the spreadsheet that corrects the CRM. The second call that exists because the first record was incomplete. The report someone rebuilds because they do not trust the first one. Write the date and the name of the person who counted. Without that page, a business case is a cloud list with a percentage taped to it, and the percentage will outlive every person who knows it was borrowed.

## Time one process, then stop talking about clouds

Do this for one process, not for the whole estate in a single number. Pick the process the programme claims it will change. If the claim is "faster quotes," the process is quoting. If the claim is "cases closed without a second call," the process is the case. If nobody can point at a process, the claim is not ready to be costed. "One view of the customer" is a hope until someone can show the old view, how long it took to assemble, and how often it was wrong. Multi-cloud programmes fail this test when the benefit is a diagram and the cost is real.

Sit with the people who do the work. Time ten real instances, not a workshop estimate. A workshop estimate remembers the good day and forgets the chase. Note the rework separately from the first pass. A quote that takes a first sitting, then another sitting because the price was wrong, is two sittings. Count both. Write what the second sitting was for: a missing discount approval, a product that was not on the price list, a customer name that did not match the billing account. Those reasons are the design. A total with no reasons is a number you cannot improve.

Write the date, the person who held the watch, and the ten identifiers, so someone else can open the same records. A baseline that cannot be reopened cannot be recounted. Store it where the steering papers live, not in a notebook that leaves with the project manager. If the ten instances are not representative, say how you chose them. Ten quotes from one friendly seller is a different baseline from ten quotes across the teams that actually struggle. Either can be honest. Pretending they are the same is how the recount later looks like a failure of the programme when it is a failure of the sample.

If you cannot name the process, stop the return slide. Do not substitute a count of objects, users, or clouds. Those describe the estate. They do not describe a change. The meeting that cannot name the process is the meeting that should not approve the spend, and saying so early is cheaper than discovering it in the recount.

## Costs you can name, and cells you leave blank

Salesforce describes Agentforce pricing in one sentence: "Our pricing options include Flex Credits, Resolutions, or per-user licensing, designed to fit how and where you deploy AI." That is a cost shape for one product. It is not a saving, and it is not a return. Put the option you will actually buy on the cost page, in the unit the contract uses. If you have not chosen, say so, and leave the cell blank. Do not convert an unchosen price into a benefit by assuming the cheapest option and the busiest month. The steering group will remember the benefit and forget that you had not bought it.

[Data 360 help](https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5) is equally plain: "Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs." Add-on licences are a cost. Usage that can be adjusted is a commercial conversation, not a free input. If you do not know the edition and the add-ons, you do not know the cost. Leave the cell blank. A round number invented to fill a blank will be the number the steering group remembers, and it will be repeated in the next pack as if it had been measured. Limits differ by edition and by what you bought. This page will not print a cap. Look up the figure for the contract you hold, on the date you write the page, and put that date next to the figure.

Implementation time belongs on the same page. Internal hours. Partner hours. The hours the business spends in workshops instead of in the process you just timed. Those hours are part of the cost of the change. A case that is shorter by two hours, and a workshop programme that consumed the team's quarter, is not a return until you have put both on the page. Training time counts when it replaces selling or dispatching. It does not count as a benefit because attendance was high.

:::warn
Do not borrow a percentage from another programme, a vendor slide, or a previous business case. This guide does not supply one. A percentage you did not derive from your own hours and your own costs is not a return. It is a decoration, and finance will be asked to believe it.
:::

## A footprint is not a return

Owning sales, service, a data platform, and a field product is a description of what you pay for. It becomes a return only when the timed process gets shorter or the timed rework stops. Adding a cloud because the diagram looked empty increases the footprint. It may also increase the cost page: another licence, another add-on, another set of workshops. None of that is a benefit until the ten instances, timed again, come back shorter or cleaner.

Recount the process after go-live, the same way, with a named person, on a date you set before you started. Same process. Same kind of instance. Rework separated from the first pass. If the hours got worse, that is the result. Publish it beside the baseline. A programme that only reports the cloud count has not calculated anything, and a programme that recounts only the instances that improved has calculated a wish. Put the worse ones on the page. They are how you decide whether to continue, change the design, or stop.

The expected change, before go-live, is written as fewer hours or less rework, not as a ratio. "The second sitting on the quote stops, because the price is taken from the price list instead of typed again." That sentence can be checked. "Efficiency improves" cannot. The person who will recount it is named now, so the job is not orphaned when the project team rolls off. If that person was also the person who counted the baseline, the method is more likely to match. If they are different people, have them time one instance together before the baseline is filed.

| Line on the page | What you write | Leave it blank when |
| --- | --- | --- |
| Process | The work the programme claims to change | The claim is a diagram |
| Baseline | Hours and rework, ten real instances, a date, a name | The number came from a workshop |
| Licences and add-ons | The option you will buy, looked up | You have not chosen, or you do not know the edition |
| Implementation | Internal hours, partner hours, business hours in workshops | You only counted partner days |
| Expected change | Fewer hours, or a kind of rework that stops | You only have a percentage |
| Recount | The same method, after go-live, including worse results | The pack only shows the cloud list |

## What is cheap to correct, and what sticks

Cheap, before anyone has presented the percentage: throwing the borrowed figure away, naming the process, timing ten instances, listing the licences you can actually point at. The steering group may be impatient. The impatience is cheaper than a year of reporting a number nobody can recompute.

Expensive, once the percentage is in a board paper: every later conversation starts from it. People will explain variances against a figure that was never yours. Correcting it looks like the programme is slipping, when the programme is meeting a baseline you had not written. Write the baseline before the first pack. If a pack has already gone out with a borrowed figure, the next pack says so in a sentence and replaces it with the hours. Do not leave both numbers in circulation. The borrowed one will be the one that gets repeated, because it is round.

Three ways teams avoid the watch. They average the whole company into one "productivity" number, so no process can be found inside it. They time a demonstration in a conference room and call it the baseline. They treat a licence discount as a return on the transformation, which is a purchasing result, not a change in the work. A discount can sit on the cost page. It does not shorten the quote. The quote shortens when the second sitting stops, and you will know that only if you counted the sittings.

Two processes do not become one number. If the programme claims both a shorter quote and a shorter case, time them separately, with two baselines and two recounts. Averaging them lets a gain in one hide a loss in the other, and the pack will report the average as success. A survey that asks people whether they feel faster is not a substitute for the watch. Feeling faster while the second sitting is still in the field history means the field history is the baseline you should have used.

The recount meeting has an agenda that fits on the same page. Read the ten new instances against the ten old ones. Name which reasons for rework disappeared, and which new reasons appeared, because a new system often replaces one kind of rework with another. A price that is no longer retyped, and a credit check that now waits on an integration, is not automatically fewer hours. Count the wait. If you cannot explain a movement in hours by a movement in those reasons, you do not understand the result yet, and you should not translate it into a ratio.

Present one page. The process. The baseline in hours. The costs you can name. The change you expect, stated as fewer hours or less rework, with the person who will recount it. No percentage you did not calculate from those hours. If finance wants a ratio, they can divide your recounted hours by your named costs. Hand them the inputs. Do not hand them a figure from a slide you did not measure.

The same hours-and-rework test is how a later quarter should be scored, which is the discipline in [a roadmap that records whether the pain moved](/continuous-improvement-roadmap-salesforce). A roadmap that cannot point at this baseline will fill up with clouds. This page is the baseline it should be pointing at.

:::note
If the recount is worse, publish it next to the baseline. The hours got worse, and that is a result. Adjust from that page. The original cloud list cannot tell you what to change.
:::

## Questions

### Where does the calculation start?

With one process the programme claims it will change, timed on real instances. Separate the first pass from the rework, and write why the rework happened. Record the date and the person who counted, and keep the identifiers so the same kind of instance can be opened again. A workshop estimate is not a baseline. A single number for the whole estate hides the process, and then there is nothing to recount.

### Can we use a percentage from another programme?

Only a percentage you calculated from your own hours and your own costs. A borrowed figure, from another programme or a vendor slide, is not a return. This guide does not supply one. If a percentage is already in a board paper, the next pack should say it was not measured here and replace it with the hours. Leave the borrowed number out, or it will be the figure people repeat.

### Which costs can we put on the page honestly?

Licences, add-ons, usage you expect to pay for, and implementation time, including internal hours and the hours the business spends in workshops. Salesforce says its pricing options include Flex Credits, Resolutions, or per-user licensing. Data 360 help says some features are add-on licences and some have usage limits that can be adjusted. If you have not chosen the option, or you do not know the edition, leave the cell blank. A round number invented to fill a blank is the number the steering group will remember.

### Does a longer list of clouds improve the case?

It increases the footprint, and often the cost. The return is a measured process getting shorter, or measured rework stopping. Adding a product because the diagram looked empty does not create that change. If you cannot name the process, you do not have a case yet. A licence discount can sit on the cost page. It is not a shorter quote unless you timed the quote and the second sitting actually stopped.

### What do we do if the recount is worse?

Publish it next to the baseline, using the same method and a named person. The hours got worse, and that is a result. Include the instances that deteriorated, not only the ones that improved. Adjust the programme from that page rather than from the original cloud list. A pack that only restates the footprint has not calculated anything, and it cannot tell you whether to continue or stop.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce consultancy (https://synconai.com/salesforce-consultancy).