| name | business-case |
| description | Quantified ROI / value model for a deal from buyer-stated metrics + approved proof. Trigger: 'business case', 'ROI', 'payback', 'justify the investment'. Value math only — pricing = quote-desk. |
| origin | ESCC |
Business Case
The ROI and value-engineering model for a deal. Takes the buyer's own numbers
(MEDDPICC M: the quantified pain they have described) and pairs them with approved
benchmark data from product-knowledge to produce a current-state / proposed-state
comparison and a payback / ROI frame. Every input in the model is sourced -- either
buyer-stated or from an approved entry. If a number is missing, the model records
the gap rather than assuming a benchmark the buyer has not validated.
Governing rules: rules/common/selling-principles.md (never fabricate
claims; no invented benchmarks); rules/meddpicc/qualification.md (M evidence is
the input; the deal-review M score gates whether a business case can be built
rigorously); rules/meddpicc/deal-review.md (M scoring discipline);
rules/common/forecasting-definitions.md Currency-correctness clause
(v1.8.0) — every ROI figure carries a currency code; buyer-stated metrics in
one currency are never mixed with costs in another without normalizing
through the workspace locale config and stating the rate + as-of date.
When to Activate
Activate this skill when:
- An economic buyer or champion explicitly asks for ROI, payback period, total cost
of ownership comparison, or "the numbers" behind the recommendation.
proposal-builder calls for the ROI section and the model has not been run yet.- A deal is at or approaching evaluation / business-review stage and the champion
needs a financial justification to present to the economic buyer internally.
- The rep wants to pressure-test MEDDPICC M before a forecast call: "Is the pain
actually quantified, or are we guessing?"
Do not activate when:
- The buyer's M is not captured (red in MEDDPICC) -- the model cannot be built
rigorously without it. Stop, note the gap, and probe for a number first.
- Pricing, discount, or packaging is the question -- that is
quote-desk. This
skill models value delivered; quote-desk models price charged.
- The only "metric" available is a benchmark the rep wants to borrow from a
different industry or segment without the buyer validating it. Use only
buyer-validated or approved-proof inputs.
The value model structure
A business case has five components:
| Component | What goes here | Source requirement |
|---|
| Current-state cost | The buyer's baseline: what the problem costs them now (time, revenue, risk, headcount) | Buyer-stated (direct quote or CRM record) |
| Proposed-state outcome | The improvement they would achieve with the solution | Approved proof point from product-knowledge (with guardrail check) OR buyer hypothesis (clearly flagged as unvalidated) |
| Delta | Proposed minus current = value delivered | Derived from the two rows above |
| Payback | Time to recover the investment (investment / annualized delta) | Investment figure from quote-desk; delta from above |
| 3-year ROI | ((3-year delta - total investment) / total investment) x 100 | Same sourcing discipline |
Workflow
Step 1 -- Confirm M evidence exists
- Pull the deal's MEDDPICC M from the CRM or from the latest
deal-review output.
- M is "known" only when there is a specific number the buyer stated:
- A dollar cost ("we lose $200K/quarter to manual re-forecasting").
- A time cost ("three people spend two days each on this before every board").
- A rate / miss ("our forecast accuracy is 60%; we need 85% to hit quota").
- If M is amber (general statement without a number) or red (no metric at all):
- Do not fill in an assumed benchmark. Record the gap:
"M is amber -- buyer has described pain qualitatively but has not quantified
it. Before running the business case, probe: 'What does that cost you per
quarter in <time / revenue / rework>?'"
- Pause the workflow. Do not produce a model with invented inputs.
Step 2 -- Build the current-state cost line
- From the buyer-stated M evidence, identify every cost bucket the pain generates:
- Direct costs: staff time, tooling, rework, error correction.
- Opportunity costs: deals missed, revenue not captured, targets not hit.
- Risk costs: audit exposure, compliance gaps, reputational items (where the
buyer has stated these -- never invent a risk category).
- Express each bucket as an annualized number. Show the arithmetic openly:
"3 analysts x 2 days/month x 12 months x $ = $X/year."
- Label each number with its source:
buyer-stated (discovery call <date>) or
buyer-confirmed in email <date>. A number with no attribution is not usable.
- Sum the current-state cost. This is the "problem worth solving" line.
Step 3 -- Build the proposed-state outcome line
- For each cost bucket identified in Step 2, query
product-knowledge for approved
proof via its specificity ladder — role + segment + competitor, falling back to
role+segment, then segment, then general (the buyer's role resolves from jobtitle):
- Prefer a proof point that matches the buyer's role and segment.
- Use the specific improvement percentage / time reduction / accuracy gain
from the approved entry; do not round up or extrapolate beyond what the
entry states.
- Apply the approved improvement to the buyer's own cost figure:
"Buyer loses $400K/year to manual rework. PP-031 shows median 70% reduction in
rework time across mid-market onboards. Proposed outcome: $280K reduction."
- If
product-knowledge returns no approved proof for a cost bucket, do one of:
- Leave the line as a question mark with a note: "[Gap -- no approved benchmark
for . Work with SE/customer success to find a comparable reference
before presenting this line to the buyer.]"
- Ask the buyer to provide their own expectation: "What improvement would you
need to see in to consider this a success?" -- use their stated target
as the proposed-state, clearly labeled as buyer-expectation rather than vendor
proof.
- Never borrow a benchmark from a different segment without noting the mismatch.
Step 4 -- Calculate delta, payback, and ROI
- Delta = proposed-state outcome (annual value) per step above.
- Payback requires the investment figure. Request it from
quote-desk -- do
not invent a price. If the quote is not yet produced, insert a placeholder:
"[Investment: pending quote-desk output -- insert ACV/TCV here before sharing
the model with the buyer]."
- Payback months = (Investment / (Annual delta / 12)).
- 3-year ROI = ((Delta x 3 - Total 3-year investment) / Total 3-year investment)
x 100. Show the formula, not just the answer; the buyer's finance team will
check the math.
- Sensitivity check: show a conservative (50% of approved proof) and an expected
(100%) scenario. This is honest and pre-empts the "your numbers are optimistic"
objection. Do not show an aggressive (>100%) scenario without a buyer-validated
basis for it.
Step 5 -- Assemble the model output
Produce a structured summary suitable for embedding in proposal-builder or
presenting in a champion-to-CFO brief:
BUSINESS CASE SUMMARY -- <Account> -- <Date>
CURRENT STATE
[Cost bucket 1]: $X/year (source: <buyer-stated>)
[Cost bucket 2]: $X/year (source: <buyer-stated>)
Total current-state cost: $X/year
PROPOSED OUTCOME
[Cost bucket 1]: $X reduction/year (proof: <PP-xxx, approved, verified <date>>)
[Cost bucket 2]: [Gap -- needs approved proof]
Total value delivered (expected scenario): $X/year
INVESTMENT
[Pending quote-desk -- insert ACV here]
PAYBACK
Conservative (50% proof): X months
Expected (100% proof): X months
3-YEAR ROI
Conservative: X%
Expected: X%
INPUTS SOURCING
All buyer inputs: discovery call <date> / CRM record <id>
All proof inputs: product-knowledge entries <ids>
Investment: quote-desk (pending / <quote id>)
Step 6 -- Log to CRM and flag for deal-review
- Post the completed model (or the gap summary if M was unconfirmed) to the
HubSpot deal record via
crm-operator.
- If gaps remain (M unconfirmed, proof missing, investment pending), flag them
as open items in the deal's next-step notes so
deal-review picks them up.
Examples
Well-sourced model:
Buyer: "Our reps spend 2 hours each week updating forecasts manually. We have 40
reps. We pay reps roughly $100K loaded, so about $50/hour."
Business case calculation:
Current-state cost:
40 reps x 2 hrs/week x 50 weeks x $50/hr = $200,000/year
source: buyer-stated, VP Sales discovery call 2026-05-14.
Proposed outcome:
product-knowledge PP-031: "median 80% reduction in manual forecast entry
(mid-market, 12 accounts, Q1-2026 internal data)".
Applied: $200K x 80% = $160K/year value delivered.
Investment: pending quote-desk -- placeholder inserted.
Payback (expected): [investment] / ($160K / 12) = [X] months once quote complete.
Conservative scenario (50% of PP-031): $80K/year -- payback doubles.
M gap -- model paused:
Discovery note: "Forecast is a mess, takes forever."
Business case assessment:
M is red -- no quantified metric. Buyer has described pain qualitatively only.
Cannot build a credible model on vague language.
Recommended probe (next call):
"When you say it takes forever -- how many hours per week across the team,
roughly? And what does a rep's loaded cost look like for you?"
Once a number is confirmed, re-run this skill.
DO NOT produce: "Based on industry benchmarks, this likely costs $150K/year."
Reason: no buyer validation + no approved source for that figure.
Proof point gap -- honest placeholder:
Cost bucket identified: "Customer support escalations from reporting errors".
Buyer states: ~15 escalations/month, 4 hours each to resolve, $75/hr support cost.
Current-state cost: 15 x 4 x 12 x $75 = $54,000/year.
product-knowledge query: no approved proof point for "support escalation reduction".
Closest entry: VP-009 (retention visibility -- general) -- not specific enough.
Proposed-state line:
"[Gap -- no approved proof for support escalation reduction. Add placeholder.]
To complete this line: (a) ask SE if a comparable deployment exists, or
(b) ask the buyer what a 50% reduction in escalations would mean to them and
use their stated expectation, labeled buyer-hypothesis."
Anti-patterns
- Filling in M with an industry average the buyer has not validated. "SaaS
companies typically spend X on this" is not M evidence. M is the buyer's own
number. Benchmark data from product-knowledge can corroborate; it cannot replace
a buyer-stated figure.
- Borrowing a proof point from the wrong segment. An enterprise deployment
result applied to an SMB deal will be challenged and will damage credibility.
Match segment explicitly; if there is no segment match, say so.
- Including pricing in the value model. The business case shows value delivered
(numerator of the ROI). Price (denominator) comes from
quote-desk. Mixing them
forces premature price anchoring.
- Showing only the optimistic scenario. A single "best case" number signals
vendor enthusiasm, not rigor. The conservative scenario demonstrates intellectual
honesty and pre-empts the finance team's skepticism.
- Presenting the model to the buyer before the champion has reviewed it.
The champion should validate the inputs with the rep before the model goes to
the economic buyer. A surprised champion will not defend numbers they have not
seen. Use
stakeholder-mapping to sequence this correctly.
- Rounding up proof points. If PP-031 says 70%, the model uses 70%, not "up
to 80%" or "approximately 75%". The guardrail in product-knowledge is the ceiling.
Related
product-knowledge -- source for all approved proof points used in the
proposed-outcome line.quote-desk -- owns pricing and investment figures; business-case inserts a
placeholder and waits for the quote.deal-review -- M evidence score is the gate for Step 1 of this workflow.proposal-builder -- embeds the business case summary as a section;
this skill runs first and hands off the output.stakeholder-mapping -- advises on who reviews the model before it goes to
the economic buyer.rules/meddpicc/qualification.md -- M definition and evidence standard.rules/meddpicc/deal-review.md -- M scoring and gap-to-action discipline.rules/common/selling-principles.md -- no fabrication; cite every number.
