Your website is losing enquiries, and you can feel it. Your partners see something else: a design bill with no return attached. That gap — between what the person closest to the website knows and what the people holding the budget can prove — is where redesign requests go to die. A business case for a website redesign closes it: it replaces opinion with a measured baseline, prices the cost of doing nothing, and asks only for the improvement needed to break even. Here are the five steps, the honest arithmetic and a one-page template.
The short answer: what a partner-proof business case contains, on one page
A partner-proof case fits on one page and answers six questions in order. What is broken, in numbers? What is that costing us each month? What exactly are we asking for, and what is the total cost — build, content, internal time and running costs included? How small an improvement would pay it back, and over what period? What could go wrong, and what is the mitigation? And what decision do we need, by when? Everything else is appendix material.
Why good redesign requests die: opinion in, no numbers out
Most requests fail before the numbers are even discussed. They lead with taste: the site looks dated, a competitor looks sharper, the homepage feels embarrassing. None of it tells a finance-minded partner what changes if the money is spent.
Three habits make it worse. The agency quote arrives before the problem is measured, so the meeting debates price instead of evidence. The projected return is a single confident number with no assumptions shown, inviting disbelief. And the risks — rankings, downtime, disruption — go unmentioned, so partners raise them as objections. The fix is not a bigger deck; it is better evidence.
Step 1 — Baseline what you can prove: traffic, enquiries, conversion and value
Start with what you can prove, over 90 days. From GA4, take sessions, key landing pages, and your key events: form submissions, calls and WhatsApp clicks, counted consistently. From Google Search Console, take organic clicks and the pages earning them. Then reconcile: CRM records, the sales team's log and WhatsApp threads. Gaps are evidence too — enquiries generated but never followed up point to a lead leakage problem no redesign alone fixes.
Turn enquiries into money carefully. You need three figures your partners already trust: the share of enquiries that become customers (close rate), the average value of a won customer, and the contribution margin on that value after delivery costs. Work with contribution, never gross revenue.
If analytics are incomplete, use the fallback: for four weeks, tally every enquiry manually and reconcile weekly with sales. A short, honest baseline beats a precise-looking export nobody believes. If you cite performance, use the web.dev thresholds — LCP ≤ 2.5 seconds, INP ≤ 200 milliseconds, CLS ≤ 0.1 — on real visits.

Step 2 — Price the cost of doing nothing, month by month
Doing nothing is not free, but price it in two columns. The first holds costs you can document today: hours staff spend working around an unsafe-to-update CMS, patching on a fragile site, paid campaigns sending clicks to non-converting pages, and enquiries lost to broken forms or slow mobile pages. Use real invoices, timesheets and campaign spend.
The second column is conditional, labelled that way: the contribution forgone each month if the improvement in Step 3 turns out to be real. It is only as good as its assumptions, so never present it as money already lost. Together, they show what is at stake if your base case is roughly right: a quarter of deferral costs three times the monthly figure.

