Recheck Every Assumption Before the Proposal Leaves

A polished proposal can still be built on weak evidence

Most proposal mistakes do not begin in the proposal. They begin earlier, when an estimate, preference, or verbal answer gets copied into the working record and quietly starts behaving like a fact.

The client said twelve locations on the first call. The inventory later showed fourteen, but the quote still says twelve. A supplier said a migration could happen in six weeks, but nobody confirmed whether that clock starts at signature, site readiness, or final design approval. The existing contract date came from an old spreadsheet. The pricing assumes one billing entity even though the client has three.

None of those details looks dramatic by itself. Together, they can change price, scope, timing, contract exposure, and the recommendation.

Do not solve this with another generic proofreading step. Proofreading catches typos. You need an assumption review that checks the evidence underneath the document.

Separate facts, assumptions, and open decisions

A proposal can contain all three. The problem starts when the reader cannot tell them apart.

• Verified fact: Current evidence supports the statement, and the source and confirmation date are known.
• Working assumption: The team needs a temporary planning input, but the point is not confirmed yet.
• Open decision: The client, supplier, advisor, or another party still has to choose or approve something.

"The client has 420 users" sounds final. "Pricing assumes 420 users based on the October 8 inventory export; the client must confirm the final count before order" tells everybody what is known, where it came from, and what remains open.

That level of clarity is not legal decoration. It gives the proposal owner a way to decide whether the document can move, needs a condition, or should stop.

Review the assumptions that can change the deal

You do not need to verify every sentence with the same intensity. Start with the assumptions that can change the client's decision or your ability to deliver.

Check five areas before release:

1. Client environment. User counts, sites, inventory, applications, integrations, usage, support conditions, and current service.
2. Commercial position. Pricing basis, quantities, discounts, taxes, fees, contract dates, notice windows, term, billing structure, and advisor compensation where relevant.
3. Delivery conditions. Lead times, client resources, supplier dependencies, access, site readiness, data availability, testing, training, and acceptance.
4. Decision path. Stakeholders, approval authority, evaluation criteria, budget status, legal review, target decision date, and the next meeting.
5. Recommendation logic. The requirements each option meets, known exceptions, unresolved validation, and the reason the preferred path still wins.

The existing technology advisor proposal process explains how to build the decision brief. This review has a narrower job. It tests whether the evidence supporting that brief is still current enough to send.

Give every material assumption an evidence record

An assumption needs more than a note that says "confirm." Record enough context for another person to review it without reopening the entire deal.

For each material assumption, capture:

• The statement being treated as true
• The client, supplier, contract, inventory, activity, or document that supports it
• The date the evidence was created or confirmed
• The person responsible for verification
• The effect if the assumption is wrong
• The next verification action and due date
• The treatment in the proposal

The impact test matters. PMI describes a useful if-then analysis for assumptions: if the assumption proves false, what happens to the project? You do not need a formal scoring model for every proposal. You do need to know whether a wrong input changes a line item or breaks the recommendation.

If the answer is "the supplier must redesign the solution," "the client misses a notice deadline," or "the implementation date no longer works," the assumption deserves attention before delivery.

Set a freshness rule based on what can change

There is no universal expiration date for proposal evidence. A legal company name may remain stable for years. Supplier pricing might expire in thirty days. Headcount can change between discovery and signature. A construction date may move every week.

Set a review window by evidence type and deal condition. Recheck the source when:

• The proposal changed after client or supplier review
• The quote validity window is close to expiring
• A contract, location, user count, or implementation date changed
• A new stakeholder entered the decision
• The recommendation depends on a verbal supplier statement
• The proposal sat idle and has now returned to active review

Microsoft's current Dynamics 365 quote guidance separates draft, active, and closed quote states. It notes that an active quote is locked and that revisions create a new working version. Your tool may handle versions differently, but the operating point holds: the client-facing version should be identifiable, and a material change should create a controlled revision rather than a silent overwrite.

Use four treatments, not one vague disclaimer

Writing "subject to change" at the bottom of the document does not resolve a bad assumption. Choose a treatment for each material item.

1. Verify. Get current evidence before the proposal leaves.
2. Label. State the assumption, source, date, and possible effect clearly when the proposal can still support a useful decision.
3. Condition. Make the recommendation or commercial offer dependent on a named validation, approval, survey, review, or revised quote.
4. Block. Hold the proposal when the unknown can change supplier fit, scope, price, feasibility, or the client's ability to act.

A missing secondary contact probably should not stop a simple proposal. An unverified service inventory might stop a network replacement recommendation. Use judgment, but make the judgment visible.

Do not hide every unknown in an appendix. Put a material condition beside the recommendation, price, timeline, or scope it affects. The client should not need detective skills to understand what could change.

Assign one release owner

Several people may contribute evidence. One person should accept responsibility for the release decision.

The release owner checks the current client record, open tasks, supplier responses, quote version, contract facts, and unresolved conditions. They do not personally reperform every discovery call. They confirm that each material assumption has an owner and treatment.

The final review should answer:

• Which facts changed since the first draft?
• Which assumptions remain unverified?
• What happens if each one is wrong?
• Which conditions appear in the client-facing document?
• Who closes the remaining items, and by when?
• Which exact version is approved for delivery?

Then review the proposal live with the client. Microsoft now tells users of its sales tools to ground strategy in customer evidence and call out gaps, unknowns, and relationship assumptions. That is good advice whether a person or an AI system helped prepare the document. Generated text does not make the underlying evidence more current.

Turn proposal corrections into operating improvements

Track what the review catches. If user counts are repeatedly wrong, fix inventory intake. If supplier timelines arrive without clear start conditions, change the quote request. If notice dates keep coming from spreadsheets, repair the contract record. If the client approval path appears only after delivery, strengthen discovery.

Do not celebrate the reviewer for catching the same problem ten times. Change the source process.

For commercial changes, use the proposal discount approval process. When a sent proposal changes, follow a controlled revision and proposal follow-up process. Before closing the deal, reconcile the accepted version against the signed order.

Run the review on your next live proposal

Pick one proposal scheduled to leave this week. Mark every material statement as verified fact, working assumption, or open decision. Add the source, confirmation date, owner, impact, next action, and treatment for each assumption that could change the recommendation.

If the document cannot survive that review, it is not ready. Better to find the weak point now than explain it after the client acts.

Advisor OS CRM connects client organizations, contacts, opportunities, contracts, suppliers, proposals, activities, tasks, owners, and reporting. That gives a small advisory firm one operating record for the evidence behind the proposal and the work required to verify it.

Use the free Advisor OS agency scorecard if proposal quality still depends on one person's inbox, memory, or final document review.