A consulting proposal has to make three things agree: what the client needs, what the consultant plans to deliver, and what the firm is prepared to commit to. The information behind those decisions is usually spread across discovery notes, an RFP, email, past work, pricing, and delivery plans.

Strawberry is an agentic browser and workspace with built-in AI agents. Your companion can work from the opportunity record that already exists, keep the supporting material beside the draft, and turn it into a proposal ready for commercial and delivery review. That makes it easier to catch a missing decision before it becomes an accidental promise.

Start with the real opportunity

The source material may include an RFP in a logged-in portal, a discovery transcript, the latest email thread, an approved offer, or a prior proposal whose structure the firm wants to reuse. Strawberry can follow it across visible tabs, files, meetings, and connected apps without asking you to rebuild the whole opportunity in a prompt.

Your companion establishes which client decision the proposal needs to support, who will read it, what format they expect, and when it is due. If an important account or meeting gap remains, it can use the relevant research or debrief workflow instead of quietly filling the gap with a plausible assumption.

Want to try it?

Ask your Strawberry companion: “Turn this opportunity, RFP, or discovery record into a complete consulting proposal using our approved scope, pricing, terms, and delivery material.”

Skill

Create a client proposal

Turn one live opportunity, RFP, or discovery record into a complete consulting proposal ready for review.

Agree the scope before polishing the document

A well-written proposal can still be wrong. The client may have asked for an outcome without agreeing how it will be measured. A delivery date may depend on access the client has not promised. The price sheet may not cover the option discussed in the final meeting. The proposal has to resolve those decisions before its wording can be trusted.

Before building the finished document, Strawberry prepares a concise outline and separates the client's stated requirements, the consultant's proposed approach, and the points that are still unresolved. Reviewing that outline gives the consultant a manageable place to correct the scope before time goes into layout and detailed prose.

  • The client problem, intended outcomes, and important constraints.
  • The proposed approach, deliverables, responsibilities, and timeline.
  • Approved fees, payment terms, assumptions, exclusions, and other terms.
  • Dependencies, unsupported claims, and decisions that still need an owner.

When an approved answer is missing, the draft keeps a clear placeholder or decision note. It does not invent a fee, discount, ROI claim, legal clause, delivery date, or authority simply because a complete-looking proposal would read more smoothly.

Use the format the client decision needs

A detailed statement of work usually belongs in a document. A proposal that will be presented to a buying group may work better as a deck with one clear point on each slide. If the proposal includes delivery options, staffing, fees, or scenario calculations, a supporting spreadsheet can make the inputs and formulas visible.

Strawberry carries the accepted scope into the chosen artifact, so the consultant does not have to brief a separate writing, presentation, or spreadsheet tool from scratch. The proposal, deck, and supporting model stay aligned because they come from the same reviewed decisions.

Review the proposal as a commitment

Proposal review needs a different standard from ordinary editing. Each promise should be supported by the opportunity record and by the consultant's authority to make it. Scope, acceptance criteria, client dependencies, staffing, schedule, pricing, outcomes, confidentiality, and terms all deserve attention when they affect what either side is agreeing to.

Because the supporting record remains available in the same workspace, your companion can show the material decisions and recommend an answer when the evidence supports one. Finance, delivery, leadership, or legal reviewers still make the approvals that belong to them. Strawberry makes those review points easier to inspect; it does not turn a polished draft into commercial or legal authority.

Keep review, sending, and acceptance separate

An internal reviewer approving the content does not automatically approve client delivery. Before suggesting how to share it, Strawberry checks who should see it, what access they need, and where it should go. The editable source, exported deck or document, supporting links, and any client data all need to be appropriate for those recipients.

Sending the proposal, changing the CRM opportunity, and accepting legal terms remain separate actions. Strawberry can prepare the email or proposed record change from the same context, but each action stays reviewable before it happens.

Turn the proposal into a working engagement brief

Once the work is accepted, the useful context should not disappear into an attachment. Strawberry can carry the approved scope, stakeholders, milestones, assumptions, evidence standards, communication plan, and client-data restrictions into the engagement brief. The delivery team starts from the agreement that was actually reviewed instead of reconstructing it during kickoff.

After a few successful proposals, your companion can preserve the accepted structure, sources, claims, voice, pricing rules, and review points as a custom skill. That gives the next proposal a better starting point without carrying one client's confidential facts or terms into another engagement.

Start with one real opportunity. Strawberry can turn the material you already have into a proposal outline, surface the decisions that still need owners, and build the finished document only after the scope is sound.

Official Strawberry skill
Copy skill file Download skill file

