The awkward part of starting a client engagement is that the work has been agreed, but the delivery team still has to reconstruct what the agreement means in practice. Scope sits in the proposal, expectations in meetings and email, and important restrictions in a contract or client system.

Strawberry can bring that accepted context together in the same workspace and turn it into one engagement brief. The result gives the team a reliable starting point without treating every sales note as a commitment or carrying another client's setup into the work.

Start delivery from what the client agreed to

A proposal explains what the consultant is offering. The engagement brief begins after acceptance and explains how the team will deliver it. Strawberry confirms the accepted piece of work, the people responsible, the current phase, and where the brief should live before assembling the handoff.

Your companion can work from the approved proposal or statement of work, kickoff material, discovery records, email, meeting notes, delivery plans, and relevant client systems. Because those sources stay available beside the brief, a delivery lead can inspect the wording behind an assumption instead of relying on a summary alone.

Want to try it?

Ask your Strawberry companion: “Turn this accepted work into a clear engagement brief covering scope, stakeholders, milestones, evidence, communication, systems, risks, and client-data restrictions.”

Skill

Start a client engagement

Turn one accepted piece of work into a reliable engagement brief before delivery begins.

Capture what delivery needs

The brief should be concise enough to use and complete enough to prevent avoidable rework. Strawberry separates accepted facts, working interpretations, and open questions, with source links beside decisions the team may need to check later.

Part of the briefWhat it should make clear
Scope and outcomesWhat is being delivered, what is excluded, and how the client will judge it.
People and milestonesWho decides, reviews, contributes, and owns each important handoff.
Evidence and systemsWhich definitions, sources, files, tools, and checks the work will rely on.
Communication and riskHow the engagement will run, where issues escalate, and which assumptions remain open.
Client restrictionsWho may access the work and how confidential, personal, legal, or retained data must be handled.

When sources disagree, the brief keeps the conflict visible and identifies who must resolve it. Strawberry does not invent acceptance criteria, dates, permissions, authority, or access simply to make kickoff look complete.

Keep client context separate

Boutique firms often reuse a familiar engagement shape, but the sources and restrictions must be replaced for every client. Strawberry can learn the accepted structure and review method without copying another client's facts, pricing, strategy, credentials, or confidential examples.

Before any sharing path is suggested, Strawberry establishes the audience, access model, and destination. An internal working brief, a client-facing kickoff document, a team skill, and a public artifact are different things. Approval of the brief does not authorize sending it or changing a project or CRM record.

Use the brief through the engagement

Once reviewed, the brief becomes useful context for market research, company analysis, recommendations, meeting preparation, debriefs, and status updates. The team does not have to re-explain the client, evidence standard, or delivery boundary at every handoff.

When scope, ownership, evidence standards, access, or restrictions change, Strawberry proposes an update and keeps the previous agreement traceable. Proposed changes do not become accepted facts until the right person reviews them.

Reuse the method, not the client

After a few successful engagements, the firm can save the accepted brief structure, source checklist, evidence standards, communication choices, and review behavior as a custom skill. A sanitized method can be shared with a boutique team once its audience and destination are agreed.

Engagement setup is usually event-driven, so it does not need a scheduled Routine. A later status or brief refresh can become draft-first automation when the sources, cadence, owner, destination, approval behavior, and stop conditions are stable.

Official Strawberry skill
Copy skill file Download skill file

Start a Client Engagement

Start delivery from what was actually accepted. Create one practical brief that the people doing the work can trust, without reopening the proposal or copying another client's setup.

1. Confirm the engagement

Identify the client or internal stakeholder, accepted piece of work, delivery team, current phase, and intended home for the brief. Confirm that the work has been accepted. If the user is still defining the commercial offer, use strawberry/consulting/create-a-client-proposal first.

Follow an existing kickoff or engagement method when the user has one. Establish who should be able to see the brief and whether it is an internal working document or something the client will also receive.

2. Assemble the accepted context

Use the approved proposal, statement of work, RFP response, kickoff material, discovery records, email threads, meeting notes, delivery plans, and relevant files already available in Strawberry. Work across visible tabs, logged-in sites, files, meetings, and connected apps when they materially improve the brief. Keep important sources easy to inspect.

Keep every client's facts, files, commercial terms, access, learned context, and artifacts separate. Do not import another client's delivery assumptions, examples, or restrictions. Ask only about gaps or conflicts that could change the work.

3. Build the working brief

Capture the information the team needs to deliver:

  • the business context, decision, intended outcomes, scope, deliverables, and exclusions;
  • stakeholders, decision owners, reviewers, responsibilities, and client dependencies;
  • milestones, timing, acceptance points, and known resourcing constraints;
  • evidence standards, definitions, approved sources, and how claims or calculations will be checked;
  • communication cadence, meeting rhythm, status format, and escalation path;
  • systems, files, source locations, access boundaries, and the intended home for new work;
  • client-data, confidentiality, legal, privacy, brand, and retention restrictions;
  • assumptions, open questions, risks, and changes that would require the scope to be revisited.

Distinguish accepted facts from working interpretations and unresolved questions. Link decisions to their sources when the team may need to verify them later.

4. Resolve the important gaps

Compare the sources and surface contradictions, unclear ownership, missing access, unsupported success measures, or delivery expectations that do not match the accepted scope. Recommend an answer when the record supports one, and identify the person who must decide when it does not.

Do not invent acceptance criteria, client permissions, authority, dates, outcomes, or system access. Do not quietly turn a kickoff decision into a commercial commitment.

5. Review the handoff

Present a concise brief and a short list of unresolved decisions. Check it with the people who own delivery before using it as the basis for research, meetings, artifacts, status updates, or system changes.

Approval of the brief confirms the working context only. Client delivery, sharing, task assignment, CRM or project changes, sending, publishing, and legal acceptance remain separate actions. Establish the audience, access model, and destination before recommending any sharing path.

6. Put the brief to work

Use the accepted brief to route the engagement without duplicating specialist workflows:

  • strawberry/research-analysis/map-a-market for landscapes and categories;
  • strawberry/research-analysis/extract-web-data for repeated structured research at scale;
  • strawberry/consulting/turn-client-research-into-recommendations when evidence needs to become a client decision;
  • strawberry/operations/prepare-for-meetings and strawberry/operations/debrief-a-meeting for the general meeting loop;
  • strawberry/operations/prepare-a-status-update for source-backed engagement updates.

Update the brief when accepted scope, owners, access, evidence standards, or restrictions change. Do not record proposed changes as agreed facts.

7. Preserve the reusable method

After the engagement setup works, offer to save the accepted structure, source checklist, evidence standards, communication choices, and review behavior as a custom skill. A boutique team can share that sanitized method after client-specific facts and access are removed and the audience and destination are agreed.

Engagement setup is normally event-driven, so do not create a Routine by default. A draft-first Routine may refresh the brief or prepare a status view only when the sources, owner, cadence, destination, approval behavior, and stop conditions are stable.

Suggested outcome

Create one concise, source-linked engagement brief that gives the delivery team a trustworthy view of the accepted work, its boundaries, the evidence expected, and the decisions still open.