Client Brief Template: Goals, Audience, Scope and Approval

A client brief template turns a client-supplied business need into a shared starting point for delivery. It captures why the engagement exists, who it should serve, what success would look like and which boundaries or decisions must be respected.

The brief is not a content brief and it is not automatically a contract. It should reflect the client’s own context and receive explicit client confirmation. Commercial terms, legal obligations and professional requirements belong in the documents and review processes authorized for the engagement.

Start with the business need

Describe the situation that prompted the work before proposing a solution. Record the current condition, affected people or operations, available evidence and the decision the client needs to make. “Build a portal” is a requested output; “reduce repeated manual requests from approved partners” is closer to a business need that can be explored.

Ask what happens if nothing changes and why the work matters now. The answer may reveal timing, risk, opportunity or dependency that should shape scope. Keep assertions traceable to client-provided evidence, and label beliefs that have not yet been tested.

Use a project intake form template when requests enter through a broader portfolio process. The client brief can then deepen the selected request without losing its original owner or rationale.

Define goals and decision criteria

Convert the need into a small set of outcomes. Each goal should describe a meaningful change rather than an activity the team can complete. Pair it with evidence the client will use to judge progress, the person who owns that judgment and the date or decision point at which it will be reviewed.

Avoid invented precision. If no baseline exists, state that measurement design is an early task. Do not promise an outcome that depends on adoption, policy, market behavior or client-controlled work outside the delivery team’s authority.

Rank goals when they compete. Speed, cost, flexibility and depth cannot always be maximized together. A brief should expose the client’s preferred tradeoff and the approver authorized to change it.

Identify the audience and context

Name the people whose behavior, work or experience the engagement intends to affect. Describe roles, needs, environments, access requirements and relevant differences without turning assumptions into fictional personas. Distinguish primary users from buyers, approvers, administrators and people indirectly affected.

Record what evidence exists: interviews, service records, analytics, observation or prior work. Note groups that are missing. Do not copy unnecessary personal data into the brief, and keep sensitive client or participant evidence in approved storage with appropriate access.

If discovery is still needed, use consulting discovery questions to plan a structured conversation. Questions should clarify the business context rather than steer the client toward a preferred solution.

Copy this client brief template

CLIENT BRIEF

Client / engagement / version / date:
Client sponsor / brief owner / delivery lead:

BUSINESS NEED
Current situation:
Evidence supplied:
Why now / consequence of no action:
Decision this work should support:

AUDIENCE
Primary audience / context / needs:
Other affected stakeholders:
Evidence gaps / excluded groups:

OUTCOMES
Goal / evidence of progress / owner:
Priority and accepted tradeoffs:
Non-goals:

SCOPE AND CONSTRAINTS
In scope / out of scope:
Required deliverables:
Budget, timing, policy or technology constraints:
Dependencies / client-supplied inputs:

GOVERNANCE
Working team / responsibilities:
Review stages / acceptance criteria:
Named approver / approval method:
Change route / unresolved questions:

Keep a version number and approval date. The brief should remain concise enough to review in one sitting while linking to controlled evidence and detailed specifications rather than duplicating them.

Set scope and explicit non-goals

List the capabilities, audiences, channels, regions and delivery phases included. Then state non-goals in equally concrete language. “Reporting excluded” is weaker than “No custom executive dashboard is included; the team will provide the agreed export only.”

Separate desired features from required outcomes. A client may suggest an implementation because it is familiar, but discovery may reveal a safer or simpler route. Preserve the request, the underlying need and the current decision status so later readers understand what was approved.

Map deliverables to scope and acceptance criteria. A marketing campaign brief template illustrates how one downstream team can translate an approved client need into execution detail. The client brief itself should remain broader and should not silently create contractual commitments.

Check scope from both directions. Ask whether every included activity supports an approved outcome and whether every required outcome has sufficient work, evidence and ownership behind it. Remove attractive extras that do not serve the need, and flag outcomes that depend on work nobody has included. This simple trace exposes gaps before schedules and estimates make them harder to discuss.

Record constraints, dependencies and assumptions

