Web Design Proposal Template That Helps Close the Deal

A web design proposal has one job: let a business owner say yes without having to decode your process. The owner should be able to read it on a phone, see what problem you found, what you will deliver, what it costs, and what happens after they accept.

Most proposal templates fail because they were written to impress other designers. This one is built for selling fixed-scope websites to local businesses, where the buyer cares about phone calls, bookings, and quotes, not about your stack.

Quick answer

A good web design proposal template has eight sections, in this order:

1. The client's problem, stated in one or two verified sentences.
2. The outcome the new site will produce for their customers.
3. The deliverables, with explicit exclusions.
4. What the client must supply, and by when.
5. The review, revision, and approval process.
6. The price and payment schedule.
7. Ownership of the domain, hosting, accounts, and content.
8. The offer expiry date and how to accept.

Keep it short. If a section does not help the owner make a decision, cut it. Everything else you want to say belongs in the conversation, not the document.

Why most web design proposals lose deals

The losing proposal is rarely too expensive. It is usually one of these:

• It leads with the designer's process instead of the client's problem.
• It lists features without saying what the client must decide or supply.
• It hides the approval process, so the owner cannot tell what "yes" starts.
• It bundles vague ongoing obligations into a number, so the price is impossible to compare.
• It has no expiry date, so the owner files it and forgets it.

A proposal is a decision document. Structure it so the owner can check each section against what you discussed on the call and find no surprises.

The template, section by section

Copy this structure into your own document and adapt the bracketed text. The wording below is deliberately plain; local business owners do not buy from documents full of agency vocabulary.

1. The problem

One or two sentences, factual and verified during your audit. Not a pitch.

Your current page makes the quote request hard to find on a phone, and the service area is not stated. Customers outside your referral network have no simple way to check that you cover their town and ask for a price.

If you cannot write this sentence from evidence, stop and finish the audit first. The website audit checklist covers how to document findings so this section writes itself.

2. The outcome

One short paragraph describing what changes for the client's customers. Name the action, not the technology.

The new site will let a homeowner on a phone understand your services, confirm you cover their area, and request a quote in under a minute. Your phone number and enquiry form will work from every page.

3. Deliverables and exclusions

List exactly what the client gets. Then list what is not included. The exclusions section is not pessimism; it is what keeps the project from growing into unpaid work.

Included:

• A one-page website covering [service summary], [service area], [opening hours], and [contact action]
• Mobile-first layout, tested on current phones and browsers
• Contact or quote form delivered to [address the client confirms]
• Connection of [domain] from the client's own account
• Launch checks: HTTPS, form delivery, phone links, page metadata
• Two revision rounds as defined below

Not included:

• Copywriting beyond restructuring the text the client supplies
• Photography, logo design, or brand work
• Booking, payment, or third-party integrations
• Blog, news, or multilingual content
• Ongoing updates after launch, which are covered by the optional care plan

4. What the client supplies

Projects stall on missing inputs more often than on design decisions. List everything you need and tie each item to a date.

• Confirmed business details: name, address, phone, hours, service area
• Services to feature, and any to leave out
• Logo and usable photos, or written permission for existing ones
• Access to the domain account, or a decision to register a new domain
• One named approver for all feedback and the final sign-off

State plainly that the schedule moves if these arrive late. It is easier to say in a template than in an awkward email later.

5. Review, revisions, and approval

Define a revision round as one consolidated list of changes from the named approver. This single definition prevents the most common scope dispute in small web projects.

A workable process:

1. You deliver the first version for review.
2. The approver returns one consolidated change list within an agreed window.
3. You apply it and deliver the second version.
4. A second round works the same way.
5. The approver confirms the site in writing before anything goes live.

Nothing publishes until the client approves names, services, locations, prices, images, contact details, and any claims that appear on the site.

6. Price and payment schedule

Give one fixed price for the defined scope, and state what it does not cover. Show the payment stages.

The price for the scope above is [$X]. 50% is due on acceptance, and 50% on approval, before the site goes live. Work outside the listed scope is quoted separately before it starts.

