How to Write a Project Brief in Scoutzera

Where the project brief lives

When you open a project in Scoutzera, the brief sits on the project detail page — below the project header and above the video grid. It's always visible, always editable, and always the first thing your editor sees when they open your share link. This placement is intentional: the brief is the context layer. Everything else in the project — the videos, the per-video notes — lives below it.

The brief uses a rich text editor that supports bold, italic, bullet lists, numbered lists, links, and inline code. Click anywhere in the editor area to start typing; there's no separate Edit mode to switch into. As you type, it auto-saves — you'll see "Saving..." appear briefly, then "Saved" once it's done. There's no Save button to click and no risk of losing work if you close the tab after seeing "Saved." When your editor opens the share link, they see the brief read-only, formatted exactly as you wrote it: bold text is bold, lists are lists, links are clickable.

What belongs in the project brief vs. per-video notes

The project brief is for information that applies to all videos in the project: the overall tone and brand voice, the technical deliverable specs, the deadline, the recurring style rules, what to avoid. Per-video timestamped notes are for information that applies to one specific moment in one specific video: this cut, this b-roll request, this audio fix at 3:12. The two layers serve completely different purposes and are read at different times — your editor reads the brief once, at the start, to understand the job. They work through the per-video notes sequentially while editing.

A common mistake is putting everything in timestamped notes. Your editor ends up scrubbing through Video 1 to find the deadline that applies to all five videos, or hunting through every annotation to find the style rule about transitions. Anything that's true of the whole project — not just one moment — belongs in the brief.

What to actually write in the brief

Start with the deliverables: list every output your editor needs to produce, with the format and spec for each. "3 videos — long-form YouTube (16:9), vertical cut for Instagram Reels (9:16 under 90 sec), horizontal short (16:9 under 60 sec)" is specific enough that your editor can plan their work without asking. Add the deadline next, and bold it so it doesn't get buried: "Deadline: June 14. Please have the YouTube cut ready for review by June 12."

After deliverables and deadline, cover tone and style. "Upbeat but not frantic. Match the energy of the hook, not the energy of an infomercial." is a single sentence that saves a revision round. Follow it with your style guide rules: which transitions are allowed, what the lower-thirds template is, how you handle scene changes. Then add a "what to avoid" section — this is where you list the things you've had to correct before. "No stock music from the free tier of Epidemic Sound — we've had copyright strikes from those tracks before." Finally, link to your assets: "B-roll and music are in the shared drive folder linked here: [link]."

Formatting that helps

Use a numbered list for ordered deliverables or steps where sequence matters, and bullet lists for unordered style notes. Bold the deadline so it's unmissable — most editors scan a new brief quickly on first read and bold text is what catches the eye. Use separate headings or a visual separator to divide sections: Deliverables, Style Notes, Assets, Deadline. A well-structured brief reads in under two minutes on first pass and stays useful as a reference while editing.

Links to drive folders, reference videos, or brand guidelines belong in the project brief — not in a Slack message that gets buried. If your editor needs to find the brand kit three days into the project, the brief is the one place they'll know to look. Keep those links current: if the drive folder moves, update the link in the brief.

Updating the brief mid-project

If something changes — the deadline shifts, a new deliverable gets added, the client changes the tone direction — update the brief directly. It's a live document. Your editor always sees the current version when they open the share link, so there's no need to send a separate "heads up, the deadline changed" message alongside a doc update. Just update it and optionally drop a note in whatever channel you use to say "updated the brief, check the deadline section."

There's no version history in the brief, so if you're removing something important, consider leaving it with a strikethrough and a short note rather than deleting it outright. "~~Deliver a vertical cut~~ — client removed this deliverable on Jun 9" tells a different story than a blank space where the requirement used to be. Your editor may already have started work on that cut; the strikethrough tells them to stop.