Create a Client Proposal

Build the proposal from the real opportunity and the consultant's approved pricing, terms, and delivery material. The aim is a proposal the client can evaluate, not a generic capabilities pitch. If the user already has a proposal process or tailored skill, follow it.

1. Understand the decision

Identify the client, opportunity, proposal type, intended reader, decision the proposal should support, deadline, and requested delivery format. Establish whether this is a new proposal, a response to an RFP, a statement of work, or a revision.

If the work has already been accepted and the user needs to prepare delivery, use strawberry/consulting/build-client-brief to start the engagement instead of reopening the proposal.

2. Bring together the approved context

Use the relevant sources already available in Strawberry, such as visible tabs, a logged-in RFP portal, discovery notes or transcripts, email threads, the client website, prior proposals, case studies, offer descriptions, pricing, terms, and brand material. Ask before looking through connected apps when permission or scope is not already clear.

Working from this shared context lets Strawberry draft from the complete opportunity record without making the user reconstruct it in a prompt. Keep important source material easy to inspect while the proposal is reviewed.

Use strawberry/sales/research-an-account when important account context is missing. Use strawberry/sales/debrief-a-sales-meeting when a discovery record still needs commercial interpretation about client needs, commitments, or next steps. Do not repeat work those skills have already completed.

Keep each client's facts, files, commercial terms, and examples separate. A prior proposal may provide an approved structure or style, but never carry its client facts, pricing, commitments, or confidential material into this one. Ask only about gaps or conflicts that could materially change the scope or commitment.

3. Agree the scope before drafting

Prepare a concise proposal outline that distinguishes:

  • the client's stated problem, requirements, and constraints;
  • the outcomes the work is intended to support;
  • the consultant's proposed approach, deliverables, responsibilities, and timeline;
  • approved fees, payment terms, assumptions, exclusions, and other terms;
  • unresolved decisions, unsupported claims, and dependencies.

Make interpretation visible rather than presenting it as a client-agreed fact. Explain meaningful choices about depth, schedule, deliverables, or format, and recommend an answer where the evidence supports one. Let the user correct the outline before building the finished proposal.

4. Draft the proposal

Write in language appropriate to the client and decision. Include only the sections the proposal needs, while making the problem, intended outcomes, approach, deliverables, responsibilities, timeline, commercial scope, assumptions, exclusions, terms, and next step easy to find.

Use a document for a detailed proposal or statement of work. Use a deck when the proposal will be presented or benefits from a visual narrative; in that case, use strawberry/research-analysis/create-beautiful-slide-deck for presentation production. When fees, options, resourcing, or calculations need a transparent model, use the internal strawberry/general/spreadsheets capability and keep its inputs and formulas visible.

Do not invent fees, discounts, legal language, authority, client outcomes, ROI, dates, staffing, or other commitments. Use a clear placeholder or decision note when an approved answer is missing.

5. Review it as a commitment

Check every promise against the available evidence and approved authority. Look for scope creep, unclear acceptance criteria, hidden client dependencies, scheduling or resourcing conflicts, unsupported outcomes, and commercial or legal points that still need review.

Show the user the material decisions and recommended answers, then revise the proposal with their feedback. Identify when legal, finance, delivery, or leadership approval is still required; do not provide that approval on their behalf.

6. Prepare the approved delivery

Deliver an editable source and the agreed presentation or export, plus a short list of unresolved commercial points. Before recommending any sharing path, establish the audience, access model, and destination. Protect client and personal data in the document, its links, and any visual examples.

Treat internal review, client sharing, sending, CRM updates, and legal acceptance as separate approval states. Approval of the draft does not authorize any of them. If the user wants to send the proposal, use strawberry/sales/send-personalized-outreach and obtain its required approval. If the opportunity record should change, use strawberry/sales/keep-crm-updated and follow its scoped review behavior.

7. Preserve what worked

After the proposal has been accepted as a useful model, offer to save the approved structure, sources, claims, voice, pricing rules, and review points as a custom skill. Share the reusable method with a boutique team only after removing client-specific facts and restrictions and agreeing who can access it and where it belongs.

Proposal work is normally event-driven, so do not suggest a scheduled Routine by default. If a trusted intake process genuinely repeats, a draft-first Routine may prepare the outline and flag missing inputs. It must stop when pricing or authority is missing, terms conflict, client context is unclear, or the request falls outside the approved offer.

Suggested outcome

Create a client-ready proposal in the agreed format, grounded in the opportunity record and approved firm material. Keep assumptions and open decisions visible, and make it clear what has been drafted, reviewed, shared, sent, or accepted.