build-client-brief

name	build-client-brief
description	Turn accepted consulting or agency work into one reliable engagement brief covering scope, stakeholders, milestones, evidence standards, communication, systems, risks, and client-data restrictions. Use after a proposal, statement of work, or internal mandate has been accepted and delivery needs a clear starting point.

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.