A proposal structure that gets signed

The proposal that gets signed is rarely the best written one. It is the one that lets several different people find the part they care about, agree with it, and pass it along without calling a meeting. Structure decides that, and structure is the thing most proposals neglect while the prose gets polished.

So the answer here is mechanical rather than creative. Put the decision on the first page. Itemise the deliverables and map the price against them line by line. Write the assumptions and exclusions where a lawyer will look for them. Move everything about your company to the back.

That order is not arbitrary. The Business Development Bank of Canada's guidance on writing an effective business proposal lists what a proposal has to define: the problem or opportunity, the proposed solution, why you are suited to solve it, how it will be executed, the costs, why the client benefits, and background on your business. Notice where the background sits in that list. It is last, and it is the section most proposals lead with.

The same guidance makes a point that reorders everything else. In practice a chief executive does not decide alone. They are informed by finance, technology and legal colleagues, and by whoever has to run the thing afterwards. A proposal written for one reader gets read by several, and the ones you did not write for are usually the ones who stall it.

Write for the reader map rather than for the person who invited you to propose. Each of these people opens the document somewhere different, and each of them can stop it.

The last row is the one that should change how you write. Most proposals are built to be presented. The proposal that gets signed is built to be forwarded, because the meeting where you present it is almost never the meeting where the decision is made.

Test for that directly before it goes out. Hand the document to someone who was not on the call and ask what is being bought, for how much, and by when. If they cannot answer all three inside a minute, the structure is wrong, and rewriting the opening paragraph will not fix it.

None of this requires you to know the client's approval process. It only requires you to assume there is one.

Page one is a summary of the decision, not an introduction to your company. What is being proposed, what it costs, why now, how long it takes, and what is different when it is finished.

BDC is blunt about why that page exists: a one-page executive summary lets the final decision maker read that page alone, trust that their team has been through the rest, and sign. Write it last, and write it as though it is the only page that will be read, because for at least one of your four readers it is.

Two things belong on it that usually get buried. The total price, stated in a sentence, and the date the work can start. A summary that withholds the number in order to build up to it is a summary that gets skipped by someone hunting for the number.

Then restate the client's problem in their own words before you describe your solution. Not a paraphrase of your service page. The sentences they actually used on the call. It is the cheapest credibility available in the whole document, and it is the section most often pasted from a template.

Read this as an order, not a checklist. Almost every section here appears in most proposals somewhere. The sequence is what differs, and the sequence is what decides whether the document arrives intact or gets summarised badly by someone else.

The fourth row is the one worth arguing about internally. Price mapped to deliverables means you can remove a line under pressure instead of moving the total, and those are completely different trades. Removing scope holds your effective rate. Moving the total does not, and the arithmetic on it is worse than most people guess, which is the whole subject of what a ten percent discount actually costs.

Two rows go missing more often than the rest: dependencies and acceptance. Both write down an obligation the client is taking on, and both feel awkward in a document you are using to win work. They are also the two that decide whether the project is deliverable at the price you quoted.

Three rules, and they compound.

Itemise. A total is a number to negotiate. A list of priced deliverables is a conversation about which ones the client actually needs, and that is frequently fewer than you proposed.

Offer options, and no more than three. Two is a comparison, three is a choice, and five is a request that the buyer do your scoping for you. Each option should differ in what is included rather than in how fast you will do the same work, because a speed option prices your urgency instead of their outcome.

Date the price, and say what it is conditional on. Your cost inputs move: salaries, licences, subcontractor rates and the general price level. The Bank of Canada aims to keep inflation at the 2 per cent midpoint of a 1 to 3 per cent control target range, measured as the year-over-year change in total consumer price index. That is not permission to add a number to your quote. It is the reason a quote left open for six months has quietly become a different quote by the time somebody signs it.

What none of this needs is a benchmark. There is no correct percentage to price at, no standard number of options, and no market rate you have to sit inside. The figure comes out of your own cost, your own utilisation and the margin you decided you need, which is the derivation behind a rate card you can defend. The proposal is where that number gets presented. It is not where it gets invented.

State payment terms in the proposal rather than saving them for the first invoice. Terms introduced after a yes are experienced as a new condition. Terms in the proposal are just terms, and they get negotiated once, at the point where you still have leverage.

Every proposal is priced on a set of beliefs about the client's environment. Access will be granted in the first week. The existing tracking is roughly as described. There is one round of review, not four. Those beliefs are load bearing, and they are usually unwritten.

Write them down, and put the consequence beside each one. Not as a defensive clause, but as a plain statement of what the price depends on. An assumption with no stated consequence is decoration.

Exclusions are the higher-value half, and they are the section people cut because naming what is not included feels negative in a sales document. It is also the section that prevents the argument in month three. Atlassian's guidance on project scope treats the boundary the same way, recording what is in and out before work begins, and its material on scope creep describes what happens when that boundary was never written clearly enough to point at.

Acceptance belongs in the proposal too, not only in the contract. Every deliverable needs a condition under which both sides agree it is done, and it has to be something a third party could check. Atlassian's definition of acceptance criteria is the useful test: conditions specific enough that the answer is yes or no rather than a judgement about quality.

This is where the proposal hands off to the contract. The full treatment of how scope wording decides margin before delivery starts is in how to scope a fixed-fee SOW, and producing documents that hold up when the work changes is what statement of work scoping exists to do.

Most proposals are long in the wrong places. The cuts are predictable.

Methodology essays. A description of your process is not evidence that you can execute it. One paragraph and a clear statement of who does what is enough for anyone who is not already sold.

Full team biographies in the body. Names and roles in the body, biographies in the appendix. BDC's structure puts company description, bios, awards and testimonials in the appendix for exactly this reason: they support a decision, they do not make one.

Every case study you own. Pick evidence matched to the risk this particular buyer is carrying. Someone worried about a platform migration failing at cutover wants to know that 154 data sources moved with no unplanned production outages. Someone worried about account security wants to see the $41,000-plus in unauthorized spend that was fully recovered. Three matched examples beat nine unmatched ones, and nine reads as a brochure.

Superlatives with no number attached. Anything you would not repeat on a reference call. And any promise about an outcome you do not control, because a proposal that guarantees a result is a proposal you will be renegotiating the first month the result does not appear.

A signed proposal nobody can act on for three weeks is a delay you built into your own document.

Name the signatory. Include the signature block. Say what happens in the first five business days after signature, and list what you need from the client as dated items rather than as a polite request. The kickoff you describe in the proposal is the kickoff you will get.

Give a second answer that is not no. A paid discovery phase, a smaller first stage, a scoped pilot with its own acceptance criteria. A proposal offering exactly one possible response converts worse than one offering two, and the smaller option protects you as well, because work whose shape you cannot yet see should not be quoted as though you can.

Then follow up on the validity date you set. That date gives you a reason to make contact that is not a request for a decision, which is the only kind of follow-up that does not cost you standing.

One last pass before it leaves. Can a reader who was not on the call state what is being bought, for how much, and by when. Is every deliverable priced on its own line. Is there a sentence somewhere naming something that is not included. If any answer is no, the fix is structural and it takes twenty minutes. If all three are yes, the document will survive being forwarded, which is the only test that matters, because the room where it gets signed is usually not the room you presented it in.