AI Adoption GuideSalesPropose
ROI business case generator
AI builds a quantified value model and CFO narrative from discovery inputs, using tools like Cuvama or Vivun.
Sales processProspectQualifyDiscoverProposeNegotiateCloseHandoffRenew
By Don, DoneThat’s AI coach · updated
Quoted discovery metrics only; blanks stay blank
The quality output is a value model the buyer can defend in finance, built only from quantities they said in discovery, plus a narrative that uses those same quantities. If a number was not said, the cell is empty. A filled cell with no quote fails at the first finance review.
Value selling platforms in the Cuvama and Vivun class hold the model, the assumption log, and the CFO-facing narrative. They are one class of tool, not a ranking. Gong holds the recording and transcript. Salesforce holds the opportunity. The generator sits between those systems. It does not invent a return so the deck looks complete.
Start from what MEDDIC auto-extraction already proposed as Metrics, with the quote attached. If Metrics is empty, you do not have a business case. You have a gap. Send it through a discovery gap analyzer and the next call, not through a benchmark table.
A usable input row has three parts or it does not enter the model:
- The buyer's quantity in their words (hours, headcount, error rate, cycle time, or a cost they named).
- A verbatim quote, with speaker and timestamp or email date.
- A unit the arithmetic can use without a translation they did not approve.
"This is costing us a fortune" is pain, not an input. Do not convert tone into dollars.
Put the formula where finance can see it, and label every assumption
Finance does not argue with a headline return. Finance argues with the inputs and the conversions you hid. Show the arithmetic in the order a CFO will reverse-engineer it: quoted quantity, conversion you applied, dollar result if and only if a rate was also quoted.
Keep three layers visible, not collapsed into one ROI cell:
- Quoted facts. What someone at the account said, with the cite.
- Assumptions. Conversions nobody said: working days in a week, fully loaded cost, adoption ramp, what "two days" means in hours. Each one is a labeled row the AE or the buyer can change.
- Results. Only what facts plus accepted assumptions can produce. If a rate is missing, annualized dollar impact stays blank. If cost and benefit cannot both be stated, ROI and payback stay blank.
The AE and the buyer still own the number. The tool proposes a structure and fills cells that have cites. It does not publish a return. If the champion changes an assumption, that change is the model. If they refuse a conversion, the result cell goes back to blank.
Do not let the generator complete the sheet from a loaded-cost average, a category benchmark, or a default ramp. Those fills die when the VP asks where the rate came from and the answer is "the template." If two assumptions were accepted, you can show what happens when each one moves. Sensitivity is not a license to import a third figure nobody discussed.
Price is not value. A pricing recommendation engine may suggest a band from like-for-like won deals. That band does not belong inside the value model as investment unless this buyer agreed a figure.
Two days a week, and no dollar line
This walkthrough is illustrative, not a measured result.
A director of operations, on a recorded discovery call, says they lose "about two days a week" to a manual forecast rebuild. That is why they took the meeting. They name the VP of Finance as the person who has to sign anything that touches reporting. They do not give a loaded cost, a team size, or a payback they would accept.
A correct model after that call:
- Time lost: about two days a week. Quote attached. Status: quoted.
- What "a day" means in hours: blank. Not said.
- People affected: blank. They said "we," not a headcount.
- Loaded cost or fully loaded FTE rate: blank. Not said.
- Annualized dollar impact: blank. Cannot compute.
- ROI, NPV, payback: blank. Cannot compute.
- Economic buyer: VP of Finance, named, not in the room. Not a signature on the model.
You may propose, as an assumption the champion must accept or reject, that a week means five working days. You may not propose a dollar rate they never discussed. You may not annualize into a headline they cannot source.
The failure version fills the blanks so the slide looks executive-ready. It takes "two days a week," assumes a knowledge-worker loaded cost from an industry table, annualizes a dollar waste line, stamps a return from a lookalike customer, computes a payback, and books time with the VP of Finance. None of those extra figures were said. The first question in that meeting is "where did this number come from?" The director cannot answer it, because they have not seen the deck.
If you need a rate, put it on the next call as a question. "When you say two days a week, is that one person or the pod?" "Do you already have a loaded cost finance uses for this team?" Those are discovery questions, not permission to complete the spreadsheet overnight.
A lookalike case study is analog, not this buyer's return
Case-study retrieval RAG is useful in propose for proof that someone in a similar motion got a result you can name. It is not a source of inputs for this model. A published return and a logo slide describe another account's baseline and math. They do not describe this account.
Keep analog evidence in a separate exhibit: customer, situation, what they measured, what they claimed. Label it analog. Do not paste their multiple, their payback, or their annual benefit into this buyer's result cells.
The failure is quiet. Empty rate cells, a close-enough industry story, and a headline copied because the slide needed a number. Finance will ask whether the number is theirs. If the honest answer is "it is from another customer," the headline was already a problem.
Use the analog to ask a better question on the next call. "They measured rebuild hours before and after. You mentioned two days a week. Can we measure that the same way?" That is still this buyer's model.
The champion reviews the model before finance sees the deck
A CFO narrative the economic buyer has not seen, and that the champion cannot walk through, is an ambush. Do not send the deck to finance, procurement, or a VP who was named but not met, until the person who gave you the quotes has accepted the facts, the assumptions, and every result cell that is not blank.
Review order:
- AE checks every result cell against a quote or an accepted assumption. Anything else is deleted, not footnoted.
- Champion, or the person who said the quantities, walks the arithmetic. They change assumptions in the tool, or they reject them. Their version is what ships.
- Only then does the narrative go into an auto-drafted proposal, as a value section the buyer has already seen, not as a surprise appendix.
Cuvama and Vivun class tools often exist so this review happens in a shared model rather than in a slide the AE built the night before. Salesforce should record that the champion accepted the model, with a date. Gong should remain the cite for the original quotes. None of those systems should auto-email the VP of Finance a board deck.
If there is no champion, there is no internal owner for the numbers. Sending finance a model anyway asks a signer to adopt math they did not ask for.
Refuse these automations even after the team trusts the quotes:
- Filling a blank rate, volume, or cost from an industry average, a persona benchmark, or a typical-customer table.
- Writing this buyer's ROI, NPV, or payback from another customer's case study.
- Computing a multiple or a payback when cost, benefit, or both are still blank.
- Emailing or staging a CFO deck the buyer has not reviewed.
- Treating a completed-looking model as proof the deal is qualified, or as a substitute for a quoted economic buyer.
The quality you are buying is a business case whose every figure is either this buyer's sentence or an assumption they accepted, and whose blanks are still blank.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first