# How to reduce meeting follow-up without losing decisions

https://techy.eus/en/resources/reduce-meeting-follow-up
Updated: 2026-09-20

Meetings become expensive when the important part happens afterward: trying to remember what was decided, who volunteered and what the deadline meant.

Techy · Editable offline copy. Examples are illustrative, not customer results. Review the guide's limitations before applying it.

## Decide what the meeting is for

Before it starts, state whether the meeting is for a decision, an update, a working session or a review. Mixing every purpose into one call makes both the discussion and the notes unclear.

If no decision or useful exchange requires a live conversation, a short written update may be better.

## End with a visible decision list

Reserve the final few minutes to read back decisions, actions and owners. Record the outcome in the place the team already trusts, not in a private notebook.

An action should include a verb, an owner and a date or trigger. ‘Improve onboarding’ cannot be followed; ‘send the revised checklist before Friday’ can.

- Decision made.
- Action and owner.
- Due date or trigger.
- Open question and who resolves it.

## Share a short record quickly

Send the notes while people still recognize the conversation. A short, accurate record is more useful than polished minutes that arrive after the next decision has already changed it.

## Worked example: a decision log that survives the meeting

Replace ‘we discussed the launch’ with a fictional decision entry: ‘Launch the request form without online payments. Sam verifies delivery to the inbox by Thursday; Priya approves the final copy. Revisit payments after the first release.’ Link the relevant brief and state who made the decision. A discussion summary alone does not tell an absent colleague what to do.

Before ending, read each action back to its owner. If nobody accepts it, record it as unassigned and resolve ownership instead of treating silence as agreement. Send one canonical note rather than separate versions to each participant. At the next check-in, inspect the deliverable or blocker, not whether someone remembers the conversation. When a decision changes, append the replacement with a date so the original remains understandable in context.

## Correct a decision record without erasing its history

Fictional project meeting: D-07 approves launching a request form without payments on Thursday, conditional on a successful test. Later, the test fails. The record should make clear which decision remains valid and which condition has not been met.

Keep the original decision and append the changed status with a timestamp. Do not silently rewrite ‘Thursday’ as ‘Friday’ and leave readers guessing what was promised. Send a targeted update to people depending on the launch, including the unresolved condition and who will decide after the retest. A meeting note is useful only if it distinguishes decision, action and condition.

Worked example · fictional inputs

| Record | Owner | Meaning |
| --- | --- | --- |
| D-07: approve scope without payments | Priya | Scope decision remains recorded |
| A-12: test confirmation and error paths | Sam | Failed; evidence linked |
| Launch gate | Priya | Not cleared while A-12 fails |
| Next checkpoint | Sam | Retest Friday morning; report result |

## Test the result and handle the exception

When participants disagree about what was decided, mark the decision as disputed and ask the decision owner to clarify. Do not resolve ambiguity by presenting one person’s recollection as unanimous agreement.

- A task marked complete has an observable output, not just an owner.
- The conditional launch is not announced as confirmed.
- People can find the current status without reading a full chat transcript.

## Your working sheet — fill in locally

Situation and date: ____________________

Inputs and where they came from: ____________________

Decision / calculation: ____________________

Expected result: ____________________

Actual check and evidence reference: ____________________

Exception and next action: ____________________

Owner and review date: ____________________

Do not put passwords, patient details or other sensitive data in a shared worksheet. Downloading or checking a box does not verify real-world compliance.