B2B sales enablement workshop / 5 MIN READ
Put the assumptions where the buyer can see them
Make proposal scope, dependencies and exclusions readable before commercial approval.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A proposal becomes misleading when a confident promise depends on hidden buyer work or unpriced services. State the conditions that make the proposed outcome achievable and distinguish them from commitments.
What you will leave with: An assumptions register linked to the proposal’s scope and review process.
Use this when
- Implementation effort repeatedly surprises customers.
- Sales proposals combine standard language with custom promises.
This is not legal advice or authority to change contractual terms without the appropriate commercial and legal review.
Connect the proposal to verified needs
Salesforce’s sales-process guidance starts from customer needs and agreed follow-up. A proposal should preserve that context instead of substituting a generic package description.
Summarize the task the buyer is trying to improve and distinguish confirmed requirements from open questions. Cite the relevant meeting or requirement record internally so the team can check the basis. Do not present an inferred need as a customer commitment. If the buyer corrected an earlier assumption, remove or revise it everywhere rather than leaving contradictory versions in separate sections.
Expose the work behind the promise
For each promised deliverable, identify what the supplier will do, what the buyer must provide and what other parties control. Specify required input quality, approvals, access and decisions in plain language. A dependency should be understandable without a specialist decoding it.
Separate assumptions from exclusions. An assumption is a condition used in planning, such as receiving a complete approved data file. An exclusion is work the proposal does not include, such as cleaning historical records. Avoid using vague language to hide likely additional costs. If the assumption is uncertain, show the consequence for scope, timing or further review.
Resolve commercial ambiguity before sending
Ask the delivery owner to check whether the proposed scope can actually be fulfilled. Have the appropriate commercial or legal reviewer inspect commitments, acceptance language and change terms. Marketing polish must not convert a tentative estimate into a guaranteed result.
Keep optional work clearly optional, with its decision point and approved pricing method where applicable. Confirm that tables, summaries and attachments describe the same package. A disclaimer at the end does not repair a headline that promises something materially broader. If important information is missing, identify it as an unresolved condition rather than filling the gap with an optimistic assumption.
Carry assumptions into delivery and change control
Once the proposal is accepted through the proper process, give the delivery team the actual agreed version and its unresolved items. Do not rely on a sales handoff that says only “standard implementation.” Explain why any unusual assumption matters and who can verify it.
If a condition changes, assess the effect and follow the agreed change process before promising extra work. Keep the buyer informed about the specific dependency and available options. An assumptions register is not a tool for blaming the customer afterward; it is a shared way to prevent surprises and make necessary choices visible early.
Make the reasoning concrete.
A fictional reporting-service proposal promises a migration by a launch date. The estimate assumes the buyer will provide clean, mapped historical records, but that condition appears only in an internal note.
Keep the promise simple
Opening: Send the polished date without explaining the required input.
Hypothesis: The proposal sounds confident and easy to approve.
Risk: The buyer may reasonably expect data preparation to be included.
Make the dependency explicit
Opening: Describe the required input, preparation responsibility and effect of missing information.
Hypothesis: The buyer can evaluate the real scope before agreeing.
Risk: The timeline may need revision or an additional scoped service.
The delivery owner reviews the requirement with the buyer. The proposal is revised to distinguish migration from data preparation, and no new deadline is promised until the dependency is understood.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Requirement
Which buyer need is confirmed and which is inferred?
Supplier work
What exactly will be delivered?
Buyer dependency
What input or decision is required, by whom?
Uncertainty
What changes if an assumption proves false?
Approval
Who has reviewed the actual commitment and version?
Watch for the wrong conclusion.
- Hiding critical buyer work in internal notes.
- Treating estimated outcomes as guaranteed results.
- Sending a proposal that delivery has not checked.
Your next action
Choose the strongest promise in your current proposal and write the conditions required to fulfill it directly beside the scope.
Sources & scope
The workflow, worksheets and hypothetical examples are original editorial analysis. Sources support only the identified principles. No measured business results or named human reviewer are claimed.
- Salesforce Trailhead: Learn About the Sales Process →Primary vendor training guidance · Supports: A sales process includes understanding customer needs and following up with agreed next steps; the decision framework is original analysis.