The brief. That document you write in 20 minutes between calls, send as a PDF, and dig up six weeks later when everything goes sideways. Most agency disputes don't stem from poor execution. They come from an ambiguous brief. The team delivered what they understood. The client expected something else. Nobody's wrong. Everyone loses.
A commercial director at a 12-person agency once told me her team lost 34,000 euros in margin on a single e-commerce project because the initial brief didn't specify whether the product filtering module was in scope or not. One vague line in a four-page document. That's all it took.
Why most briefs fail
The problem isn't format. It's philosophy. Most brief templates work like admin forms: a few fields to fill in, an 'objectives' box, a 'budget' box, done. The client writes what they think they want, the project manager reads what they want to understand, and both parties sign off on two parallel realities.
An effective brief is a transcribed conversation. Not a wish list. The client asking for 'a modern website' has no idea what that implies technically. Your job is to turn that vague intention into something actionable. And that doesn't happen over email.
The 6 components of a solid brief
- The client's real problem, not their proposed solution: 'we want to redo our website' often means 'we're losing leads because our contact form is broken'
- Measurable success criteria: +20% mobile conversion rate in 90 days, not 'improve user experience'
- Explicit out-of-scope items: everything the project does NOT cover, in writing
- Technical and organizational constraints: existing stack, server access, client-side contacts, real deadlines vs. stated ones
- The validation process: who validates what, in how many days, how many feedback rounds are included
- Shared definitions: what counts as a 'page', a 'revision', a 'bug' in this specific context
We had an 8-page brief with moodboards, personas, benchmarks. Beautiful. And nobody had specified that the client wanted to manage content themselves. We delivered a custom site with no CMS. The client refused the delivery. That brief was worthless. -- Romain, Technical Director, 20-person agency, Lyon
How to run the brief session
Forget the online form sent by email. A proper brief is built in a 60-90 minute call or in-person session with real decision-makers on the client side. Not the project manager who relays messages. The CMO, the CEO, the person who has the problem and will sign the invoice.
The technique that works best: the five whys, applied to an agency context. Why this project now? Because we're launching an offer in September. Why September? Because of a trade show. Why is that trade show critical? Because 60% of our annual contracts come from it. The real driver isn't the website. It's the trade show. That changes everything about prioritization.
Brief and Agile: making them work together
There's a real tension between a fixed brief and Agile methods. In Scrum, the backlog evolves. But that doesn't mean the brief can stay vague. In fact, Agile demands an even more rigorous brief on objectives and success criteria, precisely because the 'how' will change.
My recommendation: a two-level brief. The strategic brief (vision, OKRs, major constraints) is locked before sprint 0 and can only change with a signed amendment. The operational brief (user stories, feature specs) is refined sprint by sprint. This separation keeps you agile on execution while maintaining a stable contractual framework. With Clynt, you can attach the validated brief directly to the project and flag any scope deviation in real time.
FAQ
How long should a client brief session actually take?
Budget at least 2 to 3 hours total: 60-90 minutes with the client, then an hour to rewrite and send back the brief summary. It's an investment that pays off the first time you avoid a change request.
What if the client refuses to spend time on the brief?
That's a red flag. A client who can't spare 90 minutes to define what they want will be the first to dispute the delivery. Make a 30-minute brief call a non-negotiable step before any proposal. If they refuse that too, seriously reconsider the project.
How do you handle brief changes during an Agile project?
Separate legitimate backlog evolutions (user story refinements) from strategic scope changes. The first is part of the Agile process. The second always triggers a priced amendment. Explain this distinction to the client before sprint 0, ideally in the brief itself.
What's the best tool to store and share the brief with the team?
Notion is popular for documentation in agencies, but it lacks direct links to project tracking and billing. Clynt lets you attach the validated brief to the project file and make it accessible to everyone from sales to developers, with no duplicate or outdated version floating around as an email attachment.