Step 3 — Build the return honestly: break-even uplift, payback and three cases
Most cases lose credibility here, so invert the usual method. Do not start with an assumed uplift multiplied into a headline return. Start with the total cost from Step 4 and ask: how small an improvement would pay this back?
Work through this illustrative example — assumptions chosen for demonstration, not benchmarks. Say your baseline is 4,000 sessions a month converting at 2%, giving 80 enquiries; a 25% close rate gives 20 customers; contribution per customer is AED 3,000 — about AED 60,000 a month. Say the total project cost is AED 30,000. To pay that back within 12 months you need AED 2,500 a month extra — one extra customer a month, or a 4% relative improvement in conversion.
Show three cases on the same baseline. Conservative: no improvement — no payback, and the case must rest on documented costs and risk, or not be made. Base: a 10% relative improvement adds AED 6,000 a month, paying back in five months. Optimistic: 20% adds AED 12,000 a month, paying back in two and a half months. Model search-traffic changes separately, and allow a ramp-up after launch.
Step 4 — Cost the proposal properly: build, content, internal time and running costs
A case priced on the agency fee alone will be re-opened the first time an extra cost appears. Total the whole investment: design and build; content, photography and video if pages are rewritten; migration and redirect work; your team's internal time, costed at real rates; and the first year of running costs — hosting, licences, maintenance and support.
Anchor the build cost in verifiable figures where you can. Published starter packages give partners a reference point — WebStackRank's are AED 990 for a one-page website, AED 2,490 for a small business website of up to five pages and AED 4,990 for a basic business web app — but present them as starter anchors, not the price of your redesign. Your figure comes from an itemised proposal for your scope; our guide to how much a website costs explains what moves it.
Step 5 — Answer the risks before they are raised: SEO, downtime, scope and failure
Raise the risks yourself, each with its mitigation, before a partner can raise them as a veto. Search visibility: a redesign that changes URLs or templates can disturb rankings, so the plan must include a URL map, redirects and post-launch monitoring — our website redesign SEO migration checklist sets out that control. Downtime: staging and a rollback route keep the live site selling.
Scope: the approved scope is fixed in writing, because unmanaged changes grow budgets. How change requests are handled inside a running project, and how an approved budget is then divided, are covered in our guides to scope creep and change requests and allocating a website budget — next steps after approval, not part of this case. Failure: agree what you will measure at 90 days, and what changes if the base case is not materialising.
When the honest case says "don't redesign yet": the cheaper fixes to ask for instead
Sometimes the baseline shows the platform is sound and one or two fixable problems do the damage: tracking that undercounts enquiries, a campaign landing page that converts badly, a slow key template, a form that loses submissions. Asking for those fixes instead — cheaper, faster, measurable — is not a failed case. It is the same discipline producing a smaller, better ask, and it buys credibility for when the full case is needed. If the open question is which scope you need, settle it with the refresh, redesign or rebuild decision.
The one-page template: copy this structure into your proposal
Copy this structure — one page, in this order, with evidence in an appendix.
| Section | What goes there |
|---|---|
| The problem | One sentence: what the website is failing to do, in business terms |
| Baseline evidence | Sessions, enquiries, conversion rate, close rate, contribution per customer — period stated |
| Cost of doing nothing | Documented monthly costs, then the conditional forgone contribution, labelled as conditional |
| The ask | Scope in one line; total cost including content, internal time and first-year running costs; decision date |
| Break-even and three cases | Improvement needed to pay back in 12 months; conservative, base and optimistic payback |
| Risks and mitigations | SEO migration, downtime, scope control, the 90-day measurement test |
| Decision requested | Approve, approve a smaller fix, or reject — by a named date |

Common mistakes that lose the room
Leading with screenshots of competitors instead of your own numbers. Borrowing benchmark uplift figures and presenting them as your forecast. Calculating return on gross revenue instead of contribution. Forgetting content, internal time and running costs, so the "total" is not total. Promising rankings the redesign cannot guarantee. And asking for "a redesign" with no scope, decision date or owner — making deferral the easiest answer.
FAQ
How do I calculate the ROI of a website redesign honestly?
Use your own baseline: sessions × conversion rate × close rate × contribution per customer gives current monthly contribution. Model an improvement as an explicit assumption, subtract added running costs, and divide total project cost by the monthly gain for payback. Show three cases, and label every unmeasured figure as an assumption.
What payback period should we expect from a redesign?
There is no standard figure, and anyone quoting one without your baseline is guessing. Calculate your break-even improvement instead — the uplift needed to repay the total cost inside a period your partners set, often 12 months. If it is small against a documented problem, the case is strong; if it demands heroic growth, ask for a smaller fix instead.
What evidence can I use if our analytics are unreliable?
Reconcile manually for four weeks: tally every form enquiry, call and WhatsApp message, record the source, and match them against sales outcomes weekly. Add Search Console data for organic landing pages and invoices for fixes. State the limits plainly — a short, honest baseline persuades better than a polished export nobody trusts.
Should the case include expected SEO or traffic gains?
Only as a separate, clearly labelled scenario — never blended into the conversion case. Traffic effects depend on migration quality and can dip before they recover. Keep the core case standing on conversion of traffic you already have; treat growth as upside.
How long should a website redesign business case be?
One page for the decision, with evidence in an appendix: the problem, baseline, cost of delay, total ask, break-even and three cases, risks and decision date. If a partner needs a forty-slide deck to say yes, the numbers are not yet doing their job.
Get an itemised proposal your partners can actually judge
Once your one page is drafted, the ask needs a real number. WebStackRank provides an itemised proposal within 24 business hours once the scope is clear, with 50% due to begin and 50% at launch. Bring your baseline, platform and partners' decision date, and start with our web design team in Dubai.