How to prepare a commercial proposal in a free service so it doesn't become a price letter

When a client writes «send over a commercial proposal», what they most often receive is a file containing the name of a service and a sum. Sometimes a logo, a paragraph about the company, and a «best regards» sign-off get added too. Formally, it’s a document. In reality, it’s a price letter: it says how much something costs that the reader can’t yet see. The client looks at the figure and is forced to fill in everything else themselves — what exactly they’re buying, where your work begins and where it ends, and what will happen if they reply «okay».

The problem isn’t that the price is bad. The problem is that a price without context turns you into a price list. The reader compares your sum with someone else’s sum, because there’s nothing else to compare. You look like a line in a table rather than a person taking on a specific result. And worst of all: when it comes to the actual work, every small detail becomes a subject of dispute, because no one agreed on what’s included in that figure and what isn’t.

A price letter also quietly shifts the risk onto you. If the document doesn’t state where the boundary of your work lies, the client will quite sincerely assume there is no boundary. They’ll ask for «just a little more», then «a tiny fix», and you’ll end up in a situation where you formally promised a sum but effectively promised an endless scope.

Your next step is simple: open the last file you sent as a proposal and try to understand, from it alone, where your work ends. If you can’t — it was a price letter.

A proposal differs from a letter in that it describes the deal in full, not just its cost. The article I’m building on here breaks this down into five parts: the result, the boundaries, the dependencies, the price, and a separate event of acceptance. This isn’t bureaucracy — these are five questions the reader is looking to answer anyway; without them, they look for the answer in their own head, and with them, in your document.

The result is what the client will have in hand when you’re done. Not «development», not «support», but a specific, observable state: an integration that works, a report that’s set up, a process that’s running. The result is described so that it can be recognized, not felt.

The boundaries are what the work does not include. This is exactly where most proposals stay silent, and it’s that silence that later costs the most. A boundary is stated plainly: «this includes one form, not three», «we set it up but don’t migrate old data», «support runs until launch, after that it’s separate». A boundary doesn’t make you greedy. It makes you clear.

The dependencies are what you can’t do your part without. Access, answers, decisions on the client’s side. If this isn’t in the document, any delay will look like your fault, even when you spent weeks waiting for a password.

The price comes after these three things for a reason. Once the reader already knows the result, the boundaries, and the dependencies, the sum stops being an abstract figure and becomes the price for a specifically outlined piece of work. And the event of acceptance rounds it all off — there’s a separate conversation about it below, because it’s what turns a document into a deal.

Your step: take these five words — result, boundaries, dependencies, price, acceptance — and check your draft against them. If any one of them is missing, you know what to add.

Here it helps to understand one thing from the logic of contract law, because it directly affects how you write. Whoever makes an offer to enter into a contract is usually bound by it — meaning they can’t simply change their mind — unless they have explicitly excluded that binding effect themselves. In plain words: when you send a proposal, you take on, by default, what’s written in it. This isn’t a reason to fear the document. It’s a reason to write it deliberately: everything you’ve put in it, you’re genuinely ready to carry out for the stated sum.

Hence a practical conclusion. If you don’t want to be bound indefinitely, it’s worth marking that plainly in the text itself — for example, stating that the proposal is valid until a certain date, or that the final terms are agreed separately. Binding effect doesn’t appear or disappear on its own; you either accept it consciously or limit it consciously. Both options are fine; only the third is bad — not thinking about it at all.

The second thing matters even more for everyday work. If a client replies «I agree, but…» and changes or limits something, that is legally not agreement. Acceptance that is altered or limited counts as a refusal combined with a new offer. That is, with their «almost yes» the client has effectively made you their own counter-offer, and now it’s you who decides whether to accept it or not. This saves you from the classic confusion where both sides think they’ve agreed, when in fact each was holding their own version in their head.

For you, this means that any change from the client should be caught as a separate event, not treated as a formality. «Yes, only without the second stage» is not an acceptance of your proposal — it’s a new one, and you can work by it only after your own explicit «yes» in response.