Offer the care plan as a separate line with its own price, so the project price stays comparable. Hosting, monitoring, and a defined allowance of content changes is a product; "maintenance" is a promise nobody can price.

7. Ownership

Name who owns what after launch. Disputes here destroy referrals.

• The domain stays in the client's account, registered to the client.
• The hosting account and site belong to the client.
• Logins and account details are handed over at launch.
• You may show the finished site in your portfolio unless the client objects in writing.

8. Expiry and acceptance

End with a date and an action.

This offer is valid until [date, typically 14 to 30 days out]. To accept, reply to this email confirming the scope and I will send the first invoice and the kickoff checklist.

The expiry date is not pressure. It protects the client from a price that no longer reflects your calendar, and it gives you a natural reason to follow up.

Adapting the template to different projects

The structure stays the same; only the scope section changes.

• No-website client: the problem section describes the missing owned presence and the customer action that currently requires a social account or a phone call. Deliverables emphasize business-information accuracy.
• Redesign client: the problem section cites specific audited findings, such as a broken mobile quote path or conflicting opening hours. Add a line about preserving or redirecting existing pages so the rebuild does not strand URLs that already get traffic.
• Care plan proposal: treat it as its own document with its own scope, response times, and allowance. Never hide recurring work inside a one-time build price.

The full sales process around the proposal, from first contact through the discovery call and invoicing, is covered in how to sell websites to local businesses.

Proposal mistakes that cost you the deal

Sending the proposal before the discovery call

A proposal written before you know the approver, the budget signal, and the real problem is a guess with a price on it. Use the call to confirm facts and fit, then write the document to match what was agreed.

Pricing options without a recommendation

Three packages with no guidance makes the owner do your job. If you show options, mark the one that fits the problem you audited and say why.

Quoting hourly for a fixed deliverable

An hourly estimate tells the owner the price is unknowable. For a defined local-business site, quote a fixed price and control risk through the scope, revision limits, and exclusions.

Letting the proposal and the invoice disagree

If the accepted scope says one thing and the invoice says another, you have created a dispute at the exact moment the client is happiest. Generate the invoice from the accepted offer, or at minimum copy the scope, price, and payment stages word for word.

Skipping the ownership section

"We will sort the domain out later" becomes an emergency at launch. The template's ownership section is three sentences; write them before you need them.

From accepted proposal to invoice

The proposal's job ends at acceptance. What follows should be mechanical: the kickoff checklist goes out, the first invoice matches the payment schedule, and the project starts against the agreed scope.

Keep the chain in as few tools as you can. A workspace that holds the lead, the preview, the approved scope, and the invoice in one place removes the copy-paste errors that happen between a document editor, a spreadsheet, and accounting software.

Opportunora is built around that chain: it finds source-backed local opportunities, generates a reviewable site, publishes only when the operator approves, and creates the invoice from the won deal. The product walkthrough shows how the steps connect, and the pricing section explains how the plans work. If you want to run your pipeline this way, you can start a free trial.

Frequently asked questions

How long should a web design proposal be?

Long enough that the owner can check every decision without calling you, and no longer. For a fixed-scope local business site, one to two pages usually covers all eight sections. Length does not signal thoroughness; unresolved questions do.

Should I send the proposal as a PDF or a web page?

Use whatever the client can open, read on a phone, and reply to. A simple PDF or a plain email with the sections above both work. Avoid formats that need an account, an app, or a desktop to read comfortably.

Do I need a proposal for a very small job?

Yes, but it can shrink. For a small fixed job, the problem, deliverables, price, payment, and acceptance lines can fit in one email. What you cannot skip is the written record of scope and price, because that is what the invoice and the revision boundaries refer back to.

What if the client asks for changes to the proposal?

Change the document, not the deal in your head. If they want a lower price, remove scope and reissue the proposal with the new deliverables and exclusions. A revised written version beats a thread of emails that contradict the original.

When should I follow up on a proposal I sent?

Mention the expiry date when you send it, then follow up once partway through the window with a short note offering to answer questions. The expiry gives the follow-up a reason that is about the client's timeline, not your pipeline.