← All templates Collaboration template

Editorial review brief template for focused, usable feedback

Tell a reviewer what the draft is trying to do, where it stands, and which decisions their attention can genuinely improve.

What this template is for

Beta reads, supervisor feedback, developmental review, client approval, peer editing, stakeholder review, and any handoff where several kinds of change are possible.

Before you use the editorial review brief template

Freeze or identify the exact version being reviewed.
Decide which choices remain open and which constraints are already fixed.
Ask only questions whose answers can change the next revision.

The structure, part by part

1. Document and version

Name the piece, the exact milestone or file, its length, and the date it was frozen for review. A reviewer should never have to guess whether the link in front of them is still the target.

2. Reader and promise

State who the piece is for and what should change for that reader. Include necessary publication or genre context, but keep this short enough that the reviewer can hold it while reading.

3. Current stage

Name the stage - Outline, rough draft, structural revision, line edit, or proof - And what has already been reviewed. The stage tells the reader whether to question chapter order or catch a missing comma.

4. Questions for this round

Ask two to four questions tied to real decisions: where the argument becomes hard to follow, whether the counterargument is answered, or which of two openings better serves the reader. Avoid ‘What do you think?’

5. What is open and closed

List the decisions the writer can still change and those fixed by evidence, contract, policy, or a prior round. Reviewers can then spend effort where revision remains possible.

6. How to respond

Specify anchored comments, an editorial letter, a call, or answers under the review questions. Give the deadline, priority if time runs short, and who decides when reviewers disagree.

7. Known concerns

Share the places you already distrust without apologising for the whole draft. A known concern helps the reviewer test a hypothesis; it should not ask them to reassure you before doing the work.

The template itself

Copy this skeleton into a new document and replace each line. In Strut you can start a document from it directly - Pick Editorial review brief in the template selector when you create one.

Editorial review brief template

## Document and version
Document and version: [title, milestone, length, frozen date, and link].

## Reader and promise
Reader and promise: [primary reader] should [understand, feel, or do] after reading.

## Current stage
Current stage: [stage], with [work already completed] and [work deliberately deferred].

## Questions for this round
Questions for this round: [two to four decision-specific questions].

## What is open and closed
Open and closed: [changeable decisions] / [fixed constraints and reasons].

## How to respond
Response: [comment format], by [deadline], prioritising [most useful input]; [person] decides conflicts.

## Known concerns
Known concerns: [specific hypotheses the reviewer should test].

Worked example: turn a broad request into a review question

Too broad

Let me know what you think.

More useful

After the second section, can you state the central claim in your own words, and where - If anywhere - Did your version diverge from mine?

How to adapt this editorial review brief template

Use case	What to change
Developmental edit	Open structure, argument, reader promise, and missing material; close sentence-level polish.
Subject review	Ask about accuracy, missing context, terminology, and risk; identify editorial decisions outside the reviewer's role.
Proof or approval	Close structural questions and ask only for errors, required corrections, and explicit approval status.

Check the draft before you move on

The reviewer can identify the exact document and stage without asking.
Every question maps to a decision the writer can still make.
Deadline, response format, priority, and final decision authority are explicit.

Where this structure goes wrong

Sharing a draft with no stage, which invites proofreading during structural revision and structural redesign during proof.
Asking too many broad questions, which diffuses attention and makes different reviewers' responses hard to compare.
Hiding constraints until after feedback, wasting the reviewer on changes the writer was never able to make.
Leaving authority unclear when several reviewers disagree, so the draft becomes a compromise between incompatible readers.

Questions about this template

How many questions should I ask?

Two to four for one round. If everything is open, the manuscript probably needs an editorial assessment rather than several uncoordinated reader reactions.

Should reviewers see each other's comments?

Comment visibility depends on the goal. Independent first responses reduce group influence; a later shared discussion helps resolve conflicting interpretations. Decide the sequence in the brief.

What if I only want a general reader reaction?

You can still ask focused experiential questions: where attention dropped, what promise they expected after the opening, and what they believed at the end.

Do I need a separate brief for each round?

Yes, even if it is a revised copy. Stage, open decisions, questions, version, and deadline change, and the brief creates the boundary around that round.

Guides that go deeper

Version history and review workflows in Strut - Use milestones, version comparison, anchored comments, review snapshots, and resolution notes to keep one manuscript current through several review rounds.
How to give writing feedback writers can act on - Write feedback that names the editing level, describes the reader's experience, marks severity, and leaves the writer with a change they can actually make.
Developmental editing vs copyediting vs proofreading - See what developmental editing, line editing, copyediting, and proofreading change, when each belongs, and how to choose the right pass.