Before asking for meeting feedback, say what can still change

When you send meeting notes for review, state what can still change. A useful request sounds like this: “By 15:00 tomorrow, correct factual errors in the decision, owner, date or condition. The product choice is settled; a proposal to change it needs a separate request to the decision owner.”

That sentence does three jobs. It gives the review an end, tells people where mistakes matter and separates correcting the record from reopening the decision.

Separate three kinds of feedback

Most review threads become messy because every response arrives as “feedback.” In fact, post-meeting comments usually belong to one of three categories.

Correction

The record is factually wrong.

The due date was Thursday, not Friday.

Priya owns the security review; Leon owns the rollout plan.

Corrections should update the record when the available evidence supports them.

Clarification

The record is accurate but too ambiguous for someone to act on safely.

“Pilot customers” means the five accounts listed in the launch brief, not every beta account.

Clarifications add a boundary that was present in the discussion but missing from the draft. If the meeting never established that boundary, the comment may actually be a new proposal.

Change request

The commenter wants a different decision, scope, owner or date.

We should include every beta account in the pilot.

That may be a good idea. It is not a correction. Route it to the person who owns the decision and record the outcome separately.

Put the boundary in the review request

“Please review” makes the recipient infer the assignment. A precise review request names:

• the deadline: when the draft becomes final;
• the review surface: decisions, owners, dates, conditions and unresolved questions;
• the decision state: open, conditional or settled;
• the finalizer: who resolves conflicting comments and closes the draft;
• the change route: where a new proposal should go.

For example:

Review by Tuesday at 15:00. Check the launch decision, its two conditions, action owners and dates. Mira will resolve corrections and finalize the record. The launch approach is settled; send any proposal to change it to Leon as decision owner.

This is not bureaucracy. It removes five decisions from every reviewer and prevents the note owner from becoming an accidental appeals court.

If the draft itself still needs formal correction, use a short, named window rather than waiting for unanimous approval. Meeting minutes need a finalizer and an exact correction deadline.

Use evidence to settle factual disputes

Two people can leave the same meeting with different memories. Do not settle that conflict by seniority, speed or the confidence of the comment.

Check the strongest available evidence in order:

1. the explicit read-back at the end of the meeting;
2. notes or a transcript from the relevant moment;
3. the decision owner's confirmation of what they decided;
4. the action accepted by the named owner immediately afterward.

Evidence may reveal that the meeting never produced a clear decision. If so, write that honestly. Replace a false conclusion with an unresolved question, name who must answer it and set the return point.

Do not retrofit certainty because the team has already started work. A clean-looking record that misstates the meeting is more dangerous than a visibly open issue.

Do not let wording preferences block finalization

A reviewer may prefer “evaluate” to “assess,” a longer summary of their argument or a different order for the background. Those edits can improve prose, but they should not hold operational fields open indefinitely.

Give priority to changes that affect action:

• the decision itself;
• the reason or evidence needed to interpret it;
• an owner or due date;
• a condition, exception or limit;
• an unresolved question;
• the point when the decision may be reviewed again.

Accept a wording edit when it makes one of those fields more accurate. Decline it when it merely makes the minutes sound more like the reviewer's personal account and changes no operational meaning.

Reopen a decision through a separate route

Sometimes feedback contains evidence that genuinely changes the choice. The boundary is not meant to suppress that. It is meant to make the change visible.

A request to reopen should state:

• the settled decision;
• the new evidence or failed assumption;
• what work should pause, if any;
• who has authority to reconsider it;
• when the reconsideration will happen.

Keep the original decision active until the authorized owner changes it, unless continuing would create a legal, safety or irreversible risk. Record the objection without quietly editing history. A disagreement can remain in the record without pretending the decision never happened.

When a decision does change, add a new entry that says what superseded the old one. Do not rewrite the old minutes to make the team look consistent in retrospect.

Close the loop visibly

At the deadline, the finalizer should publish a short resolution note:

• corrections accepted;
• clarifications added;
• wording suggestions declined because they did not change meaning;
• change requests routed to the decision owner;
• remaining disputes and who will resolve them.

Then mark the minutes final. Late evidence can still trigger a correction or a new decision, but it should arrive through a visible change rather than leaving the original draft permanently provisional.

Scripta starts after the call: bring the notes or transcript, then keep editable and final meeting minutes, decisions, action items and contextual comments together. The product can preserve the record and discussion, but the team still has to define the review boundary and the authority behind it.