Project Brief Template: A Free, Copy-Paste Template (+ How to Fill Each Field)

A blank page is where good projects go to stall. You know roughly what the client wants, you sit down to write it up, and you spend the first twenty minutes deciding what a project brief even needs to contain. A template removes that friction: the same labelled sections, every time, so the only work left is filling them in. Below is one you can copy right now, plus a plain-language guide to what belongs in each field and why.

This post is the template itself. If you want the reasoning behind each choice — how to phrase questions, how to get clients to actually answer — that is a separate guide, linked at the end. Here, the goal is to hand you a working document. Copy the block, drop it into a doc, and you have a brief structure that covers the things projects actually trip over.

The project brief template

Copy everything in the block below. Each section has a one-line prompt in brackets telling you what to put there — delete the prompt as you fill it in. Thirteen sections looks like a lot, but most fields are a sentence or two; a real project brief for a small site fits on two pages.

PROJECT BRIEF

Project name:
Prepared by / date:

1. SUMMARY
[One short paragraph: what this project is, for whom, and why now.]

2. GOAL & SUCCESS METRICS
[The single outcome this project must achieve, and how you will know it worked.]

3. TARGET AUDIENCE
[Who actually uses the result. Be specific — "returning customers on mobile", not "everyone".]

4. SCOPE
In scope:  [What this project includes.]
Out of scope:  [What it explicitly does NOT include, so later requests become change orders.]

5. DELIVERABLES
[The concrete things you will hand over, e.g. 5-page marketing site, booking flow, style guide.]

6. KEY FEATURES & USER FLOW
[The main things a user does, in order. One line per step or feature.]

7. DESIGN & BRAND DIRECTION
[Look and feel, brand assets, references they like/dislike, any hard constraints.]

8. TECHNICAL NOTES & INTEGRATIONS
[Platform, hosting, existing systems, third-party tools this must connect to.]

9. CONTENT & ASSETS
[Copy, images, data, translations — and for each: who owns it and when it is due.]

10. TIMELINE & MILESTONES
[Launch date or key dates, plus any fixed deadline behind them (event, campaign, etc.).]

11. BUDGET
[Range or fixed figure, and what it does / does not cover.]

12. STAKEHOLDERS & SIGN-OFF
[Day-to-day contact, anyone else who reviews, and the one person who gives final approval.]

13. OPEN QUESTIONS
[Everything not yet decided. An honest list here prevents surprises later.]

That is the whole thing. The rest of this post explains the sections that get skipped or filled in badly — because a template only helps if the answers you put in it are the right kind of answer.

What each field is really asking for

Most of the thirteen sections are self-explanatory. Five of them are where briefs quietly go wrong — usually because the field gets a vague answer, or gets left blank because nobody wanted to have the conversation it forces. These are the ones worth getting right.

1. 1Goal & success metrics — not a feature list. The goal is the outcome, not the thing you are building. "A new website" is not a goal; "cut the booking calls reception handles by letting patients book online" is. Add how you will know it worked, even roughly, because a goal you cannot observe is a wish. This one field quietly decides every trade-off later — when two options compete, the one that serves the stated goal wins.
2. 2Scope — the "out" list matters more than the "in" list. Everyone fills in what is included. The section that saves projects is "out of scope": the things a reasonable client might assume are part of the job but are not. Writing "no multilingual content, no payment processing, no patient portal" now means a later request for them is a change order and a conversation, not a silent assumption and an argument. Scope creep almost always starts in the gap this line closes.
3. 3Content & assets — attach an owner and a date to each. Copy, photos, product data, translations: someone has to produce all of it, and it is usually a client employee who already has a full-time job. "We'll send copy later" is the phrase that strands more finished builds than any technical problem. Do not just list the assets — put a name and a due date next to each one, and treat a missing owner as a live project risk.
4. 4Stakeholders & sign-off — name the person who approves. Your contact is rarely the whole story. There is usually a second opinion-haver and, separately, a person who approves the final invoice and may not have seen anything yet. The most expensive feedback in agency work is a director reviewing the project for the first time in the last week. Name that person here, now, while it is cheap.
5. 5Open questions — an honest list, not an empty one. A brief with no open questions is not finished; it is pretending. Every project has things that are not yet decided, and writing them down turns them from future surprises into a visible to-do list with owners. An empty open-questions section usually means the unknowns are still there — just undocumented, waiting to surface at the worst moment.

The template is a skeleton — the value is in the filling

It is worth being honest about what a template can and cannot do. The template gives every project the same labelled slots, which is genuinely useful: nothing gets forgotten, and everyone knows where to look for the scope or the sign-off. But an empty template is not a brief. Its value is entirely in the quality of what you put in each slot.

This is why "just send the client the template" rarely works. Hand a busy client a thirteen-section blank form and you get back a logo, two sentences under "goal", and "TBD" under everything that required a decision. The structure was right; the answers were thin. Getting good answers is a different problem from having a good template — and it is the one that actually determines whether the brief is worth anything.

How to actually get the fields filled

A blank form and a real answer are not the same thing. The reliable way to fill a template is not to email it over and wait — it is to interview, one question at a time, so each answer sets up the next. "Who uses this?" leads to "what do they do first?" leads to "what stops them today?". A form asks everything at once and gets shallow replies; a conversation follows the thin answers until they are real.

The full method for turning answers into a finished document is covered in how to write a project brief clients actually complete, and the exact questions to ask are laid out in the web design questionnaire. Use this template as the destination; use those two as the way to fill it.

The template, filled in

Here is the skeleton above with real answers in it, for a familiar example — a three-location dental practice that wants online booking. Notice how each field carries a decision, not a placeholder:

For three complete briefs across different project types — a bakery site, a booking platform, and an internal tool — see the filled-out project brief examples.

Three ways this template gets misused

1. 1Filling it in alone, then asking the client to "confirm". A brief you wrote from memory and sent for a thumbs-up is your assumptions with a signature on them. The client skims, says "looks good", and the gaps surface in week four. The template should capture what the client actually said, drawn out by real questions — not what you guessed and they rubber-stamped.
2. 2Deleting the sections that feel awkward. "Out of scope", "budget", and "who signs off" are the fields people quietly drop because they force an uncomfortable conversation. Those are exactly the fields that pay for the whole template. If one genuinely does not apply, write "not applicable" so it is clear you considered it — do not remove it.
3. 3Treating it as a form to survive, not a decision log. The point is not to reach the bottom of the doc; it is to have made every decision the doc asks for. A field full of "TBD" is not a filled field. Better to have five sections with real answers and eight honestly marked open than thirteen that all say nothing.

Filling the template without the chase

However you fill it, the principle holds: the template is only as good as the answers in it, and good answers come from a conversation, not a blank form. This is the part ReqBrief automates. Instead of emailing this template and waiting, you send the client a link and an AI interviews them one question at a time — goals, audience, scope, stakeholders, content, constraints — following up on the thin answers, and hands you back a structured brief with these exact sections already filled in. The client finishes it in one sitting on their own schedule, and unlike a static form it adapts each question to the last answer. It is built for freelancers and small agencies scoping client work.

Copy the template, use it by hand, and it will already make your projects start cleaner. Fill it through a real interview instead of a blank form and it gets better still. Either way, the blank page — and the twenty minutes deciding what a brief needs — is a problem you only have to solve once.

Frequently asked questions