A board-ready business case for a new website: conversion, efficiency, risk and the cost of delay

“Our website is dated” may be true. It is rarely an investment case.

A board or executive team needs to understand what has changed, why the current position matters, which outcomes the organisation expects, what alternatives were considered, what the full commitment will be and who will remain accountable after launch.

That requires a different conversation from a website brief. A brief records known requirements and constraints for an agency. A business case explains why the organisation should invest at all.

The strongest cases do not promise that a new interface will magically produce revenue. They connect a verified problem to a chain of changes: improved journeys, clearer content, better data, reduced manual work, stronger governance, accessible experiences, reliable integrations, safer technology and measurable commercial outcomes. They also expose the dependencies that sit outside the website, including sales follow-up, content ownership, process change and adoption.

The Victorian Department of Treasury and Finance frames a business case around four fundamental questions: what is the problem or service need, what benefits will result from addressing it, whether there is a compelling case to invest, and whether the project can be delivered as planned. Its current business case guidance is written for government investment, but the logic is equally useful for a corporate website decision.

The short answer

A board-ready website business case should contain:

A one-page decision request.
An evidenced problem and consequence of maintaining the current state.
Strategic alignment and affected stakeholder groups.
Measurable benefits across growth, service, efficiency, risk and capability.
A credible baseline, target, owner, timing and confidence level for each major benefit.
Genuine options, including improving the current site and staging investment.
Whole-of-life cost rather than only the build fee.
Delivery, operational and change risks with mitigations.
Governance, decision rights and benefits realisation after launch.
A clear next approval, which may be paid Discovery rather than full implementation.

If consequential scope, technology, data, integrations or governance remain unresolved, the responsible request may be approval for Discovery and an indicative programme envelope, not approval for a falsely precise fixed implementation.

Start with the decision the board is being asked to make

Do not make directors search through 40 slides to find the request. State it at the beginning.

The decision summary should explain:

What approval is requested now.
What business problem the approval addresses.
What outcome and timeframe are proposed.
The recommended option and why it is preferred.
The investment basis and important exclusions.
The main risks and dependencies.
Which later decisions are not yet being requested.

For example, an organisation may ask the board to approve paid Discovery to define a multi-market website and customer portal, with implementation subject to a later decision. Another may have a sufficiently defined corporate website and ask for implementation approval immediately. The approval should match the maturity of the evidence.

Define the problem without prescribing the solution

“We need a new website” is a solution statement. Reframe it.

A better problem statement might be:

Prospective customers cannot confidently identify the right service, contributing to low-quality enquiries and avoidable sales effort.
Content is duplicated across brands and markets, creating inconsistent claims and expensive updates.
Customers must call staff to complete routine tasks that could be handled securely online.
The platform cannot support required integrations, permissions, accessibility or publishing governance.
The technology is difficult to maintain and creates unacceptable continuity or security exposure.
Marketing cannot connect website activity to qualified pipeline, limiting investment decisions.

Support the problem with evidence. Useful sources include analytics, search data, CRM outcomes, contact-centre reasons, task completion, usability research, content audits, publishing effort, support records, accessibility findings, incident history and platform constraints.

Separate evidence from interpretation. “Forty per cent of service calls concern document status” is evidence if the sample and period are reliable. “A portal will remove all those calls” is a hypothesis that depends on adoption, process and feature design.

The Victorian Government’s Investment Management Standard deliberately separates problem, benefit, response and solution. That sequence prevents an attractive asset from being presented as the only possible answer before the investment need is understood.

Establish the counterfactual: what happens if nothing changes?

The alternative is rarely “do nothing at zero cost”. Keeping the current website has costs, risks and constraints.

Document the base case over the same period used for the proposed investment:

Existing licences, hosting and support contracts.
Manual administration and duplicated publishing.
Cost of recurring defects and workarounds.
Lost or poorly qualified demand where evidence exists.
Content, accessibility, privacy and security remediation.
Staff training on ageing or fragmented tools.
Upcoming end-of-support or vendor changes.
Delayed campaigns, launches or market expansion.
Expected growth in volume that the current process must absorb.

Avoid inflated “cost of inaction” totals. Some costs will continue under any option. Others are opportunity costs rather than cash savings. Label them clearly.

Build the value case across five benefit families

A website can create value in more ways than conversion rate. Use the categories that fit the organisation and avoid counting the same benefit twice.

1. Growth and conversion

Potential measures include qualified enquiries, appointment completion, online sales, average order value, repeat purchases, application completion and revenue influenced by digital journeys.

Build from the commercial funnel:

Eligible sessions × conversion rate × qualified rate × close rate × average contribution

Use contribution or another finance-approved measure where revenue would overstate the value. Apply low, central and high assumptions. Identify which inputs are observed and which are hypotheses.

2. Service and customer outcomes

