When asking a manager to replace the website, one page is enough: open with the decision you need, then cover the current state, the cost of waiting, three options plus a recommendation, budget and timeline, risk controls, and the next step. “It looks dated” rarely wins approval. Quantify lost inquiries or extra staff hours each month so the choice is easier to make.
IT and marketing contacts often stall at the same point: they handle site problems every day and know a refresh is due, yet the boss only sees a new expense. The proposal should turn daily friction into choices a manager can decide. A fill-in structure follows.
Decision criteria, not website jargon
A manager does not need responsive layout, content systems, or server versions. They only need to judge whether this is worth doing now. Before you send it, be ready to answer these five questions:
- Why now? What happens if you wait, and is there a deadline?
- How large is the problem? Can it be stated in counts, hours, or money?
- What are the choices? Besides a full rebuild, is there a smaller path?
- What will it cost, and how long? Are post-launch fees included?
- What if it goes wrong? How will you control overruns, delays, or vendor lock-in?
The last question is often skipped. For a manager, risk is not only the fee. It also includes an unfinished project, a blown budget, or being stuck with the vendor afterward. If the proposal does not answer this first, the reply is usually to revisit it later.
Collect five kinds of evidence first
You do not need a pile of proof. Three solid categories are enough. Most of it already sits inside the company and can be gathered in half a day to a day.
| Evidence type | Where to find it | How to write it |
|---|---|---|
| Traffic and devices | GA4, Search Console | Over the past year, mobile visitors were [X]%, with only [Y] mobile inquiries |
| Inquiries and sales | Sales records, forms, chat logs | About [X] customers call each month for information missing from the site |
| Internal hours | Colleague estimates, vendor invoices | Updating one product record takes [X] hours, about [Y] hours a year |
| Risk and expiry | Hosting contract, vendor notices | The hosting contract ends on [date], and security updates have stopped |
| Customers and peers | Customer feedback, peer sites | In the past six months, [X] customers could not order on mobile |
Convert staff time like this: hours per task × times per year × hourly cost, then add yearly vendor change fees. The figure need not be exact to the last digit, but show how you estimated it. Managers accept estimates. They do not accept numbers with no source.
If the data is missing, say plainly that it cannot be tracked yet. Not knowing where inquiries come from is itself a reason to act.
A one-page template you can fill in
Paste the table below into your document and replace the brackets with your company’s facts. Put the conclusion in the first row so a manager who reads only that row still knows what to decide.
| Section | What to fill in |
|---|---|
| Decision requested | Recommend updating the site by [month/year]. Please approve [option], a budget cap of [amount], and reply by [date] |
| Current state | The current site launched in [year]. Over the past 12 months: [the 2–3 most important numbers] |
| Cost of waiting | About [hours or money] lost each year; after [expiry or risk event], [specific impact] may follow |
| Option comparison | A small fix: [cost / scope]; B partial redesign: [cost / scope]; C full rebuild: [cost / scope] |
| Recommendation | Recommend option [X]. Give at most three reasons, each tied to a problem above |
| Budget and timeline | Build [amount], yearly maintenance [amount], internal effort [person-days]; vendor schedule [start–end month] |
| Risk control | Pay in stages against acceptance; keep the domain and accounts in the company name; state delivery scope and usage rights in the contract |
| Result tracking | Track [2–3 indicators], baseline [numbers], and report at 3 and 6 months after launch |
| Next step | After approval, confirm the vendor by [date], owned by [name]; attach quotes, a site map, and the data |
Follow three rules while you fill it in:
- State the requested decision in the first line: put background later so the point is not buried at the end.
- Each option must give something up: a choice with no downside looks like you are only trying to sell it.
- Recommend one option: you know the situation best. Listing choices alone hands the judgment back.
If you still need materials from vendors, list the questions you would ask in a pitch review first. Delivery scope and usage rights can then be written more precisely.
Compare three options, not one answer
With only one option, the manager can only say yes or no. Three options shift the talk toward which one fits. A common comparison looks like this:
| Item | A. Keep the site, small fixes | B. Partial redesign | C. Full rebuild |
|---|---|---|---|
| Upfront cost | ✓ Lowest spend | ! Mid-range | ✗ Highest spend |
| Mobile experience | ! Depends on the current site | ✓ Can be fixed | ✓ Can be fixed |
| Admin and workflow | ✗ Usually not | ! Only in part | ✓ Can be fixed |
| Legacy system and security | ✗ Cannot fix the root cause | ! Depends on the old system | ✓ Can be fixed |
| Internal effort | ✓ Lower effort | ! Moderate effort | ✗ Higher effort |
| Best fit | Problems sit on a few pages | The system still works; the issue is experience | The system is obsolete, or needs have clearly changed |
First check whether the old system can still receive security updates, and whether the admin tools still match how work is done now. If both are fine, a full rebuild is usually unnecessary. Start with a small fix or a partial redesign. If updates have stopped, or every content change needs an engineer, small fixes mostly postpone the problem.
Estimate cost with a redesign-budget method, then collect written quotes from at least two vendors. A typical company site often lands between 50,000 and 200,000, and membership, payments, or integrations push it higher. Use real quotes in the proposal, not market ranges alone.
Six common objections and ready replies
Pushback is usually a risk check. Prepare evidence instead of improvising in the room.
| What a manager may say | Suggested reply | Evidence to bring |
|---|---|---|
| “It still opens. Why replace it?” | The pages still load, but they cost [X] extra hours a year, and [risk] remains | Hour estimate, expiry date |
| “Why is it this expensive?” | Among the three options, this scope fits the need best; if the budget must drop, look at [option A] | Option comparison, quotes |
| “Can a template or AI do it?” | A brochure site could be considered, but we need [membership, quotes, or integrations], and both paths were compared | Feature needs, platform limits |
| “How much will sales rise?” | A multiple cannot be promised, but we will track [indicators] and report at months 3 and 6 | Current baseline |
| “Will we be locked to a vendor again?” | The contract will state delivery scope and usage rights, with the domain and accounts in the company name | Contract terms |
| “We are busy. Later.” | A decision by [date] is needed to meet [event]; if it is not urgent, start with phase one | Timeline and phase-one scope |
The question about how much revenue will grow needs the most care. Do not promise a top search ranking or doubled sales just to get approval. After launch, that sentence will follow you. For how to measure results, set indicators with a return-on-investment review.
Vendor lock-in depends on the contract. Ask each vendor to state ownership, the usage rights you receive after payment, whether you may edit the site or hire another firm to maintain it, and whether the full source code will be delivered. When you compare vendors, require those points in writing.
Four reasons a proposal gets rejected
One: the case rests only on appearance. Looks are subjective, and a single “it still seems acceptable” can shut the discussion down. Lead with lost inquiries, wasted hours, and upcoming risk. Put visual taste later.
Two: you forward the vendor’s deck as-is. A vendor document says what that firm can build. The manager wants to know why the company needs it. Write a one-page summary yourself and attach the vendor file.
Three: you count only the build fee. Maintenance and content-production costs that appear later make the next proposal harder. List those costs at the start.
Four: there is no next step. Even if the manager agrees, the project stalls if no one knows what to approve or who owns it. End with the date, the owner, and the items that need approval.
Preview it verbally for five minutes
Book five minutes first. Say the conclusion and the decision you need, then hand over the document. If the manager already knows the topic, the email is less likely to be forgotten.
If finance or sales leaders will influence the outcome, ask them privately what cost or process issues they care about, and include those points. When more people must align, map the order in which stakeholders should be briefed.
A delayed yes is still useful. Find out whether the block is budget, timing, or expected benefit, then adjust the option or shrink phase one. Keep a rejected draft. New numbers or a contract expiry date let you update it later.
Show choices, not an invoice
A website-refresh proposal works when everyday problems become decisions someone can make. Keep these three points in mind:
- Open with the decision you need: even a glance at the start should show the option, the budget, and the reply date.
- Explain the cost with hours, inquiries, and expiry dates: that is easier to discuss than “the site is old.”
- Bring three options, but recommend one: also state the budget, the risks, and how results will be tracked.
For the broader sequence and cost structure of a redesign, review a full process guide separately. If you already have quotes and a site map, this template is much easier to complete.
