An email arrives: “Please send a proposal.” You open an old PDF, change the client name, enter a new amount, and catch yourself thinking: it seems to have everything. There is a service. There is a price. But what exactly will the person buy when they reply “okay”?
This is where a document often turns into an ambiguous letter. The client reads “ad setup”, while you picture a brief, access permissions, campaign structure, data checks, and one revision round. Both of you see the same phrase, but agree to different things. This is not anyone’s carelessness. It is a process that decided to break before the work even started.
A useful proposal does not have to sound ceremonial. Its job is simpler: record the future agreement so that you and the client can verify the same things. What will change, where the work boundary is, what each side needs to provide, how much it costs, and which action starts the work.
1. A price list, scope of work, and proposal are different documents
A price list answers the question “how much do individual items cost”. A scope of work explains what you usually do. A proposal combines these two parts with the client’s specific situation. It does not need to predict the future, but it should make assumptions visible.
A price list is useful for orientation, but not for boundaries
It is perfectly normal for a price list to say “analytics audit” or “ad campaign management”. This helps a person understand the direction and rough order of offers. However, a price list does not explain which systems you review, what you consider a result, whether fixes are included, or what happens if access is unavailable.
If you send only a price, the client will naturally fill in the rest with their own expectations. You do not have to fill the document with tiny details for the sake of tiny details. But it is worth naming what changes the scope, sequence, or price.
A scope of work without context leaves plenty of room for guesses
The phrase “we will create a reporting system” can mean very different routes. For one client, it means consolidating existing data. For another, you first need to find out what data is available at all. A proposal should not present a general method as a ready-made promise.
Start with one sentence about the situation: “For [business name or type], [action] is proposed in order to achieve [verifiable outcome].” Then immediately unpack that sentence into fields. This turns the text from a presentation of yourself into a map of shared work.
First diagnosis: there is a price, but no defined subject
The sign of this diagnosis is simple: you can read the document and still not understand what will be ready at the end. It has a package, an amount, and attractive service names, but no outcome that can be shown or checked.
Do not treat this with a long list of activities. Instead of “we analyse, set up, consult”, name an artefact or change: an approved campaign structure, a list of identified discrepancies, a working route for handing over leads, a set of configured events. If the result depends on source data, say so.
2. Six fields that hold a proposal together
Before sending, read the document not as its author but as someone who has to make a decision. Can they answer six questions from it? If not, you do not have to rewrite everything. Often it is enough to add one precise sentence in the right place.
1. Outcome: what exactly should appear
An outcome is not “high-quality work” or “business improvement”. It is a specific consequence of agreed work: a document with conclusions, a configured process, an approved structure, a delivered set of materials. Name it so that both sides can recognise the moment when it is ready.
For an illustrative example, imagine an interior visualisation studio. In a proposal to launch an ad campaign, the outcome might be not “leads” but an approved campaign structure and a configured way to pass enquiries into a defined system. There is no need to quietly build a number of enquiries into the promise if you have not agreed it separately.
2. Scope: which parts are included in the route
Scope shows what exactly you do to achieve the named outcome. A short list of stages fits here if they genuinely follow one another: collecting provided materials, work in agreed systems, handing over the result, and a joint check.
Do not mix scope with your internal to-do list. A client does not always need the name of every tab you will open. They need to see the boundary: how many directions, systems, pages, campaigns, or materials the proposal covers, if that is what affects the work.
3. Exclusions: what remains outside the boundary
Exclusions are not a defence against the client. They are a way to avoid attributing things to the agreement that are not in it. Write calmly and specifically: “This proposal does not include creating new creatives” or “Work with an additional system is agreed separately.” Such wording does not close a door. It shows where the next decision begins.
The second diagnosis is inflated scope. It appears when the document contains broad phrases such as “full support”, “turnkey”, or “everything necessary”, but has no boundaries. On the outside, this looks confident. On the inside, it works like an empty suitcase: everyone packs their own things into it.
4. Dependencies: what must come from the client or a third party
Many delays begin not because of the work, but because of invisible dependencies. No place was assigned in the document for access to an account, source materials, a contact person, data, or approval. Then both sides wait, and the process pretends that this is a normal state.
Name the dependency without reproach: “To begin work, access to … is required”, “The client provides …”, “A designated contact person confirms the decision on …”. If a third party can affect progress, do not disguise that as complete control on your side.
5. Price: what exactly the amount is charged for
The price in a proposal should be tied to the described scope. You do not need to decorate it with complicated explanations. More importantly, it should be clear which work it relates to and what happens if the scope changes.
For example, an illustrative workshop that makes custom furniture asks for help with enquiry analytics. The proposal may cover checking already available sources and handing over a map of discrepancies. If it later turns out that another channel needs to be connected, this is not a “small detail” but a new element for separate agreement. This keeps the price from hanging in the air.
6. Acceptance: which response means the start
The final field is often hidden in an email or assumed without words. It is better to write directly which action means acceptance: confirming the proposed scope and price by email, signing the document, or another explicitly named method. This way, the client does not have to guess whether “looks good” already starts the work.
3. When “yes, but” becomes a new round of agreement
The third diagnosis is a silent change to the agreement. You can spot it in replies such as: “I agree, but add …”, “Can we keep the same price but make the scope broader?” or “I will return to this after the stated date.” Such a response may be the beginning of a new proposal, not the completion of the old one.
For agreements to which these BGB provisions apply, it is useful to keep three reference points in mind. BGB § 145 provides that the offeror is bound by an offer unless this binding effect has been excluded. BGB § 148 allows a deadline for acceptance to be set, and acceptance must take place within it. Under BGB § 150, late or altered acceptance is treated as rejection combined with a new offer.
Do not argue with edits, turn them into clarity
When a client adds a condition, you do not need to automatically treat it as a problem. First separate what is new from what has already been agreed. A reply may sound like this: “I see the additional item. It was not part of the original scope, so I suggest recording it separately and updating the proposal.” This is not coldness. It is normal care for shared understanding.
An acceptance deadline is not there to create pressure
A deadline helps avoid leaving a document in open-ended waiting. It gives both sides a clear point after which they should revisit the scope, price, or conditions instead of pretending that a month of silence changed nothing.
Do not use a deadline as a theatrical timer. Name it where it is genuinely needed for planning, and pair it with a simple action: confirmation within the stated period means you can move on to the start-up dependencies.
4. Make a narrow template, not a universal machine
The most useful template does not try to serve every service, industry, and life situation. It holds one recurring type of proposal well. For example: an initial audit, configuration of a specific process, or support for one defined direction.
A canary template should reveal the weak point
Take one recent or typical request and build a template with the six fields. Do not start with design. First check whether you can fill in every field without guessing. Where data is missing, leave not a pretty placeholder but a question for yourself: “What outcome are we verifying here?”, “Who provides access?”, “What is definitely not included?”
Such a narrow template is a canary. It does not prove that everything now works for every situation. But it quickly reveals where scope disappears in the process or where nobody records acceptance.
Automation starts after boundaries, not instead of them
When the fields repeat, part of the preparation can be automated: inserting client details, assembling service blocks, checking whether exclusions and dependencies are filled in. But automation should not decide what exactly you promised. That boundary remains for manual review. You can learn more about this process split on the automation and AI systems page.
Stop the automated route before sending and ask yourself four questions: does the outcome match the request, is the scope boundary agreed, are dependencies named, and is the acceptance action clear? If one of these has no answer, the document is not ready yet, however tidy its PDF looks.
5. Check the movement of the agreement, not the beauty of the document
After several proposals, look not only at whether they were opened. It is more useful to see at which step a question arises: outcome, boundary, price, dependency, or acceptance method. This is material for improving the template, not a reason to chaotically rewrite the entire text.
Fourth diagnosis: the proposal has no next action
If the ending is only “I will be happy to discuss this”, the client may not understand what to do next. Discussion is sometimes needed, but it too can be framed as the next step: confirm the list of items, send the required data, choose a scope option, or return comments by a specific date.
Analytics is needed here not as a decorative dashboard, but as a way to check the route “proposal - clarification - agreed outcome”. If this route matters for sales, process analytics helps formulate which transitions and reasons for stopping should be visible.
Your first step today: open one current proposal and add only a sentence about an explicit acceptance action. Then read it through the client’s eyes: is it clear what exactly “yes” will mean?