How to write a website proposal that gets approved

To write a website proposal that gets approved, confirm the client's goal and budget before you write anything, scope the work in plain language, price it in a few visible line items, and send it within 48 hours of the discovery call with a single clear way to accept. Most proposals fail before they are opened, because they arrive late or answer a question the client did not ask.

This article covers the process from the first call to the signed proposal, with the specific questions, wording and follow-up timing that work for freelancers and small agencies.

Run a short discovery call first

Never send a website proposal from an email brief alone. A 30-minute call saves hours of rewriting and tells you whether the project is worth proposing at all.

Ask these five questions:

1. What should the new site do that the current one does not? Look for a business outcome, such as more bookings or fewer support emails.
2. Who will use it most, and on which device?
3. What content already exists, and who will write the rest?
4. When do you need it live, and why that date?
5. What budget range have you set aside?

The budget question feels awkward, but it is the most useful one. If the client says $3,000 and your smallest realistic scope is $8,000, you have learned that in five minutes instead of after two days of writing. If they will not give a number, offer ranges: "Projects like this usually land between $6,000 and $12,000. Where in that range are you comfortable?"

Scope in the client's words

Open the proposal by restating the goal in one or two sentences using the client's own phrasing from the call. This shows you listened, and it gives the client something to agree with immediately.

Then describe the work in concrete units. "Up to eight page templates" is better than "a full website". "Two design concepts and one revision round" is better than "design until you are happy". Every vague phrase is a future argument.

Be explicit about what is not included. If you do not write copy, say so. If hosting is the client's responsibility, say so. A short "not included" list does more to prevent scope creep than any contract clause, because the client reads it before signing.

Price so the client can see the logic

A single lump sum invites haggling because the client cannot see what they are paying for. A long itemised list with twenty rows invites them to cut items. Three to six line items is the range that works.

Group work into phases the client understands, such as discovery, design, build and launch. Add one or two optional extras, clearly marked, that the client can include if they want. This gives the client control without reopening the core scope. If you are unsure whether to call the document a proposal, a quote or an estimate, read proposal vs quote vs estimate first, because the answer changes how firm your numbers should be.

State the payment split next to the total, not on a separate page. "50% to start, 50% at launch" removes a question the client would otherwise have to ask.

Send fast and make acceptance easy

Speed matters more than polish. A proposal sent the day after the call, while the client is still excited, is approved far more often than a perfect one sent a week later. Aim for 48 hours at most.

Send a link rather than an attachment when you can. A link opens on the client's phone, always shows the latest version, and lets you see when it was viewed. End the proposal with one action: type your name and accept. Every extra step, such as printing, signing, scanning and emailing back, loses some clients.

Follow up on a schedule

Most approvals that do not happen in the first two days need a nudge. A simple schedule:

• Day 2 after viewing: ask if they have any questions about scope or timing.
• Day 5: offer a short call to walk through it.
• Day 10: ask directly whether the project is still a priority this quarter.

Keep each message to two or three sentences. If you can see the proposal has not been opened, resend the link rather than asking whether they had a chance to look.

An example from start to signature

A small agency had a discovery call with a dental clinic on a Monday. The clinic wanted online booking and said their budget was "around ten thousand". The agency sent the proposal on Tuesday afternoon.

Scope: six page templates, booking integration with the clinic's existing system, content migration, launch and training.

Pricing:

• Discovery and sitemap: $1,500
• Design: $3,000
• Build and booking integration: $4,500
• Optional: copywriting for service pages, $1,200
• Optional: three months of maintenance, $600

Base total: $9,000, inside the stated budget. The clinic viewed it the same evening, asked one question about the booking system on Wednesday, and accepted on Thursday with the maintenance add-on, for a total of $9,600. From call to signature took three days. The agency's previous proposals, sent as PDFs a week after the call, averaged eighteen days.

Common reasons proposals get rejected

The most frequent are a price far outside the budget, scope that does not match what was discussed, and a proposal that took too long to arrive. Less obvious is a document that is hard to read on a phone: many decision makers first open it between meetings.

If a proposal is rejected, ask why in one sentence. The answer improves the next one more than any template.

Write less, send sooner

The structure above fits on two or three screens. ProposalKit gives you that structure as a ready-made website proposal, with optional add-ons the client can toggle and typed-name acceptance on a link that works on any phone. Start from one of the web project templates or sign up free.