How to Write an Architecture Proposal That Wins the Project

Where proposals actually lose

A client with three proposals on the desk is not comparing architecture. They cannot, not yet. They are comparing three documents, and in most cases those documents open with the same paragraph about a collaborative, award-winning, client-focused practice.

When every proposal says the same thing in the first section, the only remaining difference is the number at the back. That is how firms end up competing on fee without ever deciding to.

The document does not win on design quality. It wins on evidence that you understood this specific project better than the other two firms did.

The six sections, in the order they are read

The structure below is not clever, and it should not be. A client circulating your document internally needs to find things where they expect them. Save your originality for what fills the sections.

The section that decides the shortlist

Section one is the only place in the document where you can prove something rather than assert it. Everything else can be claimed by anyone. Understanding cannot be faked, because it comes from having listened.

The test is simple and unforgiving. Read your understanding section and ask whether a competing firm could have written the same paragraph after the same meeting. If they could, it is not doing any work.

What belongs in it

• Their words, not yours. If they said the ground floor feels like a corridor, write that, not poor circulation legibility.
• The constraint they are most worried about. Name it plainly, early, and without softening it.
• The thing behind the brief. They asked for an extension. What they want is to stop leaving the house at seven to beat traffic, or to get two more staff into a building they cannot leave.
• What you noticed that they did not raise. One observation from the site or the documents is worth more than a page of methodology.

Here are my raw notes from a first meeting with a prospective client: [paste everything, including fragments and things they said twice].

Write the "Understanding of the Project" section of a proposal, 200 to 250 words.

Rules:
- Use their language wherever my notes captured their actual words. Quote them where it helps.
- Lead with the outcome they want, not the building they asked for.
- Name the constraint they seemed most worried about, in the first third.
- Include one thing they said that most firms would have skipped over.
- Do not describe our process, our practice, or our awards. This section is entirely about them.
- If my notes are too thin to write any of the above honestly, write [MISSING: what to go back and ask] instead of inventing it.

Scope creep is a writing problem first

Every scope dispute that ends in an awkward conversation started as a sentence that could be read two ways. The client read it their way, you read it yours, and neither of you noticed for four months.

Two mechanisms prevent almost all of it, and both belong in the proposal rather than in a later email.

1. Assumptions. Things you have taken as true in order to price the work. A survey provided by the client. A single round of consultation. An existing structure that is sound. State them, because each one is a fee conversation you are choosing to have now instead of later.
2. Exclusions. Work the client might reasonably assume is included but is not. Planning appeals. Interior specification. Attendance at more than a stated number of site meetings. Written firmly and warmly, these read as clarity rather than defensiveness.

The rewrite that helps most is turning every service into something the client can verify. Coordinate with consultants is not a deliverable. Issue a coordinated drawing set at the end of stage three, incorporating structural and services input, is.

Here is the scope of services for an architecture project: [paste your scope].

Project context: [type, procurement route, who else is appointed, anything unusual about the client].

Do four things:

1. Rewrite each line so it names a deliverable the client could verify, rather than an activity.
2. List every assumption hiding in the current wording that should be stated explicitly.
3. Draft an exclusions list of things a client on this project type commonly assumes is included but is not.
4. Flag the three lines most likely to be read differently by me and the client, and say how each could be misread.

Write the exclusions in a firm but friendly tone. Protective, not defensive.

When the client says the fee is too high

The instinct is to shave something off. Do not. A fee that moves under one question has told the client it will move again, and the next conversation starts from the lower number.

The move is translation, not reduction. The gap between your fee and a cheaper one is buying something. Say what.

• Seniority. Who actually does the work, and who they will be speaking to in month four.
• Inclusion. What is in your scope that the other firm has excluded, which will reappear as a variation.
• Risk removed. Approvals experience on this building type, in this authority. Cost certainty. Fewer surprises.
• One honest trade-off. Naming a genuine downside of choosing you makes everything else you said credible.

Then offer to walk the scope line by line rather than negotiate the number. It moves the conversation from price to value, and it is the offer that most often turns a lost bid into a second meeting.

What to reuse and what to rewrite

Boilerplate is not the enemy. Boilerplate in the wrong section is.

If you want the same treatment applied to the conversations that happen before the proposal exists, read how to start conversations with clients you have not met. For where this fits in the wider picture, see the practical guide to ChatGPT for architecture firms.