Send a meeting correction as a change note, not a second recap
A correction should make one part of the meeting record clearer, not force everyone to compare two full recaps and guess which sentences still apply.

When a meeting recap contains a wrong owner, date or decision, correct the record with a change note: identify the exact statement, show the old and new values, explain the reason, and name any work that changes.
Then update the shared meeting record. Do not send a second full recap and expect people to compare it with the first one.
Two nearly identical recaps create a new problem. Some readers keep the first. Others forward the second. A few notice the difference but cannot tell whether the rest of the document changed too. The correction is technically available, yet the team now has two candidates for the truth.
Separate a correction from a later change
Before writing the note, decide which event occurred.
A correction means the recap described the meeting inaccurately:
- the owner was Priya, not Leon;
- the agreed date was 16 October, not 18 October;
- the room approved a pilot, not a full rollout;
- a condition attached to the decision was left out.
A later change means the recap was accurate when written, but circumstances moved afterward:
- Priya handed the task to Leon the next day;
- a supplier delay moved the date;
- new evidence caused the decision owner to pause the pilot;
- legal review added a condition after the meeting.
Do not edit history to make a later event look as if it happened in the room. Preserve the meeting outcome and add a dated follow-up that names what changed afterward.
This distinction is the same one that protects final meeting minutes from silent rewriting. The question is simple: was the old record wrong, or did the world change after it was right?
Write the smallest complete change note
A useful correction is narrow enough to scan and complete enough to act on.
Use five lines:
Meeting: Pricing launch review (12 October)
Corrected field: Action-item owner
Was: Leon will send the revised pricing copy by 16 October.
Now: Priya will send the revised pricing copy by 16 October.
Reason and effect: The recap assigned the task to the wrong person. Priya confirmed ownership; Leon has no action on this item.
The format removes three common ambiguities. Readers can see exactly what changed, whether the date moved, and what they should stop doing.
Avoid messages such as “Small correction to yesterday’s notes” followed by a replacement paragraph. A replacement paragraph still asks the reader to locate the old passage and compare it word by word. Label the field and show both values.
For a wording correction that changes no work, say so explicitly: “No owner, date or next step changes.” That sentence prevents people from reopening tasks merely because a message arrived.
Correct the operational fields first
Not every error deserves the same interruption.
Send a prompt change note when the error can alter somebody’s next move:
| Field | Why it matters |
|---|---|
| Decision | People may follow an option the room did not choose. |
| Owner | The real owner may wait while the wrong person receives reminders. |
| Due date | Work may appear late or start too slowly. |
| Scope | A pilot can quietly become a rollout, or the reverse. |
| Condition | Work may begin before an approval or dependency is satisfied. |
| Status | An open question may be mistaken for a settled answer. |
A typo in a background paragraph can often wait for the record to be edited. A wrong owner should not. Prioritize the fields that can send work in the wrong direction.
Keep one link trustworthy by updating the record itself: decisions, task state, files and discussion should change together instead of producing another recap version.
The practical test is not “Is the recap perfect?” It is “Could this error change a decision, commitment or handoff?” If yes, make the correction visible.
Update the record and the work it controls
A correction message is a notification, not the final storage place.
If the shared minutes still name Leon while chat says Priya, the conflict remains. Future readers will find whichever version their search returns first. The authoritative record and every affected operational field must agree.
After sending the note:
- correct the minutes or recap;
- update the action item, decision, owner or due date that people use;
- add a dated comment explaining the correction when the reason will matter later;
- notify the people whose work changed;
- close or replace any duplicate task created from the wrong version.
Scripta keeps meeting minutes, decisions, action items and comments with the source meeting. That makes it possible to correct the visible record and the affected work in one place. Scripta does not decide whether a change is a factual correction or a later development; the meeting owner must make that distinction and explain it.
If the correction changes an owner, preserve the acceptance step described in an action-item handover. Replacing a name in the record does not prove the new owner saw or accepted the commitment.
Notify only the people whose next move changed
The whole attendee list does not need every punctuation fix. A correction should reach the people who:
- own or review the affected work;
- rely on the corrected decision;
- received the incorrect recap;
- maintain a plan, file or customer message that contains the old value;
- need to stop work that the incorrect version started.
For a material correction, use a subject line that is searchable:
Correction: Pricing launch review, owner changed from Leon to Priya
Do not hide the change behind “Updated notes” or “Latest version.” Those labels say that something moved but do not tell a busy reader whether it affects them.
When an external client received the wrong information, correct that audience deliberately. Do not assume an internal edit will reach a forwarded copy. Name the error plainly, give the corrected value, and avoid blaming the note taker. The goal is to stop the wrong instruction from travelling.
Resend the full recap only when the delta is harder
A change note works when the stable parts greatly outnumber the changed parts.
Resend a complete record when:
- several decisions and actions were assigned to the wrong meeting;
- the first recap used the wrong source notes;
- the structure is so misleading that individual corrections would be difficult to follow;
- a required formal process demands a reissued document.
If you reissue it, label the replacement clearly, identify the previous version it replaces, summarize the material changes at the top, and withdraw the old link where possible. Do not circulate “final-v2” beside “final-final” and leave version control to filenames.
For one owner, one date or one condition, the delta is easier than the document. Send the delta.
Use this correction template
Copy this into email, chat or a comment on the meeting record:
Correction: [meeting name] ([meeting date])
Field: [decision, owner, due date, scope, condition or status]
Was: [the incorrect value]
Now: [the correct value]
Reason: [why the earlier record was inaccurate]
Action affected: [what starts, stops or changes; or “none”]
Record updated: [where the authoritative correction now lives]
A meeting correction should reduce uncertainty in one pass. Show the change, repair the record, and tell the affected people what, if anything, they must do differently.
FAQ
How do you correct a meeting recap after it has been sent?
Should you resend the entire meeting recap after a correction?
What if the team changed its mind after the meeting?
Keep reading
More from the Scripta blog
MeetingsA status meeting should surface exceptions, not narrate every task
Replace the round-robin status update with a short exception review that exposes blockers, decisions and changed commitments.
DecisionsBefore asking for meeting feedback, say what can still change
Set a correction window and decision boundary so post-meeting feedback improves the record without reopening every settled choice.
MeetingsA meeting parking lot needs a return rule
Stop deferred meeting topics from disappearing by recording why each one was parked, who owns the next move and the condition that brings it back.
MeetingsSeparate observations from interpretations in meeting notes
Keep meeting records trustworthy by labeling what the team observed, what it inferred and what it still needs to verify.