Constraints may include a fixed event, approved budget, existing platform, brand rule, accessibility requirement, data restriction or client policy. Identify who confirmed each constraint and whether it is mandatory, preferred or provisional. Route legal, security, regulatory and professional questions to the client’s qualified owners.

Dependencies need owners and due dates. Examples include access to systems, participant recruitment, source files, decisions, procurement or third-party work. State the effect of late or incomplete inputs instead of assuming the delivery team can absorb every delay.

Maintain an assumptions list with a validation owner. An assumption should never become “agreed” merely because it survived several drafts without comment.

Document known decision deadlines, not only delivery dates. A client may need to choose a market, provide access or confirm a policy interpretation before the team can proceed. State the latest useful decision date and the effect of delay. Where the consequence depends on commercial terms, reference the approved agreement instead of creating a penalty in the brief.

Also record constraints that protect quality. Required review time, accessibility checks, participant safeguards and evidence standards are not optional padding. If the requested timeline would remove a required check, escalate the conflict to the owner with authority to change scope or timing; do not quietly compress the control.

Establish roles and approval rights

Name the client sponsor, day-to-day owner, subject-matter reviewers, delivery lead and final approver. Clarify who can provide feedback, who consolidates it and who can authorize changes to outcome, scope, cost or schedule. A crowded stakeholder list without decision rights creates delay rather than governance.

Define review stages and the artifact expected at each one. Approval should identify the version, approver, date and any conditions. Silence, meeting attendance or access to a shared document should not be interpreted as approval unless an authorized process explicitly says so.

Use a decision log template for material choices made after kickoff. Link the decision to the brief section it changes and notify affected owners.

Resolve gaps before delivery starts

Run a brief review with client and delivery owners. Ask whether the business need is evidenced, audience is understood, scope is feasible, dependencies have owners and approval rights are clear. Convert missing facts into named discovery tasks rather than filling them with plausible language.

Flag contradictions directly. If the requested deadline conflicts with review time, or the desired outcome conflicts with a mandatory constraint, present options and consequences to the authorized decision-maker. Do not hide the conflict inside a generic risk paragraph.

Approve the brief before substantial work begins. A limited discovery phase can start with an intentionally provisional brief, provided its boundaries, decision date and permitted spend are explicit.

Run a short playback in the client’s language: “Here is the need we heard, the outcome we will pursue, the people affected, the work included and the decisions you retain.” Invite correction before requesting approval. This reveals semantic agreement more effectively than asking whether a dense document “looks fine.” Record corrections in the brief, not only in meeting chat.

Check that every open question has an owner and deadline. If an answer could materially change feasibility, price, risk or outcome, identify the work that must pause pending resolution. The brief should make uncertainty governable, not make it disappear through polished wording.

Use Kuno in client discovery responsibly

Client discovery can contain strategy, customer information, personal data or confidential commercial details. Record only with clear authorization, notice to participants and handling that follows the parties’ agreements and applicable policies. Confirm whether external tools are permitted before uploading source material.

Create a reviewable draft from an authorized client conversation. Kuno can help capture consented discussion and organize draft notes, while client and delivery owners verify every requirement and decision. Explore Kuno

Treat generated summaries as working material. Check names, numbers, commitments, exclusions and implied approvals against the recording and controlled documents. Apply human judgment and remove unnecessary confidential details before sharing.

Maintain the brief through change

At kickoff, restate the approved need, outcomes, boundaries and decision route. During delivery, review the brief when new evidence changes an assumption or when the client requests a material shift. Do not rewrite history: preserve versions and link approved changes.

Use a risk register template to track uncertain events separately from confirmed scope changes. This keeps a possible dependency failure from being confused with a decision that has already altered delivery.

At close, compare the delivered work with the approved brief and changes. Record unresolved outcomes, client-owned follow-ups and evidence still needed. The brief then becomes a reliable explanation of the engagement, not merely a sales document abandoned after kickoff.

Keep client context connected to accountable action. Kuno supports authorized capture and draft follow-ups; people on both sides confirm meaning, protect confidential information and approve the record. See Kuno

FAQ