Client Proposal Presenter

Client Proposal Presenter

Use this skill when the user wants to prepare, revise, present, or send a client proposal, quote, proposal PDF, or three-option offer. It is especially useful for website redesigns and rebuilds, but the presentation method can apply to other scoped services.

This skill handles proposal framing, document structure, decision flow, scope protection, and delivery wording. Pair it with $the-pricing-method when the value case, discovery, or price itself still needs to be researched or calculated; do not duplicate its evidence and ROI rules here.

Core principle

Make the proposal a decision aid, not a specification dump. Lead with the change the client wants, show three useful ways to reach it, state one price and ETA for each, and make the next decision obvious. Detailed implementation scope can follow the client's selection in a statement of work.

Use the presentation pattern below when appropriate:

1. Briefly recap how the work reached this point and what was understood.
2. Restate the original request, then show the larger opportunity the work can address.
3. Present three coherent options and ask which is closest to what the client wants.
4. Pause after the options and price. Do not keep selling, discount pre-emptively, or bury the choice under extra detail.

Three-option structure

Always make the options genuinely useful; never create a deliberately bad decoy. Name them in the client's language rather than Gold/Silver/Bronze.

• Ambitious: the broadest credible transformation and business outcome.
• Recommended: the best balance of outcome, evidence, scope, risk, and investment.
• Focused: a smaller but meaningful outcome or phase that remains viable at its price.

For each option, define:

• Dream: the client-language name or desired future state.
• Outcome: what changes for the client or their customers.
• Price: one clear total in the binding currency.
• ETA: when the change is expected to arrive, subject to inputs and approvals.

Put outcomes before feature lists. Use features only to make the outcome credible.

Proposal shape

Prefer a concise decision page. Add detail only where it reduces real uncertainty.

The decision page should contain:

• the client's current situation and the opportunity;
• the three named options;
• the outcome, price, and ETA for each;
• the recommended option, when there is a defensible recommendation;
• one clear next step, such as replying with Option 1, 2, or 3.

Supporting pages may cover verified understanding, option scope, shared inclusions, exclusions, assumptions, payment terms, and guardrails. Do not default to a long proposal containing every deliverable, case study, or internal process detail before the client has chosen a direction.

Scope guardrails

If the user intentionally prices below a normal floor, protect the offer explicitly rather than apologising for the price. Add a short guardrails section or page that states:

• exact page, route, asset, or deliverable limits;
• the number of consolidated revision rounds or approved visual directions;
• who supplies content, credentials, approvals, and legal sign-off;
• what counts as one feedback round;
• the single approval path or decision-maker when relevant;
• support or bug-fix duration after delivery;
• additions that require a separate written quote.

Typical separately quoted additions include new pages, structural changes after approval, extra languages, new integrations, professional photography, paid advertising, ongoing SEO, and continuous maintenance. Do not promise that a lower price includes unlimited revisions or open-ended discovery.

Currency and payment

When the client requests two currencies:

• choose one binding contract/invoice currency, normally the client's local currency;
• show the second currency as a smaller, rounded reference;
• state the exchange-rate date or basis and that the reference can change;
• calculate payment milestones in the binding currency;
• never let a rounded reference look like a fixed FX commitment.

Keep taxes, payment timing, validity period, and assumptions visible. If prices were intentionally reduced, say so internally and enforce the corresponding scope limits in the document.

Document-first delivery

If the user prefers not to hold a call, faces a language barrier, or the client is more comfortable reviewing asynchronously:

• write the client-facing document entirely in the client's language;
• keep the user's internal rationale in their preferred language;
• attach the proposal PDF and include the live concept or prototype link when useful;
• end with one low-friction written choice or adjustment request;
• do not ask for a call merely because the method often works live.

The accompanying message should be short: identify the attachment, explain what it contains, include the concept link, and ask the client to reply with the closest option. Do not claim that anything was sent unless the user explicitly authorises and the send is actually completed.

After the proposal

• If the client chooses an option, stop selling and turn the chosen option into a detailed scope of work or agreement.
• If they are between options, offer a deliberate blend with a revised price and scope; do not give away the extra work informally.
• If they ask “what do we get?”, answer at the outcome and scope level, then return to the decision.
• If they need another decision-maker, invite a written review or a follow-up that includes that person.
• If they are silent, use a respectful, low-pressure follow-up at an agreed time rather than repeated nudges.

Quality checks

Before delivery, verify:

• all claims are supported by evidence or clearly labelled assumptions;
• no invented traffic, revenue, conversion, ROI, credentials, or guarantees appear;
• the three options are distinct, valuable, and internally deliverable;
• the recommended option has a reason, not just a highlight colour;
• page and revision limits match the price and the later SOW;
• currency calculations and milestone amounts are correct;
• all included links work and the client-facing language is consistent;
• any generated PDF is rendered and visually checked before delivery;
• external sending, publishing, or client contact has explicit user authorisation.