Your step: add one line to your template about the proposal’s validity period, so that you consciously manage your binding effect rather than receiving it by default.

Imagine — purely for illustration, this isn’t a real client — that you own a small B2B service that sets up automated reports for online stores. A store manager approaches you: they want «the data to gather itself into a single spreadsheet». The temptation is to reply with a letter: «Setting up automated reports — such-and-such a sum». And that’s it.

Now the same request, assembled as a proposal. The result: every day at eight in the morning, a summary of the previous day’s sales appears in a shared spreadsheet. This is something the client recognizes without explanation — they simply open the spreadsheet and see it. The boundaries: you connect one data source, not all of the store’s systems; you build one report, not a dashboard with ten charts; you don’t migrate historical data from past years. The dependencies: the client grants access to their account before the work starts and assigns one person who answers questions during the day.

Notice that in this example there isn’t a single made-up outcome figure — no «40% time saved», no «sales growth». And that’s on purpose: you can’t promise a specific business effect, because it depends on things outside your work. You promise a working report in a spreadsheet — exactly what you actually control. You place the price after this description, and it now reads as payment for outlined work, not as a figure out of thin air.

And now imagine the client replies: «Great, but let’s do three data sources right away, plus a dashboard». Thanks to the previous section, you already know this isn’t agreement to your proposal but a new proposal from them. You calmly prepare an updated version for the wider scope instead of silently agreeing to carry three times the work for the old sum.

Your step: take one real request currently sitting in your inbox and lay it out along this same scheme — result, boundaries, dependencies — before naming a price.

The good news: you don’t need an expensive tool for this. Any free document editor in which you can create a file, share a link, and fix a version will do just fine. The main thing isn’t in the buttons, but in how you organize the document.

Make the structure visible. Five elements — five separate blocks with headings: «What you’ll get», «What’s not included», «What’s needed from you», «Cost», «How to accept the proposal». When the «what’s not included» section stands on its own and is visible, the client won’t be able to say later that they didn’t notice the boundary. You don’t hide limitations in fine print — you place them next to the result, as an equal part of the agreement.

Next — versioning. Free services rarely have sensible version management, so do it by hand: name the file with a date or number, for example «Proposal v2, 27 July». It’s a small thing that saves you when you’ve exchanged three revisions and no longer remember which exact sum and scope you discussed in a live conversation a week ago. A precise version isn’t pedantry, it’s what you both refer back to later.

Avoid the «I’ll leave room to maneuver» trick. The temptation to write vaguely so you can settle things later actually works against you: a blurry wording is interpreted by the reader in their own favor, while it’s you who is bound by your proposal. So it’s better to be narrow and honest than broad and just-in-case.

Your step: create an empty template with the five headings in a free editor today, so that next time you don’t start from a blank page under deadline pressure.

The last part — the one everything was set up for. A proposal stops being just a nice description once it contains a clear event of acceptance: a specific action that means «yes, we’re working on these terms». Without it, you remain in a state of limbo where the client seems to agree, but no one has named the moment from which the agreement takes effect.

Describe this event directly in the document. For example: to accept the proposal, the client replies in the correspondence with the words «I accept version v2» — and you begin. Now acceptance isn’t a vague «well, go on», but a recognizable fact. You know when the deal exists, and the client knows exactly what they’re confirming. And, most importantly, you both refer to one named version rather than to different memories of a conversation.

Here the logic about altered acceptance comes into play again. If, in response to «I accept», there comes «I accept, but without the second stage», you don’t start working by the old document. You treat it as a new proposal from the client, prepare the next version for the new scope, and wait for your own clear acceptance this time. That way the event of acceptance is always tied to a specific version rather than an «approximate» one, and neither side ends up in the «I thought we agreed on something else» situation.

It’s exactly this discipline that separates a service owner who controls their deals from one who works out afresh, every time, what was actually agreed. You aren’t making the client’s life harder — you’re removing the ambiguity that both of you suffer from.

Your step: add one line to the end of your template about the exact action by which the client accepts the proposal, and name the version in it — this will turn your document from a letter into a deal.