Client Briefing: The Template and the Questions That Prevent Rework

Rework almost always starts with a sentence said with confidence and understood differently: "I want something modern," "it's urgent," "just like the competitor's." A good briefing exists to swap those sentences for answers that two people read the same way. It doesn't have to be long. It has to ask the questions the client hasn't asked themselves yet.

Below are the questions by block, how to run the conversation, how to turn the answers into scope and tasks, and how to close with a sign-off. If you'd rather start from a ready-made document, the project briefing template brings all of this together in a fill-in format.

Why a shallow briefing is expensive

A shallow briefing doesn't show up as a problem at first. It shows up in the third round of revisions, when the client says "that's not what I imagined." At that point, the cost is yours: hours redoing work, a blown deadline, and an uncomfortable conversation about who misunderstood.

Almost always, nobody misunderstood. The question that would have revealed the difference simply wasn't asked. The briefing exists to ask it early, when changing your mind costs a conversation and not a redone project.

The questions, by block

Organize the conversation into blocks. Each one covers a typical source of rework. You don't need to ask every question on every project; you need to ask the ones the project requires.

1. Context and reason

• What problem or opportunity made you look for this work now?
• What happens if nothing is done in the next three months?
• What has been tried before, and why didn't it work?
• Who else is involved in this decision?

The second question is the most revealing. If the answer is "nothing much," the project is probably not a priority and will slip at every approval stage.

2. Goal and expected result

• How will you know, six months from now, that the project worked?
• Is there a number you want to move (orders, leads, time spent, complaints)?
• What would a bad result look like, even if the work were delivered?

3. Audience and users

• Who will use or see what we deliver?
• What does that person need to be able to do, and what gets in their way today?
• Is there anything the audience definitely dislikes or doesn't understand?

4. Scope: what's in and what's out

• What needs to be ready in the first delivery and what can wait?
• What is explicitly not part of this work?
• Are there parts that depend on third parties (a vendor, a system, a department)?

The question about what's out prevents more arguments than any contract clause. Write down the answer, even if it seems obvious.

5. References and constraints

• Are there examples of what you like and don't like? Why?
• Are there rules we need to respect: brand, legislation, internal standards?
• Are there tools, materials, or accounts that already exist and should be used?

Always ask for the "why" behind references. "I like site X" doesn't help; "I like how site X shows the price right at the top" does.

6. Deadline, budget, and decision

• Is there a fixed date? What drives it (an event, a launch, a contract)?
• What's the available investment range?
• Who approves each stage, and how long do they usually take to respond?

The last question is the one that delays projects the most in practice. A deadline that depends on slow approval needs two schedules: yours and that of whoever approves.

How to run the meeting

The briefing meeting is a conversation, not an interrogation. A few practices help get better answers.

• Send the questions beforehand. Some answers require checking with someone else. Whoever arrives prepared answers better, and the meeting is left for what's ambiguous.
• Ask "why" twice. The first answer is usually the solution. The second reveals the need.
• Ask for a concrete example. "Tell me about the last time this caused a problem" is worth more than a general description.
• Write while you talk. Preferably in a document the client can see. Correcting a sentence on the spot avoids correcting a project later.
• Bring in the decision-maker. A briefing with someone who doesn't approve the delivery becomes a briefing redone at approval time.
• End by repeating it back. Read the five main decisions out loud and ask for confirmation.

Warning signs during the conversation

The client says	What may be behind it	Question to ask back
"You decide, I trust you."	They haven't formed criteria yet and will form them when they see the result	"What would be the worst possible outcome for you?"
"It's simple, it'll be quick."	Expectations for time and price below what's realistic	"Walk me through the steps the way you imagine them."
"It has to be just like the competitor's."	Lack of clarity about what sets them apart	"What do they do better than you, and what do you do better than them?"
"The board will look at it later."	The real decision-maker isn't in the conversation	"Can we include that person in a short meeting before we start?"

From briefing to scope and tasks

A briefing that sits in a forgotten document doesn't prevent rework. The value appears when the answers become scope, and the scope becomes work with an owner and a due date.

Step 1: write the scope on one page

Gather the expected result, what's in, what's out, the deliverables, the dependencies, and the dates. Send it to the client for written confirmation. An "I understood this, is it right?" email already protects both sides.

Step 2: break it into deliverables and then into tasks

Each deliverable is a result the client can see and approve. Each deliverable is split into tasks with an assignee, a date, and, when necessary, an acceptance criterion. If the briefing ended up as meeting minutes, notes, or a text document, AI can help make that first breakdown: the post how to turn a document into a project plan with AI shows the way. Review the result, because a breakdown made by AI is a draft, not the decision.

Step 3: record decisions and open items

Not everything gets resolved in the meeting. Keep a list of open items with an owner and a date (the client appears on it too). Open questions, after two weeks, tend to become delays.

Step 4: put changes in the same place

Scope changes are normal. What can't happen is for them to happen through loose messages. Every change goes on the list with its impact on time and cost, and the client confirms. This avoids the "but I already asked for that" argument.

Receiving the briefing through a form

For repeatable services, the first contact can be a form with the essential questions. The client answers on their own time, you arrive at the meeting with the basics settled, and the conversation focuses on the doubts. Conditional questions help: someone who picks "website" sees website questions, and someone who picks "campaign" sees the campaign ones.

Closing with a sign-off

The briefing is the start of a cycle that ends in sign-off. Define, still in the meeting, how the delivery will be approved: who approves, within how many business days, how many rounds of revisions are included, and what happens if there's no response.

A written, simple, dated sign-off settles future disputes. Forms can collect sign-off with a simple electronic signature, which records name, IP, date and time, and a hash of the content. This type of signature is not ICP-Brasil (Brazil's official digital certificate standard), so for contracts that require a digital certificate, use the appropriate tool. For routine delivery approval, the record is usually enough.

Checklist for a complete briefing

• The problem and the reason for now are written down.
• There is a measurable result, or at least an observable one.
• The audience is described along with what they need to do.
• What's out of scope is recorded.
• References come with the reason they were chosen.
• Deadline, investment range, and approver are defined.
• The client confirmed the summary in writing.
• The scope became deliverables and tasks with an assignee and a date.

If any item is blank, the doubt exists, it just wasn't voiced. It's better to find it in the meeting than in the third round of revisions.