Measures might include task completion, time to complete, avoidable contact, application errors, support satisfaction, complaint reasons and access to information. These benefits matter even when no immediate sale occurs.

3. Operational efficiency

Look for manual re-entry, duplicate content updates, spreadsheet reconciliation, repeated approvals, staff-assisted transactions, report assembly and defect handling. Convert time to money only where the organisation can realistically reduce cost, redeploy capacity or absorb growth without adding resources.

If a new website saves 20 hours per week but nobody owns the process change, the financial benefit may not materialise.

4. Risk reduction

Relevant categories can include security, privacy, accessibility, unsupported technology, inaccurate content, brand inconsistency, resilience, auditability and dependence on a single person or supplier.

Do not convert every risk into a dramatic expected loss. Show likelihood, consequence, current control, proposed control and residual exposure. Some risk benefits are best presented as qualitative or as avoided remediation rather than speculative financial return.

W3C’s business case for digital accessibility explicitly considers tangible and intangible benefits as well as risk. Accessibility should be treated as a user and quality requirement, not only a compliance line.

5. Strategic capability

A modular content model, shared design system, reliable data layer, customer identity or integration capability can enable new brands, markets, campaigns and services. These are real benefits, but only count value that has a plausible roadmap and owner. “Future proof” is not a measurable outcome.

Give every major benefit an owner and evidence profile

The Australian Government’s current Benefits Management Policy guidance says benefits activities should be proportionate and that each benefit should have a single owner. Its standard calls for baselines, data sources, calculation methods, targets, dates, confidence levels, tolerances, assumptions, constraints and dependencies.

Apply that discipline to the most valuable website outcomes.

For each major benefit, record:

Field	Question
Outcome	What improves for the organisation or user?
Measure	What observable indicator will show progress?
Baseline	What is the current value and period?
Target	What change is expected, by when?
Source	Which system or research method supplies the data?
Owner	Who can make the business changes required?
Dependencies	What else must happen beyond website delivery?
Confidence	How reliable are the baseline and forecast?
Tolerance	What range would still justify the investment?

Do not create dozens of vanity measures. Focus on the small group that explains most of the value.

Compare genuine options, not three versions of the same recommendation

A credible board paper should show that the organisation considered alternatives.

Option 1: maintain and remediate

Keep the current platform and address priority defects, content, performance, accessibility or conversion issues. This can be appropriate when the foundation remains viable and the problem is narrower than a rebuild.

Option 2: focused replacement

Replace the public website within a controlled scope, preserving or simplifying surrounding systems. This may suit a clear corporate or lead-generation requirement.

Option 3: phased platform transformation

Create a shared foundation and release capability in stages, such as the public site first, then portal, ecommerce, integrations or additional markets. This can reduce simultaneous change but requires architecture that anticipates later phases without pretending they are already defined.

Option 4: broader transformation

Address website, data, CRM, content operations and service redesign as one programme. This may create greater value and greater delivery risk.

Score options against the problem, benefits, cost, time, risk, dependencies, internal capacity and reversibility. Do not assign weights after seeing which option wins.

An option can be strategically attractive but currently undeliverable. The recommendation should acknowledge that.

Calculate whole-of-life investment

The implementation proposal is only part of the cost.

Include, where applicable:

Discovery, research and requirements definition.
UX, content, design and development.
Data, integration and migration work.
Accessibility, security, privacy and technical assurance.
Internal staff time and subject-matter contribution.
Content creation, photography, video and document remediation.
Platform, software and third-party licences.
Hosting contracted directly with the relevant provider.
Training, change, rollout and communication.
Support, maintenance and continuous improvement.
Contingency appropriate to uncertainty.
Decommissioning of old platforms and contracts.

Show one-off and recurring costs separately. Use a consistent evaluation period and finance-approved discounting if calculating net present value. State whether GST is included.

Emote does not sell or resell hosting infrastructure. It can advise on hosting requirements and coordinate with a suitable hosting partner, but the client normally contracts and pays the host directly. A business case should show that as a separate third-party responsibility.

Treat the cost of delay carefully

Cost of delay can help sequence investment, but it is easy to abuse.

Estimate the value lost or cost incurred for each period of postponement only where there is a defensible link. Examples include:

A campaign or product launch that cannot use the current platform.
Continued manual processing that has a measured cost.
A contract renewal that locks in another period of legacy expense.
A capacity constraint that requires hiring if self-service is delayed.
A known security or support deadline.
A forecast conversion improvement applied to an evidence-based funnel.

Separate time-sensitive cost from general annual benefit. If an outcome will take six months after launch to emerge, do not count the full annual value from day one. Show ramp-up.

A simple presentation can use three scenarios:

Low: only highly evidenced benefits, slower adoption.
Central: most probable assumptions and planned adoption.
High: favourable but still plausible performance.

The board should see which assumptions change the decision and which do not.

Show why the benefits will actually happen

A new website is an output. Benefits require business change.

