# What to Clarify in a Proposal Before the Client Agrees Before asking a client to accept a proposal, make the promised result and the boundaries of the offer easy to understand. Separate included work from exclusions, client inputs, assumptions, and questions that still need an answer. The card below records a proposal-stage decision; it does not replace an agreement or the delivery handoff that follows acceptance. A fictional studio is proposing a small website refresh and the client has asked whether campaign follow-up is included too. That question belongs in the proposal while the client is still deciding, because a vague description can leave both sides with different expectations. The worksheet turns the offer into specific decisions without treating any proposed term as accepted. Cedar Lane Studio, the proposal reference, deliverables, roles, and client decisions are fictional. Canonical: https://areinum.com/guides/clarify-proposal-before-client-agrees/ Language: en Updated: 2026-10-31 ## Name the decision the client is being asked to make Start with the result the proposal describes, then say what the client should review or choose. For example, the fictional Cedar Lane Studio is considering a refresh of two service pages. The proposal should identify those pages, the deliverables being offered, and any options that change the work, so the client can respond to the actual scope rather than a general promise to improve the website. Keep the proposal's status visible. A draft under discussion is not an accepted project, and a question from the client is not approval of a new service. Record the current version and the date it was sent, then note whether the client accepted it, requested a revision, or left a specific point unresolved. Do not treat silence as consent. ## Describe deliverables in terms someone can check For each deliverable, name the output and its boundary. A page draft might include revised copy and a desktop layout for two named pages. Say whether implementation, photography, migration, analytics configuration, or publication is included only if the actual proposal says so. Avoid relying on a label such as full service when the customer cannot tell what work it covers. The proposal can also state how many review rounds or decision points it includes, if that is already part of the offer. Use the approved version of your pricing and terms rather than inventing a price rule in this worksheet. If a detail is still being negotiated, preserve it as an open question with an owner and a date to revisit it. A fictional proposal separates an output from optional or undecided work. - Proposal item: Two service page drafts; Current wording or choice: Copy and desktop layout for the named pages; Client decision still needed: Confirm that these are the two pages in scope - Proposal item: Campaign follow-up; Current wording or choice: Not included in the current proposal; Client decision still needed: Decide whether to request a separately described option - Proposal item: Client inputs; Current wording or choice: Current service descriptions and approved brand files; Client decision still needed: Confirm who will provide them and by when - Proposal item: Publication; Current wording or choice: No publication work described in this fictional offer; Client decision still needed: Ask for a revised proposal if publication is wanted ## Make exclusions and assumptions easy to find An exclusion should name the adjacent work that is outside the proposed scope, not leave the reader to infer it. If the studio is offering page drafts, state whether implementation or ongoing campaign management appears in the offer. If the answer depends on an assumption, write the assumption in plain language and show what changes if it is false. Do not turn a useful planning checklist into a claim about what every proposal must legally contain. This is an operational review aid. The parties' actual terms, commercial choices, and professional advice belong to their own process. If a question affects the offer, pause the relevant decision and return a revised proposal instead of quietly changing the working copy. ## Record client inputs and dependencies List the information or decisions the proposed work depends on, along with who is expected to provide each one. Examples might include current service descriptions, a named contact for review, or a choice between two page directions. Separate these inputs from the studio's tasks so that a delay has a clear cause and next action. Be specific about consequences without promising a timeline you have not checked. If work cannot begin until the client selects a direction, say that the start date remains open until that choice is made. If the team has not confirmed its capacity, mark the timing as unresolved rather than inserting a calendar date that looks final. ## Keep proposal clarification separate from project handoff This worksheet ends with the client's decision on a proposal. After an offer is accepted, the delivery team needs a record of the agreed scope, current state, decisions, risks, and next step. That post-sale handoff carries accepted work into delivery and stays separate from this proposal-stage worksheet. Keeping those stages distinct prevents an open sales question from being presented as an agreed delivery instruction. Before handing an accepted proposal to delivery, keep the agreed version, the client's decisions and the remaining dependencies together. A teammate can use that record without reconstructing the offer from memory. ## Use the card before sending a revised version Read each row as a question that should be settled, retained as an explicit option, or marked unresolved before the client is asked to decide. A row marked open is not a reason to hide the proposal; it is a signal to describe the uncertainty and identify who must answer it. Keep the accepted version separately identifiable once the client makes a decision. ## Using Areinum Give Areinum Assistant the proposal version and the client's questions, then ask for a comparison of included work, exclusions and unresolved decisions. The person preparing the offer checks the draft and agrees any changes with the client. ## Questions you may have ### Should an optional service appear as included work? Keep the option separate and explain what decision or revised proposal is needed before it becomes part of the agreed scope. ### Does a client question mean the revised scope is accepted? No. Record the question against the proposal version and capture a clear decision on the version the client actually reviews. ### What should the delivery team receive after acceptance? Pass on the accepted proposal, the client's decisions, required inputs and open dependencies so the team can prepare a separate delivery handoff. ### Can I try this with our own proposals? The demo uses sample company data. Ask about access and whether the proposal material and workflow you need are available. ## Sources and further reading - [First agency client asks for lead qualification and follow-up](https://www.reddit.com/r/agency/comments/1ww3tz3/first_agency_client_wants_me_to_take_over_lead/): One first-time agency owner reports that a client asked for lead follow-up beyond the original Meta Ads service arrangement. A single self-reported case after an initial arrangement, not evidence of prevalence or proof that a pre-sale proposal checklist changes outcomes. (2026-10-18) - [A sales to onboarding handoff depends on people remembering details](https://www.reddit.com/r/CustomerSuccess/comments/1wqahi8/our_sales_to_onboarding_handoff_currently_depends/): A poster describes an onboarding team reconstructing what sales promised after a customer was closed. The poster's role is not independently verified. This source concerns post-sale continuity, which is a different stage from clarifying an unaccepted proposal. (2026-10-18) Download the original worksheet: https://areinum.com/guides/clarify-proposal-before-client-agrees/proposal-clarification-card.csv ## Proposal clarification card Cedar Lane Studio, the proposal reference, deliverables, roles, and client decisions are fictional. | Proposal reference | Scope item | Proposed detail | Status | Owner | Question or next action | Decision evidence | | --- | --- | --- | --- | --- | --- | --- | | PROP-CL-08 v1 | Two service page drafts | Copy and desktop layout for the two named pages | Proposed | Cedar Lane Studio | Client to confirm the two pages in scope | No decision recorded | | PROP-CL-08 v1 | Campaign follow-up | Outside the current fictional proposal | Open option | Cedar Lane Studio | Client to say whether a separate option is wanted | No decision recorded | | PROP-CL-08 v1 | Brand files and service descriptions | Client inputs needed before drafting | Assumption to confirm | Client contact | Confirm source and expected delivery date | No decision recorded | | PROP-CL-08 v1 | Publication work | Not described in the current fictional offer | Excluded from this draft | Cedar Lane Studio | Prepare a revised scope if requested | No decision recorded | 1. Use one row per deliverable, exclusion, assumption, client input, and open option. Keep the proposal reference and version on every row. 2. Replace the fictional wording with the offer you are actually prepared to make. State only deliverables and timing that your team has confirmed. 3. An open question stays open until the responsible person records an answer. A client question or silence does not mean the proposal was accepted. 4. When the client accepts a version, preserve that version and pass its agreed scope into the separate delivery handoff. ### Describe deliverables in terms someone can check A fictional proposal separates an output from optional or undecided work. | Proposal item | Current wording or choice | Client decision still needed | | --- | --- | --- | | Two service page drafts | Copy and desktop layout for the named pages | Confirm that these are the two pages in scope | | Campaign follow-up | Not included in the current proposal | Decide whether to request a separately described option | | Client inputs | Current service descriptions and approved brand files | Confirm who will provide them and by when | | Publication | No publication work described in this fictional offer | Ask for a revised proposal if publication is wanted | ### Limits of this method - The worksheet is an operational review aid, not legal advice or a substitute for the parties' actual proposal and agreement. - The research sources are practitioner reports and do not measure how common proposal ambiguity is or whether this worksheet improves sales outcomes. ## Related reading - [What a replacement project lead needs to continue the work](https://areinum.com/guides/prepare-one-project-for-a-new-project-lead/) - [One conversation for the work behind your business](https://areinum.com/product/assistant/) Explore the demo: https://platform.areinum.com/ The demo uses sample company data. Access may need to be arranged.