What to Clarify in a Proposal Before the Client Agrees

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.

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

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.

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.

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.

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.

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.