A project brief should turn the agreement and client inputs into a clear delivery instruction. Name the goal, intended audience, deliverable, constraints, approval owner and definition of done. Resolve contradictions before production. Record the approved version so the team can distinguish a decision from a discussion that is still open.
- Accepted scopeStart from agreed work.
- Client inputAdd relevant current context.
- Resolve contradictionsRoute differences to responsible owner.
- Approved briefGive delivery a clear instruction.
The intake form collects information; it does not automatically become a production brief.
What is the brief deciding?
A brief is the point where information becomes an instruction. The proposal describes agreed work, intake supplies context, and the brief tells the delivery team what to produce. Copying an intake form into a task does not necessarily complete that translation.
Name the person responsible for preparing the brief and the person who can approve it. Those roles may sit inside the agency or with the client, depending on the engagement. Make the arrangement explicit rather than assuming that everyone in a kickoff meeting can approve the same decisions.
Include what production needs
| Brief element | Question it answers | A sign it needs clarification |
|---|---|---|
| Goal | What should this work accomplish? | Several conflicting outcomes |
| Audience | Who is it for? | Only a broad demographic label |
| Deliverable | What will the team produce? | Format or quantity unresolved |
| Constraints | What limits the work? | Unclear dependencies or exclusions |
| Evidence and assets | What can the team rely on? | Unapproved claims or missing files |
| Approval | Who decides it is ready? | Several contacts with no final owner |
| Completion | What makes this deliverable done? | “Make it better” without criteria |
Do not add detail merely to make the brief look complete. Resolve the questions that could lead two reasonable team members to produce different work.
- Goal and audienceClarify intended work and recipient.
- Deliverable and constraintsSpecify output, limits, and dependencies.
- Evidence and assetsIdentify approved sources and files.
- Approval and completionName final owner and definition of done.
Focus on questions that could lead reasonable team members to produce different work.
Reconcile the source records
Compare the brief against the accepted scope and the client's current input. A client may request an extra deliverable in intake or describe an audience that differs from the proposal discussion. Flag the difference and route it to the responsible person.
- Compare sourcesCheck scope against current input.
- Flag differenceDo not add it quietly.
- Responsible decisionChoose scope change or later phase.
- Record outcomeKeep source links and decision.
The brief should not become a second competing contract.
For an illustrative content engagement, the accepted scope might cover one article while the intake requests a full email sequence. The brief should not quietly include both. Confirm whether the added work belongs in a scope change or a later phase, then record the decision.
Keep links to the source agreement, relevant intake answers and approved assets. This helps the team verify a question without treating the brief as a second, competing contract.
Define the approval event
An approval needs an identifiable version and an explicit decision. A comment such as “looks good so far” may support continued discussion without approving the final instruction. Use wording and a record that your team and client understand.
- Identified versionState what is being approved.
- Explicit decisionUse agreed approval wording.
- Authorized approverRecord who decided.
- Open conditionKeep missing assets visible.
A general positive comment may support discussion without approving the final instruction.
Capture the approver, the version, the time and any conditions. If approval depends on a missing asset, show that dependency as unresolved. The project owner can decide whether unaffected work should begin, but the dependency should not disappear from the record.
Control changes after approval
When a brief changes, identify what changed and which work it affects. Do not rely on team members noticing that a shared document was edited. Notify the delivery owner and decide whether previous approval still applies.
Minor clarification and a changed deliverable are different events. Your scope change process should handle requests that alter commitments. A brief revision can carry the approved result into production after that decision is made.
Use the brief at review
The approved brief should support review of the finished work. Compare the deliverable with its goal, constraints and definition of done before sending it to the client. If reviewers keep introducing requirements that were absent from the brief, investigate whether the initial instruction or approval process is incomplete.
Track avoidable clarification requests and work restarted because instructions changed. These are useful signals about the brief. A long document and a quick approval are not proof that production received a usable instruction.
Questions and answers
Is the intake form the same as the project brief?
The intake form collects client information. The brief translates relevant information and the accepted scope into a delivery instruction. They can live in one system, but somebody still needs to resolve contradictions and approve the instruction before production uses it.
What counts as approving a brief?
An explicit decision about an identified version by the person authorized to approve it. Record any conditions and unresolved inputs. A general positive comment can be ambiguous, so agree on what the approval event means before the project starts.
Do small brief edits need another approval?
Assess whether the edit changes the approved instruction. A corrected typo may not; a different audience, claim or deliverable may. Define that threshold with the responsible owner and make material changes visible to the people carrying out the work.