Value Communication & Business Case Questions

Direct answer

I would treat it as an evidence investigation with two goals: find out what really happened (and how much of it we caused), and decide rebuild or exit from the facts, not from the relationship's mood. The order is: reconstruct what was promised, reconstruct what was delivered from the customer's own data, interview the people who bought, used and left, split the gap into causes, then decide using stated criteria, and present the findings as "here is what we promised, what we measured, what drove the gap, what we own", before any ask. I would enter with an offer to listen, not to defend. ROI (return on investment) here means the net benefit the customer was told to expect against what they paid.

1. What data I collect

2. Whom I interview (and what I ask)

• The economic buyer (the executive who signed): "What did you believe you were buying and what would success have looked like in your report to your boss?"
• The champion (the internal advocate): "When did it stop feeling like it was working?"
• The day-to-day users and their manager: "What do you do differently now? What did you stop using, and why?"
• Their finance or operations analyst: "Which numbers did you track and where did they land?"
• Our own account executive (AE, who owned the deal), implementation lead and customer success manager: what was known, what was said and what slipped.

I ask open questions and let them finish, and I do not argue with the account of events in the room. I check everything against the data afterward.

3. Quantify delivered versus promised (worked example)

Illustrative promise: the product cuts manual invoice handling from 12 minutes to 4 minutes on 60,000 invoices a year, at a loaded labour cost (salary plus overhead) of $40 an hour.

$\text{Promised} = 60{,}000 \times \frac{12 - 4}{60} \times \$40 = 8{,}000\text{ h} \times \$40 = \$320{,}000$

What the usage data and the customer's time study show: only 21,000 of the 60,000 invoices (35%) went through the new flow, and each took 6 minutes instead of 12, a saving of 6 minutes, not 8.

$\text{Delivered} = 21{,}000 \times \frac{6}{60} \times \$40 = 2{,}100\text{ h} \times \$40 = \$84{,}000$

Gap: $320,000 - $84,000 = $236,000. Decompose it so the cause is visible. First the time saved per invoice (if all 60,000 had gone through at the 6-minute saving: 60,000 x 6/60 x $40 = $240,000); then adoption.

(The order of decomposition matters, so I state the order I used. Taking adoption first: 21,000 invoices at the promised 8-minute saving is 21,000 x 8/60 x $40 = $112,000, so adoption accounts for $320,000 - $112,000 = $208,000, and the per-invoice shortfall for $112,000 - $84,000 = $28,000. Same $236,000 total, but a very different story: $208,000 and $28,000 instead of $156,000 and $80,000.)

Then I ask who owned each cause. Adoption stalled because two of four invoice sources were never integrated: that is partly ours (we scoped it in) and partly theirs (they did not free the staff for the work). Per-invoice time fell short because the promised 4 minutes assumed a feature that shipped later. That is ours.

4. Rebuild or exit

I would decide with stated criteria:

1. Is the cause fixable? Adoption through a missing integration, yes; a product gap that is not on the roadmap, no.
2. Is there a sponsor still willing to engage, and is the economic buyer reachable?
3. What is the realistic recovered value against the cost of the effort? In the example, if full adoption were fixed the realistic benefit is $240,000 a year against a contract of, say, $150,000 a year, so there is still a case.
4. Does the customer want it? I ask directly, with an offer tied to evidence (for example, a 90-day plan with a measurable adoption target and a named owner on their side).

I exit if the cause is a product gap with no near-term fix, the sponsor is gone, or the customer has already chosen a replacement. Exiting well still means leaving with an honest post-mortem (a review of what went wrong and why) and a goodwill relationship; some of these customers return.

5. Presenting findings

