Definitive guide · Business case / ROI
The definitive guide to the business case and the ROI one-pager
A business case is the one closing asset written for a reader who never meets the seller. A deck, a sell sheet, a proposal all assume the person reading is the person deciding, or at least in the room while the decision gets made. A business case assumes the opposite: it will be forwarded and read cold, by somebody who has never heard the pitch, who has a budget to protect and other requests competing for the same dollars.
That reader does not need to be persuaded emotionally. They need a number they can act on without calling anybody back.
State a payback period in time, not a ratio
“This pays for itself in eleven weeks” is a sentence a non-specialist reader can act on immediately. A ratio, a percentage return, or a subscription-business metric like lifetime value against acquisition cost assumes financial literacy the reader may not have, and assumes inputs, recurring revenue and a churn rate, that the buyer's own business may not produce at all.
The generalized form is the one to use: the investment divided by the monthly net benefit, expressed in months or weeks. That is the same arithmetic as the payback metric subscription businesses use, stripped of every term that only exists inside a subscription business. A contractor who sells one-off projects, a sole marketer billing by the hour and a founder pre-revenue all have the inputs for this version. None of them has the inputs for the other one.
The five inputs, and why there are only five
Every input a business case asks for is a chance for the buyer to stop filling it in. The smallest realistic set, in order:
- What the status quo costs today. Either a dollar figure, an agency retainer, a freelancer's day rate, a subscription being replaced, or a time figure converted to dollars: hours spent per month on the task, multiplied by the buyer's own stated hourly value of that time.
- The price of the alternative being proposed. This comes from your own current price list, not from the buyer. Never ask a buyer for a number you already have.
- Expected volume. How many of the thing in question the buyer needs per month or per quarter. A per-unit saving is not a business case until it is multiplied by a volume the buyer actually has.
- Time saved per unit, in hours, multiplied by the hourly value from input one. This is the only number in the model that has to come from the buyer and is not already a dollar figure.
- Optionally, an expected revenue effect, such as a faster close or a higher close rate. This one is different from the other four in kind, and the next section is about why.
Four of those five are facts about cost and time. The fifth is a guess about causation. Keeping them visually and verbally separate is most of the craft in this document.
Label the guess, every time it appears
Inputs one through four are checkable. The buyer knows what they pay today, how many they need and how long it takes. Input five, “this typically shortens the sales cycle by X days,” is an assumption about an effect, and it is the single easiest place in any business document to fabricate something that looks precise and is not.
So it carries a visible illustrative, not measured flag wherever it is shown, not once in a footnote. The standard DesignTech holds its own calculators to says this directly: clarify whether values are illustrative or authoritative, show the assumptions next to the results rather than behind them, keep precision appropriate to the evidence, and never claim measured ROI from hypothetical inputs.
This is not timidity. A finance reader who finds one labeled assumption treats the rest of the document as honest. A finance reader who finds one unlabeled assumption treats the rest of it as marketing, and the two outcomes are not close.
Never invent the buyer's own numbers
Where a status-quo cost, a volume or an hours-saved figure is missing, ask for it and leave it visibly missing until it arrives. Do not fill it with something plausible. A business case with one blank marked “we need this figure from you” is a document a buyer can finish. A business case with a number the buyer does not recognize as theirs is a document they stop reading at the first row of the table.
Define what happens at zero before you build anything
A model that has not decided what happens on a missing input will eventually show one, in front of a buyer, with no plan for it. A blank or zero should produce a stated, sane result, “we need one more number before we can show a payback period,” rather than an error, an infinite payback, a negative one rendered as though it meant something, or the letters NaN sitting where a figure should be.
Decide this first, not last. It is the one behavior in the document that is guaranteed to be exercised, because somebody will always leave a field empty.
Write to the approver, not to the champion
The champion already believes the pitch. This document exists so that the person who has never heard it can approve the spend without a follow-up call. That changes the writing in three specific ways.
- The opening has to stand alone. Assume the reader has no memory of a sales conversation, because they were not in one. One sentence saying what is being proposed, one saying what it replaces, one saying what it costs and when it pays back.
- No internal shorthand, no product names used as verbs, no reference to “the conversation we had.” A forwarded document loses its context in transit.
- Every number visible on one page. A finance reader skims for the inputs, the arithmetic and the result, in that order, and a model whose workings are on a second page reads as a model with something to hide.
Instantiate it per prospect, or do not bother
This row's done condition is explicit: a current model, instantiated with this prospect's own numbers. A reused template with the company name swapped and the same illustrative numbers left in place is not a business case. It is a worse version of the sell sheet, and it is immediately recognizable as one, because the numbers will be suspiciously round and will not match anything the reader knows about their own business.
One instance per prospect, every time. The model is the reusable thing; the document is not.
What not to put anywhere near it
A whole category of finance metrics exists that assumes genuinely recurring, renewing revenue measured monthly, with a churn rate that means something month over month: lifetime value in both its forms, net revenue retention, cohort analysis, and the various composite scores built on top of them. A contractor selling one-off projects, a sole marketer billing hourly, or a founder pre-revenue has none of those numbers and cannot produce them by filling in a form, because the inputs do not exist for their business.
Do not surface them. Two things from that family do generalize and are safe to use: the bare acquisition-cost calculation, since any business with a repeatable way of finding customers has a spend and a count, and a simple funnel conversion model, since any business with a sales process has stages and a rate between them. Everything else in that family belongs in your own operating math, not in a document you hand a buyer.
How you know this has decayed
- A champion is still building their own internal justification from scratch after every call.
- The same illustrative numbers appear, unchanged, in two different prospects' documents.
- A figure in the case contradicts your own current price list.
- Nobody can say which version of the case actually got a budget approved, and which one stalled.
The evidence
The input set and the payback form above are not a convenient simplification. They are what is left after deliberately removing every metric that assumes recurring revenue, because the audience this estate serves, founders, contractors, one-person agencies and sole marketers, mostly does not have it. That removal was done metric by metric against a surveyed finance library, and the result is the five inputs on this page.
The labeling discipline comes from DesignTech's own house standard for ROI calculators and interactive widgets, which is a production standard rather than a marketing position: write the calculation independently of its presentation and verify it against agreed examples, keep units explicit, define behavior for zero, empty, invalid, extreme and negative inputs, show assumptions near results, and do not claim financial certainty or measured ROI from hypothetical inputs. Every one of those requirements is in this guide because it is in that standard.
Being straight about the product: no DesignTech app builds a business case today. It writes structured documents, and nothing in it computes a payback period from your prospect's numbers. That is a real gap in the estate, and this page is not going to describe it as anything else.
Sources
- DesignTech's own production record: 3,996 projects and 18,471 billed hours, 29 July 2018 to 25 September 2026, counted from the agency's primary billing export.
- DesignTech AI's own house production standard for ROI calculators and interactive widgets, for the illustrative-versus-authoritative rule, the zero and invalid-input rule, and the refusal to claim measured ROI from hypothetical inputs.
- The canon's own unit-economics work, for the smallest realistic input set, the generalized payback form, and the explicit list of subscription-business metrics marked as not applicable to a buyer without recurring revenue. The third-party finance templates surveyed there are not reproduced here; only the standard metric definitions are used, in our own words.
The checklist
A condensed version of the standard above, for skimming your own work against. This is not the grading rubric; it is what good looks like, stated plainly enough to check by eye.
- The forwarding test. Read it as somebody who was not in any meeting. Does the first paragraph tell them what is being proposed, what it replaces, and what it costs?
- The payback test. Is the headline result a period of time, rather than a ratio or a percentage?
- The source test. Does every cost and volume figure come from the buyer's own statement or your own price list, and nowhere else?
- The label test. Is every causal or revenue-effect assumption marked illustrative, visibly, everywhere it appears?
- The zero test. Put a zero or a blank in every input. Does the document say something sane, or does it show an error?
- The instance test. Are these this prospect's numbers, or last prospect's numbers with the name changed?
- The jargon test. Is there a single metric on the page whose inputs this buyer's business does not actually produce?
This guide, its blueprint row, and the app
No guide on this site is an island. Each one names the row of the blueprint it serves, what has to exist before that row can be built, and whether anything in the product can actually make the artifact.
Row 22 Tier 3 Justify It ASSET
Business case / ROI
Done means A current model, instantiated with this prospect's own numbers, never a template with the name swapped.
What has to exist first The sales narrative the case argues from, and the objection and security answers, so a finance reader's first follow-up question already has an answer.
The app that makes one No app builds a business case today. The product writes structured documents, but nothing in it computes a payback period from your prospect's numbers, and this guide will not pretend otherwise.
Where to take this
A business case is cheap to build once the model exists and expensive to improvise per deal, which is the whole argument for writing the model down once.
DesignTech AI does not build this one yet. What it does build is the material the case argues from: the deck, the sell sheet, the case study and the proposal around it, from the content you already own. Start free with 2,000 credits and no card, and bring what you already have.