Build a Client Engagement Brief

Begin delivery from the work that was actually approved. Produce one practical, source-grounded brief that the delivery team can rely on without reopening commercial negotiations or carrying assumptions from another engagement.

1. Establish the engagement baseline

Identify:

• the client or internal stakeholder;
• the accepted engagement or workstream;
• the delivery team and accountable owner;
• the current delivery phase;
• the intended location for the engagement brief;
• whether the brief is internal-only or may also be shared with the client.

Verify that the underlying work has been accepted before treating it as delivery scope. If the commercial offer, scope, or proposal is still being developed, complete the proposal workflow first rather than treating draft terms as approved work.

When the organization already has a kickoff, onboarding, or engagement-management method, follow that method unless the accepted engagement requires an explicit exception.

Define the brief's audience and access boundaries before assembling or distributing it.

2. Assemble the authoritative context

Gather the strongest available sources describing the accepted work. These may include:

• approved proposals and statements of work;
• RFP responses and procurement material;
• kickoff documents;
• discovery notes and research;
• relevant email threads;
• meeting notes and transcripts;
• delivery plans;
• approved estimates or schedules;
• files and records available through connected systems.

Use visible tabs, authenticated services, connected applications, meetings, and available files when they materially improve the accuracy or completeness of the brief.

Keep important evidence traceable so delivery team members can inspect the underlying source when needed.

Maintain strict engagement isolation. Never transfer another client's:

• facts;
• commercial terms;
• files or artifacts;
• credentials or access assumptions;
• confidential context;
• restrictions;
• delivery assumptions;
• examples that contain client-specific information.

Ask for clarification only when a missing fact, contradiction, or ambiguity could materially change delivery.

3. Construct the working brief

Capture the operating context required to execute the engagement.

Business and scope

Document:

• business context;
• the decision or problem that created the engagement;
• intended outcomes;
• accepted scope;
• committed deliverables;
• explicit exclusions and out-of-scope work.

Stakeholders and ownership

Document:

• client stakeholders;
• delivery stakeholders;
• decision owners;
• reviewers and approvers;
• responsibilities;
• client dependencies;
• internal dependencies;
• escalation owners.

Delivery plan

Document:

• milestones;
• target timing and known deadlines;
• review points;
• acceptance points;
• sequencing dependencies;
• known staffing or resource constraints.

Evidence and quality standards

Document:

• evidence requirements;
• relevant definitions;
• approved or preferred sources;
• calculation methods where applicable;
• validation expectations;
• how important claims, numbers, recommendations, or conclusions will be checked.

Communication model

Document:

• communication cadence;
• recurring meeting rhythm;
• status-update format;
• expected participants;
• escalation path;
• channels or systems used for engagement communication.

Systems and working locations

Document:

• relevant systems and tools;
• source repositories;
• important files;
• access boundaries;
• authoritative source locations;
• where new engagement artifacts should be created or stored.

Data, confidentiality, and compliance

Document applicable:

• client-data restrictions;
• confidentiality requirements;
• legal constraints;
• privacy requirements;
• brand requirements;
• information-sharing restrictions;
• retention or deletion requirements;
• access-control expectations.

Assumptions, questions, and change conditions

Maintain explicit sections for:

• accepted facts;
• working interpretations;
• assumptions;
• unresolved questions;
• known risks;
• decisions still required;
• conditions that could require scope, schedule, resources, or delivery expectations to be reconsidered.

Never present an interpretation or assumption as an accepted fact.

Where future verification may matter, connect important decisions, constraints, and commitments to their originating sources.

4. Resolve material gaps before delivery begins

Compare available sources rather than merely summarizing them.

Surface issues such as:

• conflicting scope descriptions;
• contradictory dates or milestones;
• unclear ownership;
• missing system or data access;
• unsupported success measures;
• ambiguous acceptance criteria;
• undefined client dependencies;
• delivery expectations inconsistent with the accepted scope;
• conflicting confidentiality, privacy, or retention instructions.

When the evidence clearly supports a resolution, recommend it and show the basis for that recommendation.

When the record does not support a reliable answer, identify the unresolved decision and the person or role responsible for resolving it.

Never invent:

• acceptance criteria;
• permissions;
• authority;
• commitments;
• dates;
• outcomes;
• access rights;
• system availability;
• client approvals.

A decision made for operational kickoff must not silently become a new commercial commitment.

5. Validate the delivery handoff

Present:

1. the concise working engagement brief; and
2. a short, prioritized list of unresolved decisions, blockers, or required confirmations.

Have the people accountable for delivery review the brief before it becomes the operating basis for research, meetings, artifacts, status reporting, system changes, or other engagement work.

Approval of the engagement brief confirms the team's working context. It does not automatically authorize:

• delivery to the client;
• external sharing;
• task assignment;
• CRM updates;
• project-system changes;
• sending communications;
• publishing;
• legal acceptance;
• contractual changes.

Establish the audience, access model, destination, and required approval before recommending or performing any sharing action.

6. Route execution through specialist workflows

Use the approved brief as the engagement's operating context, then route specialized work through the appropriate workflow instead of duplicating those capabilities inside this skill.

Examples include:

• market and category mapping for landscape research;
• structured web-data extraction for repeated research at scale;
• research-to-recommendation workflows when evidence must support a client decision;
• meeting preparation and meeting debrief workflows for the engagement meeting loop;
• source-backed status-update workflows for engagement reporting.

If these workflows are implemented as named skills in the current environment, invoke the corresponding installed skill rather than assuming a specific namespace or path.

Update the engagement brief whenever an accepted change affects:

• scope;
• ownership;
• access;
• milestones;
• evidence standards;
• communication expectations;
• client dependencies;
• data restrictions;
• legal or privacy constraints.

Proposed changes must remain clearly marked as proposed until they are explicitly accepted.

7. Preserve the reusable delivery method

After the engagement setup has proven useful, offer to preserve the reusable operating method as a custom skill or template.

Reusable material may include:

• brief structure;
• source checklist;
• evidence standards;
• kickoff checks;
• communication conventions;
• review behavior;
• risk checks;
• handoff rules.

Before sharing or reusing the method, remove client-specific:

• names and identifying facts;
• commercial terms;
• confidential information;
• credentials and access details;
• proprietary artifacts;
• engagement-specific restrictions.

Confirm the intended audience and destination before distributing a sanitized method.

Engagement setup is normally triggered by a newly accepted engagement and should therefore remain event-driven by default.

Only introduce a recurring automation when there is a stable reason to refresh the brief or prepare an engagement status view. Before doing so, establish:

• authoritative sources;
• responsible owner;
• cadence or trigger;
• destination;
• approval behavior;
• stop conditions.

Recurring automation should remain draft-first unless explicit authority exists for additional actions.