One page, in this order: what we promised (quoted from the document, with the date); what we measured (their data, with their sign-off on the numbers); why it differed (the table above, with causes marked ours, theirs, both); what we own, said plainly; and the proposal (rebuild plan or clean exit). I show it first to the economic buyer in a private conversation, not in front of an audience. I open with: "Before I show you anything, I would like to hear what you expected this to do for you. Then I will show you what we promised, what the data shows, and where we fell short." The ownership statement is plain: "We own two things. We promised a 4-minute handling time that depended on a feature that shipped after go-live, which is $80,000 of the gap. And we agreed to go live with two of your four invoice sources not integrated, which is a large part of the $156,000 adoption gap. Finishing that integration needs your staff time, and that part is yours to decide." Internally I send the same page to product and sales leadership, because a promise made without delivery evidence is a sales-process failure, not only a customer-success one.

Trade-offs and pitfalls

• Do not defend before listening. The first meeting that sounds like a defence ends the relationship.
• Do not use our telemetry as the only evidence. The customer's own baseline is the number they will accept.
• Do not hide our part. The finding where we over-promised is the one that makes the rest believable.
• Sensitivity: the result depends most on the adoption figure, so I verify it two ways (usage logs and the customer's own count).

Direct answer

Buyers do not pay for latency, uptime, throughput or error rate. They pay for what those numbers do to revenue, cost and risk. So I translate with a four-step chain: technical metric, operational effect, business metric, dollar value using the buyer's own inputs, and I say out loud where the chain is weakest. A claim like "99.95% uptime" becomes "about 4 fewer hours a year of the checkout being down than a 99.9% service (8.76 hours versus 4.38), which at your quoted cost per hour is roughly $87,600 a year".

Terms: latency is how long a request takes; uptime (availability) is the share of time the service works; throughput is how much work is done per second or month; error rate is the share of requests that fail. Conversion is the share of visits that end in an order. A percentage point is an absolute step in a percentage (2.00% to 2.05% is 0.05 points, but a 2.5% relative increase). An A/B test shows half of visitors the old version and half the new, then compares results. Cost avoidance is spend you would otherwise have had to make, as opposed to spend you cut.

The chain, worked on four metrics

All business inputs are illustrative placeholders that I would replace with the buyer's numbers. Examples 1 and 2 are the core chains to rehearse; Examples 3 and 4 use the same four steps in table form.

Example 1: uptime to cost and risk

A year has 8,760 hours.

Difference: 4.38 hours. If the buyer says an hour of checkout downtime costs about $20,000, that is 4.38 x $20,000 = $87,600 a year (8.76 hours cost $175,200 versus 4.38 hours at $87,600). In the room I say: "What does an hour of downtime cost you in sales and in people's time?" and then do the multiplication with their number.

Weak link: only downtime during revenue hours costs that much, and contractual service credits (money returned when we miss the target) are not the buyer's real loss. Also, availability multiplies across a chain: three dependencies each at 99.9% give 0.999 x 0.999 x 0.999, about 99.7%, so the figure I quote must be for the whole path the buyer cares about.

Example 2: latency to revenue

If the buyer's own A/B test or analytics show that a faster checkout step converts better, I use that. Suppose our service makes the checkout step respond in 1.3 seconds instead of 1.8 (500 milliseconds faster), and the buyer's test measured a conversion lift of 0.05 percentage points (for example 2.00% to 2.05%) for that gain. With 2,000,000 sessions a month, that is 2,000,000 x 0.0005 = 1,000 extra orders, at $80 each = $80,000 a month. I would only credit 30% of it to our change because other releases also ship, giving $24,000 a month.

Weak link: the relationship between speed and conversion is specific to the page and the audience, and the lift usually flattens. I do not quote an industry statistic as if it were theirs; I ask for their data or propose a test.

Examples 3 and 4, in table form

How I say it in the room

"You told me an hour of downtime costs about $20,000. We take you from roughly 9 hours a year to roughly 4. Is that a number your finance team would accept, and what would you change?" Inviting the correction moves the number toward theirs.

Trade-offs and pitfalls

• Present the logic and let them own the inputs. A number I invented is a number they can dismiss.
• Say where the link is weak (conversion lift, share of downtime in revenue hours). Admitting it is why they trust the rest.
• Separate revenue protected or gained, cost saved and risk reduced (risk is expected loss: probability times impact, which is softer).
• Avoid vanity precision. Round to what the inputs justify.

Direct answer

A one-page business case for an executive sponsor (the senior person who funds and backs the project) fits on one page and reads in five minutes: a recommendation, the three or four numbers that matter, the assumptions behind them, the risks, and the ask. The chart I would choose is a cumulative net cash curve that shows the payback point with a downside line.

The sections, top to bottom

1. Recommendation and ask (2 sentences): what you want approved, the amount, and by when.
2. The problem and its cost today (3 lines): the baseline, with the source of each number.
3. The solution in one paragraph: what changes, in plain language.
4. Financials (small table): the one-time cost, the annual benefit, payback period (the months until cumulative benefit covers the cost), a 3-year TCO (total cost of ownership, all costs including running costs) comparison, and NPV (net present value, future cash flows discounted to today's money) if finance asks for it.
5. Assumptions and sensitivity: the 3 to 5 inputs the answer depends on and what happens to the result if each one is wrong (sensitivity means how much the answer moves when one input changes).
6. Risks and mitigations: the top two or three, with an owner.
7. Timeline and next step.

Numbers that must be on it (worked example, all inputs illustrative)

Order-processing automation: 15,000 orders per month, handling time falls from 9 to 3 minutes. Loaded cost means the full hourly cost of an employee (salary plus benefits and overhead), here $40 per hour. The baseline is today's measured number before the change.

• Hours saved: 15,000 x (9 - 3) / 60 = 1,500 hours per month, 18,000 hours per year.
• FTE (full-time equivalent) saved: 18,000 / 1,800 working hours per FTE per year = 10 FTE.
• Gross labour benefit: 18,000 x $40 = $720,000 per year. This is the saving in handling labour only.

The same numbers feed the TCO table, so the two figures reconcile:

• Annual net benefit (the number for the Financials table): $1,080,000 - $510,000 = $570,000, which is the $720,000 labour saving less the $150,000 running cost.
• One-time cost (implementation): $200,000.
• 3-year TCO: status quo $1,080,000 x 3 = $3,240,000. Proposed $510,000 x 3 + $200,000 = $1,730,000. Reduction $1,510,000 (46.6%).
• Payback: $200,000 / ($570,000 / 12 = $47,500 per month) = 4.2 months, so the cumulative line crosses zero in month 5.
• NPV over 3 years at a 10% discount rate, with each year's net benefit counted at year end: $570,000 x 2.487 (the 3-year annuity factor at 10%) - $200,000 = about $1.22M.
• Revenue: faster order handling might recover 0.5% of $12M of annual revenue, or $60k, but this is the least certain number so I list it separately and exclude it from the headline.

Assumptions that must appear: volume, handling time before and after, hours per FTE, loaded hourly cost, licence cost, and where each number came from (the customer's own system or a stated estimate). The assumption the answer is most sensitive to is the post-automation handling time, so show the result if it were 5 minutes rather than 3: hours saved fall to 15,000 x 4 / 60 = 1,000 per month (12,000 per year), the labour saving becomes $480,000, the annual net benefit becomes $480,000 - $150,000 = $330,000, and payback stretches from 4.2 to 200,000 / 27,500 = 7.3 months (month 8).

The chart

A line chart of cumulative net cash by month with a base case and a lower-benefit case. Using the numbers above, the base line starts at -$200,000 and rises $47,500 a month, crossing zero in month 5; the lower-benefit line starts at the same point, rises $27,500 a month and crosses in month 8. The chart shows the dip while the cost is spent, the month the line crosses zero (payback), and how late it moves if benefits come in lower, so the sponsor sees both the return and the risk in one picture. Avoid a pie chart or a feature table here: they show composition, not credibility.

If you have 30 minutes to prepare for a procurement audience

Spend it in this order: confirm three metrics and their sources (FTE-hours, TCO, revenue) with the customer, redo the arithmetic once end to end, draw the payback chart, and write the assumptions list. Procurement will go straight to the assumptions and the TCO, so those need to be exact.

Pitfalls

• A benefit with no source is worse than no benefit.
• Reporting the best case only. A one-page case with no downside reads as sales material.
• Counting soft benefits (morale, brand) in the headline number.

Direct answer

Before a renewal, the CFO wants one thing from the deck: evidence that the money spent returned what was promised, in numbers Finance can audit. I would build an eight-slide deck that opens with the answer, shows realized value against projected value line by line, says how every number was measured, shows risk reduction separately and conservatively, admits the gaps, and ends with the renewal in terms of the next twelve months. The CFO (chief financial officer) is the audience; a QBR (quarterly business review) deck, which normally covers usage, support tickets and roadmap and says little about money, would be too soft for this audience. The brief is about presenting the numbers, not building the model, so the structure below assumes a value model already exists.

Terms: a baseline is the "before" number a benefit is measured against (for example, the cost per invoice in the three months before the product). Go-live is the day a team starts using the product for real work. Hard savings are cash that actually leaves the budget (a cancelled licence); productivity is capacity released, not cash. The counterfactual is what would have happened without the product. Re-baselining is changing the baseline after the fact, which is why it must be visible. Recurring benefits repeat every year; one-time benefits (a one-off clean-up) do not. ROI (return on investment) is net benefit divided by cost. Causal attribution means showing the product, not something else, caused the change.

Slide-by-slide structure and the data behind each

Worked numbers for slides 3, 6 and 7 (illustrative)

Realized share: 780,000 / 1,000,000 = 78%. Gap: $220,000. Drivers on slide 7: two of five business units went live a quarter late, worth about $120,000 this year and recoverable next year; the remaining $100,000 is lower per-transaction savings than the model assumed, which is a model correction, not a delay.

ROI on slide 6. With subscription and services cost of $400,000 for the year: realized ROI = (780,000 - 400,000) / 400,000 = 95%, against 150% projected ((1,000,000 - 400,000) / 400,000). ROI is net benefit divided by cost.

Showing risk reduction credibly (slide 5)

Risk benefits are the first thing a CFO discounts, so I present them as a separate line, never inside the $780,000. The method is expected loss avoided: the number of incidents multiplied by the average cost per incident, taken from the customer's own log, not an industry average. Example: the customer's log shows 3 serious incidents a year before at an average of $90,000 each ($270,000), and 1 this year ($90,000). Two avoided incidents at $90,000 is $180,000. I label it "indicative: one year of data, causal attribution is partial", and I show the incident count so the CFO can judge whether two avoided incidents is signal or luck. I do not add it to ROI.

Finance questions I would prepare for

1. "Is the $160,000 of productivity real cash?" No: it is capacity, not budget released. I show where the hours went (for example, more audits done) and let the CFO decide how to treat it. I never present it as savings that reduce headcount unless it did.
2. "What baseline did you use and who agreed it?" Point to slide 4 and the sign-off. In words: "The baseline is your own cost per invoice for the three months before go-live, pulled from your finance system and signed off by your controller on the date shown on slide 4. If you want a different baseline, I will show both."
3. "What would have happened without the product?" The counterfactual: I show the trend before go-live and any other change in the period, and say what I cannot separate. In words: "Invoice volume was already flat before go-live, and the hiring freeze in the third quarter also reduced effort. I show both on slide 4. What I cannot cleanly separate is the freeze's effect on the productivity line, which is why that line is tagged estimated."
4. "Why 78% and not 100%?" Slide 7, with the $120,000 timing and $100,000 model correction.
5. "What does next year look like and what are you assuming?" Slide 8, with the same baseline, the late units' benefit now arriving and no new promises.
6. "What are the total costs, including our internal time?" I include customer-side effort in the cost line so the ROI is not flattering.
7. "How much of this is one-off?" Separate recurring from one-time lines, and say so. In words: "All $780,000 is recurring: the licence retirements and invoice savings repeat every year, and I expect the productivity line to as well. If there were a one-off item, such as a one-time data clean-up saving, I would show it on its own row so year two is not overstated."
8. "What if we do not renew?" Answer honestly with the costs of leaving, kept factual and short. A CFO who senses a threat stops listening.

Trade-offs and pitfalls

• Realized and projected must sit side by side. Showing only realized hides the gap and the CFO will find it.
• Never re-baseline quietly. If the baseline changed, say when and why, and show both.
• Estimated numbers wear a label. Mixing estimated and measured values without tags makes the audited number look like the guessed one.
• What I would change by customer: with a sceptical CFO I would put slide 4 (method) before slide 3 (results), so the method is accepted before the number arrives.

Direct answer

I would give the CIO (chief information officer) the three-year case in three scenarios, with the worst case shown first because they asked for it, the assumptions printed on the page, and the risks that produce the worst case named with a mitigation for each. The aim is not to make the worst case look good. It is to show that the downside is bounded, that I know what would cause it, and that the base case still earns its place. NPV (net present value) is the sum of yearly cash flows each divided by (1 + discount rate) raised to the year number; payback is the time until cumulative cash flow turns positive.

Assumptions I state out loud (illustrative platform deal)

The discount rate expresses that a dollar next year is worth less than a dollar today, because money today can earn a return elsewhere. Using the customer's own cost of capital (the return they could earn on the money elsewhere) as the rate is what makes NPV meaningful to their finance team; 10% here is an assumption to replace.

The numbers (code is real, run it unchanged)

RATE = 0.10  # annual discount rate, assumed

def npv(flows):
    return sum(cf / (1 + RATE) ** t for t, cf in enumerate(flows))

def flows(full_benefit, ramp, license_by_year, staff=40_000, impl=90_000):
    out = [-impl]
    for y in range(3):
        out.append(full_benefit * ramp[y] - license_by_year[y] - staff)
    return out

def payback_years(fl):
    cum = 0
    for t, cf in enumerate(fl):
        prev, cum = cum, cum + cf
        if t > 0 and cum >= 0 > prev:
            return round((t - 1) + (-prev / cf), 2)
    return None

cases = {
    "Base":                   flows(400_000, [0.5, 0.9, 1.0], [120_000] * 3),
    "Worst":                  flows(260_000, [0.3, 0.6, 0.8], [120_000] * 3),
    "Worst, with mitigation": flows(260_000, [0.3, 0.6, 0.8], [60_000, 120_000, 120_000], impl=45_000),
}
for name, fl in cases.items():
    print(f"{name:24s} flows={[round(x) for x in fl]} 3yr_total={round(sum(fl))} NPV={round(npv(fl))} payback_yrs={payback_years(fl)}")

lo, hi = 0.0, 800_000.0
for _ in range(60):
    mid = (lo + hi) / 2
    if npv(flows(mid, [0.5, 0.9, 1.0], [120_000] * 3)) > 0:
        hi = mid
    else:
        lo = mid
print("break-even full-run annual benefit, base ramp:", round(hi))
fl = cases["Worst, with mitigation"][:2]
print("loss if you exit after year 1 (worst, mitigated):", round(sum(fl)))

Output:

Base                     flows=[-90000, 40000, 200000, 240000] 3yr_total=390000 NPV=291968 payback_yrs=1.25
Worst                    flows=[-90000, -82000, -4000, 48000] 3yr_total=-128000 NPV=-131788 payback_yrs=None
Worst, with mitigation   flows=[-45000, -22000, -4000, 48000] 3yr_total=-23000 NPV=-32243 payback_yrs=None
break-even full-run annual benefit, base ramp: 250247
loss if you exit after year 1 (worst, mitigated): -67000

Reading the code in plain language

• npv divides each year's cash flow by 1.10 once for every year it is away from today, then adds them up. Hand trace of the base case: -90,000 + 40,000 / 1.1 + 200,000 / 1.21 + 240,000 / 1.331 = -90,000 + 36,364 + 165,289 + 180,316 = 291,968 (to the nearest dollar).
• flows builds the list of cash flows: year 0 is minus the implementation fee, then each year is benefit times that year's ramp share, minus licence, minus staff time. Base year 1 is 400,000 x 0.5 - 120,000 - 40,000 = 40,000.
• payback_years keeps a running total cum of cash flows (cumulative cash flow). The test cum >= 0 > prev is true only in the year the running total crosses from below zero to zero or above, using prev for last year's total. The payback is the whole years before that year plus the fraction of the crossing year needed to cover the gap. Base case: the total is -50,000 after year 1, then year 2 brings +200,000, so payback is 1 + 50,000 / 200,000 = 1.25 years.
• The for _ in range(60) loop is a bisection search for the break-even benefit, the full-run benefit at which NPV is exactly zero. It starts with a bracket from 0 to 800,000, tests the midpoint, and keeps the half that still contains the zero crossing (if NPV is positive at the midpoint, break-even is lower, so hi moves down; otherwise lo moves up). Sixty halvings narrow the bracket far below one dollar.
• In the mitigated case impl is 45,000 because that is the worst case, where the adoption target is missed, so the second half of the implementation fee (45,000) is never triggered and is simply not paid. If the target were met, benefits would be higher than this worst case and the full 90,000 would apply.

What I say

"If everything goes right, you net $390,000 over three years and pay back in about 15 months. If benefits arrive late and land at 65% of plan (260 vs 400), you are $128,000 down over three years, with an annual run rate turning positive in year 3. That is the worst case I can defend, and I would rather you see it from me. The break-even benefit is about $250,000 a year, so benefits can fall about 37% before the case turns negative on this ramp."

In today's money (NPV at 10%) the base case is +$291,968, the worst case is -$131,788 and the mitigated worst case is -$32,243. NPV adds one thing the plain totals do not: it counts a dollar that arrives in year 3 as worth less than a dollar spent today, so it is slightly harsher on a case whose benefits come late. A positive NPV means the project beats the customer's alternative use of the money; a negative one means it does not, at that rate.

Risks behind the worst case and the mitigation for each

Mitigated worst case in the table: year-1 licence $60,000 and the second half of the implementation fee ($45,000) payable only when the agreed adoption target is met. Worst-case three-year loss shrinks from $128,000 to $23,000, and if the CIO exits after year 1 the loss is capped at $67,000.

When benefits are volatile (for example seasonal swings)

If revenue or savings swing by season, I model by quarter or month, not year, because an annual average hides a bad quarter that the CFO (chief financial officer) will feel. Example (illustrative): a $260,000 full-run benefit with 10%, 15%, 30% and 45% landing in quarters 1 to 4, against $40,000 of licence and staff cost each quarter, gives net -$14,000, -$1,000, +$38,000 and +$77,000. The year nets +$100,000, but cumulative cash sits at -$15,000 until quarter 3. I show best, base and worst case with the cumulative-cash chart and mark the break-even point on it. I tell the CFO which months carry the most risk, and I advocate for the base case by showing the downside is bounded, not by hiding it.

Staying persuasive while honest

1. Say the worst case first and own it. Candour is a trust signal.
2. Show what must be true for the base case, not just the number.
3. Convert uncertainty into decisions: milestones, review points, an exit.
4. End with a recommendation: proceed with the staged commercial terms.

Pitfalls

• A worst case that is still unrealistically good invites the question "is this really your worst?" Pick a pessimistic ramp the buyer recognises.
• Discounting only helps credibility if the rate is the customer's own cost of capital, so ask finance for it.
• Do not claim mitigations that the contract does not contain.