A client writes: “Send a proposal.” You open an old PDF, change the company name and amount, then look at three neat lines. They contain a service, a price and perhaps a date. Only the answer to a simple question is missing: what exactly will the person receive when the work is complete? The first follow-up question takes the file apart: are revisions included, who provides access, what happens with a new idea in the middle of the work, what response confirms this exact version. Everything important seems to have been discussed, but the document does not remember it.
A broken process especially loves the word “flexibility”. It sounds lovely until two people flexibly pull one agreement in different directions.
A free service is neither a magic wand nor the problem here. It can help store versions, insert company details, assemble a tidy file, and keep it from getting lost among attachments. But the service does not know whether the phrase “ad setup” means one campaign with ready materials, or also creatives, analytics, result explanations, and ten new directions. Quality appears before the “create PDF” button: when you turn a conversation about a service into an agreement route both sides can verify.
1. A price list names an amount, while a proposal shows the route
A price list answers the question “how much does one unit cost”. Package names, rates, or standard services belong there. It is a useful guide when a person is only comparing options. But a price list says almost nothing about a specific situation: where the work starts, what state should exist after it, which materials already exist, and which are missing. The same line item in a price list can be entirely honest for two projects and still mean different sets of actions.
A work description goes one step further. It can name actions: build a page, set up a campaign, run training, prepare a report. Yet a list of actions is also easy to read in different ways. “Prepare a page” means approved blocks on a provided platform to one person, and texts, translation, integrations, a blog, and a new website structure to another. Both readings seem natural until someone considers the additional work already included in the original amount.
A proposal combines the result, scope, and way of moving between them. It does not have to predict every future email or pretend that work never changes. Its task is more modest and more useful: record what is known, name assumptions, show dependencies, and create room for a new agreement if the starting picture changes. This matters both when a client asks for “something small” and several related tasks have already grown in the correspondence, and when a service repeats but needs different access, materials, or approvals each time.
2. Six things you need to see before sending
Start with the result, not a beautiful service name. A result is a state you can recognise after the work. Instead of “page creation”, write about a published page with approved blocks and an enquiry form. Instead of “analytics”, write about an approved list of events and a report where they can be checked. This description does not promise abstract “improvement” and does not need to be promotional. It simply removes the situation where one person expects a finished solution and the other believes they only delivered a draft.
After the result comes the scope: specific parts of the work, stages, materials, or agreed iterations. You do not need to write instructions for a spaceship. You need to name the decisions that determine the boundary. For an advertising campaign, this may be a structure for one approved service, setup using the provided materials, and a launch check. For a page, it may be a list of blocks, layout, and publication on the agreed platform. If a certain part is not named, do not disguise the assumption with the word “comprehensive”.
Exclusions continue the scope rather than fight with it. A calm phrase such as “this proposal does not include translation, media budget purchases, the creation of new creatives, or functionality beyond the described result” does not push people away. It explains where the current route ends. Add the next bridge too: if any of the named items becomes necessary, it moves into a separate round of agreement. Then an additional request does not look like an argument about fine print, but becomes new work that can be honestly described and priced.
Dependencies show what must come from the other side: access, texts, images, decisions about an option, approval of an interim result. The price should be tied to the described scope, and the agreed payment principle should be stated beside it if it has already been defined. Finally, the document needs an explicit acceptance action: for example, written confirmation of this exact version. A result without exclusions invites excessive expectations, exclusions without dependencies sound like a cold refusal to help, and a price without acceptance leaves fog after the phrase “looks good”. Together, the six fields make the file not merely informative, but verifiable.
3. The same amount sometimes hides different work
Imagine Mark, who prepares a proposal for an ad launch in a free service. In the first version, he writes: “Ad setup - 900 euros.” The client agrees, then sends ten services, asks him to invent creatives, connect analytics, and explain results regularly. Mark did not make an arithmetic mistake. He left unanswered which result and actions the amount covers. The client is not necessarily trying to impose something either: the short document simply left room for a different reading.
In the next version, Mark defines the result as a campaign ready to launch for one approved service. In the scope, he states the campaign structure, setup of approved materials, and a launch check. Separately, he names exclusions: creating new creatives, work with several services, and building analytics beyond the approved list. To start, he needs access to the ad account and approved materials. Now a request to add another service does not become an unpleasant discussion about what someone “meant”. It is a visible change in scope for which it is natural to create a new agreement.
Another hypothetical example is Olesia, who offers to make a landing page. Her first document has the heading “turnkey website”, a price, and a timeframe they discussed on a call. In response comes a request to add a blog, two language versions, and an integration with a third-party system. This is not a set of cosmetic revisions. The result the person wants to receive has changed.
Olesia does not argue about whether a “website” is included in a website. In the updated proposal, she records one result: a landing page with approved blocks. The scope includes layout, publication on the provided platform, and one agreed revision iteration. Dependencies include texts, images, access to the platform, and approval. The blog, language versions, and integration remain outside the scope of the current version. If the client wants to add them, a new proposal or a clear change to the existing one appears. This way, the document does not close the conversation, but gives it an honest continuation.
4. A change in the reply is not always a quiet “yes”
For a proposal governed by German law, BGB § 145 provides that the offeror is bound by a proposal unless this binding effect has been excluded. Therefore, do not treat a sent document as an accidental draft email. Before sending, check whether the title, scope, price, and date match the exact version you are ready to discuss as a proposal.
BGB § 148 allows an acceptance period to be set. You can state directly in the document until which date this version is valid, so current terms are not mixed with old emails. This is not a decorative line in the footer: it makes visible the moment when the current route can still be accepted or when it is worth returning to the terms and checking them again.
Under BGB § 150, a late or altered acceptance is treated as a rejection combined with a new proposal. In everyday work, this is easy to recognise: “I agree, but add two more pages” is not a silent confirmation of the original scope. It is useful to pause here and say plainly: the original version covered one result, the new request changes the scope, so an updated version needs to be recorded.
This pause does not make the conversation bureaucratic. It saves it from the moment when the work is already done and two people suddenly discover that they were following different maps.
5. Automate the form, but leave the decision to a person
Start not with a universal document for every service, but with a narrow template for one recurring type of work. Leave fields in it for the result, scope, exclusions, dependencies, price, acceptance period, and an explicit client action. A free service can insert the name, date, line items, and amount, save versions, and assemble a draft. But it cannot determine whether the familiar word “setup” hides one specific step or half of a new project.
The boundary of automation comes before the meaningful review. Read the completed proposal as if you were not on the call: can you see what will change; can you find the boundary of the work; is what will stop the start if missing named; is it clear which action accepts this exact version. If the answer to any of these questions is “that is obvious anyway”, it is probably not in the file.
When such a template holds up across different real situations, you can explore work systems automation so fields, versions, and the next action do not get lost. And when proposals already travel from sending to agreement and result, analytics helps check the route itself instead of guessing from the mood in the correspondence.
There is one first step: open the last proposal you sent and add one sentence about the result the person will be able to verify. The scope, boundary, and way to say “yes” will naturally follow from it.