How to Turn a Client Call Into a Project Brief on Mac (Template)

To turn a client call into a project brief, work from the call notes and transcript and write five things: the purpose, the work to deliver, what is out of scope, the dependencies and dates, and the questions still open. The template below covers those sections, followed by a filled example. Rebrief for Mac records the call and writes the transcript and notes after it ends; you edit the brief and confirm the gaps before anyone treats it as agreed work.

This matters most when the client explained the project across a long call and a colleague now needs to know what to build. A recap tells them what was said. A brief tells them what to plan, what is blocked and what nobody has decided yet.

Project brief template

Paste the relevant notes into these sections and edit them for the person doing the work. Leave missing details as questions. A short reference to the relevant exchange is usually enough; you don't need to attach the whole transcript.

• Project:
• Status: Draft for confirmation
• Source call and date:
• Purpose: Who needs this, and what should change for them?
• Work to deliver: What did we agree to include?
• Outside this release: What did we explicitly leave out?
• Dependencies and timing: What do we need, from whom, and by when? Which dates are targets, and which are agreed?
• Questions before work starts: What must the client or delivery team decide?
• Next step: Who will resolve the first blocker?

If you haven't had the discovery conversation yet, start with discovery call notes for freelancers. Those notes decide whether to quote; the brief comes after the work is agreed.

Start from the call notes and transcript

During the call, focus on questions that clarify the work and leave the exact wording to the recording. Ask for permission first and follow the client's recording rules; tell everyone you're recording, as recording laws differ by place. Rebrief records your microphone and the call audio with no bot in the call, so it works for Zoom, Teams, Google Meet and Slack calls alike. For huddles, see how to record a Slack huddle on Mac. Free recordings stop at 15 minutes, so use the one-time unlock before relying on it for a longer call.

When processing finishes, open the meeting notes. Rebrief sorts the conversation into key points, decisions, action points and open questions. Read them with your colleague's next task in mind: what are they being asked to produce, what must happen first, and what can't they decide yet?

Copy the notes as Markdown into your document editor, as described in Rebrief's support guide. Give the document the project name and the call date, and keep the transcript open beside it.

Turning the transcript into requirements

Start with one sentence on the result the client wants, then name the deliverables the conversation supports. "A website form for workshop requests" gives a developer a starting point; "improve bookings" leaves them guessing.

Use the transcript for detail the short notes leave out. When a discussion moves from a big idea to a smaller first release, carry the final choice into the brief. Put explicit exclusions next to the deliverable, especially when the client spent time on something they later deferred.

If you can't find the exchange, ask Rebrief: "What did we agree to include in the workshop form, and what did we leave for later?" Ask shows the source lines under its answer, and selecting one opens the meeting at that moment. Read the replies around it, and check the audio if the speaker or wording is unclear.

List dependencies and dates honestly

Your colleague needs to see what could hold up the work. Look through the action points and open questions for content, access, approval or anyone else's input. Put each dependency beside the person expected to provide it, and the date if one was agreed.

Keep offers and deadlines accurate. "I can send the copy" needs confirming before you give the client a delivery date. "We want this for the October campaign" is a target; it doesn't mean your team promised an October release. If timing depends on inspecting the existing website, say so.

Worked example: from client call to brief

This excerpt and the completed brief were written for this article. They show the editing process, not a Rebrief result.

Client: "We need a form for workshop requests: name, email, workshop, and number of places. Staff will still confirm by email. No payments or instant booking confirmation. A manual CSV download is enough; scheduled emails can wait. I'd like it ready for the October campaign. I can send the workshop list and copy, and our content lead must approve the wording."

Consultant: "I'll inspect the site and propose a date once I have access."

After checking those details against the source, the brief could read:

Your colleague can now plan the form and the download without estimating an automatic email report, and can see the first blocker: site access. Keep the call reference with the brief, so the reasoning is easy to find if the client asks why scheduled emails were left out.

Check the brief and send the open questions

Before sharing the brief, compare the scope and dependencies with the transcript. Pay most attention to quantities, dates and who agreed to do what. Remove anything you added from habit, or label it as a proposal.

Ask the client to confirm the points that affect your colleague's next step. In the example, site access and the CSV details come before a reliable estimate. If a reply changes the work, update the brief with that reply as its source, and keep the delivery date open until someone actually agrees to it.

Open your latest client recording in Rebrief, copy its notes, and write the first version of the brief. Give your colleague the scope and the next open decision together, so they know what they can act on.