Map the chain:

Delivery output → user or staff behaviour change → operational outcome → strategic benefit

For example:

Customer portal status view → customers self-serve → fewer status calls → service team absorbs growth without additional headcount

The chain exposes dependencies: accurate backend status, customer adoption, accessible authentication, call-reason measurement, team process and ongoing product ownership. If any link is missing, the benefit is at risk.

The Australian Government Benefits Management glossary defines benefit dependencies as enabling outputs and business changes on which realisation depends. This is a valuable discipline for commercial projects as well.

Demonstrate delivery confidence

Boards do not approve theoretical value alone. They approve the organisation’s ability to deliver and operate the change.

Address:

Executive sponsor and accountable project owner.
Product, content, technical and benefits owners.
Decision rights and escalation.
Internal capacity and subject-matter availability.
Procurement and contract pathway.
Scope, assumptions and change control.
Data and integration ownership.
Security, privacy, accessibility and legal assurance.
Content and migration readiness.
Release, rollback and business continuity.
Training, adoption, support and post-launch optimisation.

State the confidence level honestly. A large portal with unresolved identity, data and integrations should not carry the same estimate confidence as a well-defined corporate website.

Use paid Discovery to earn implementation confidence

Discovery is appropriate when the business case supports investment in the problem but the implementation cannot yet be responsibly defined.

It can resolve:

Audience and service journeys.
Functional scope and release boundaries.
Platform and architecture options.
Integrations, data ownership and failure handling.
Identity, roles and permissions.
Content model, migration and governance.
Security, privacy and accessibility requirements.
Delivery plan, dependencies and refined investment.

Discovery may recommend a simpler solution, a phased programme, improvement of the current website or not proceeding with the original concept. That is useful investment control, not failure.

The board paper should state what Discovery will decide, who must participate and which later approval it enables. Do not describe Discovery as a way to defer every decision or as implementation under another name.

Present the case in layers

Directors need a concise decision surface and access to evidence.

One-page decision summary

Include the request, problem, recommended option, investment, headline benefits, key risks, timing and next gate.

Core paper

Explain evidence, options, value, total cost, delivery approach, governance and recommendation.

Appendices

Provide the benefit profiles, assumptions, research, analytics baseline, risk register, option scoring, indicative architecture and procurement material.

Keep marketing language out of the financial model. Label agency estimates, internal assumptions and independently verified data. Record version and approval status.

What to measure after approval

Measurement begins before the rebuild. Preserve a baseline and maintain definitions across launch.

Use leading and lagging indicators:

Delivery: milestones, scope, defects, content readiness and risk.
Adoption: users reaching and using the new journeys.
Experience: completion, error, time, accessibility and feedback.
Operations: contacts, handling time, publishing effort and reconciliation.
Commercial: qualified leads, sales, value and retention where attributable.
Risk: incidents, audit findings, unsupported components and control performance.

Assign reporting cadence and decision thresholds. If a benefit underperforms, the response might be journey optimisation, process change, training or revised assumptions. It should not automatically become another redesign.

Frequently asked questions

Does a website business case need a financial ROI?

Not every benefit can or should be converted to dollars. Quantify defensible growth and efficiency benefits, then present service, risk and strategic capability with appropriate measures. Show the full decision, not a fabricated single number.

How do we forecast conversion improvement before design?

Use baseline funnel data, relevant evidence and scenario ranges. Make assumptions visible and apply a ramp-up period. Do not present a benchmark from another business as a guaranteed result.

Should the board approve Discovery or the full project?

Approve the decision that the evidence can support. If scope, architecture, integrations or governance remain consequentially uncertain, Discovery may be the correct first approval.

What is the difference between a website brief and a business case?

A business case justifies the investment and preferred response. A website brief records known context and requirements for qualification or proposal preparation. Discovery resolves important unknowns.

How many options should we compare?

Enough to demonstrate a genuine choice, commonly maintain and remediate, focused replacement, phased transformation and broader transformation. Remove options that are not credible and explain why.

What period should the model cover?

Use the organisation’s finance and investment policy. Include implementation and a realistic operating period, with recurring costs, adoption timing and any replacement or decommissioning costs treated consistently.

Who should own website benefits?

The person able to deliver the required business change, not automatically the project manager or agency. Major benefits may sit with marketing, sales, service, operations or technology.

Does launch complete the investment?

No. Launch creates the asset. Benefits emerge through adoption, content, process change, measurement, support and optimisation over time.

How Emote can help

Emote helps organisations turn a website requirement into a credible digital pathway across research, UX, content, design, development, integrations, migration and measurement. The team can work from an approved business case or help translate a defined investment objective into the appropriate website brief and delivery scope.

If the next approval depends on unresolved scope, the guide to website briefs versus paid Discovery explains how to choose the right next gate.

Have a website investment case to shape? Book a meeting with Emote to discuss the evidence and pathway.