Operations Meeting Decision Capture

Meeting decision capture

Purpose

The failure is not that meetings go unrecorded — it is that summaries are generous. A discussion where three people nodded becomes "agreed: migrate in Q3". An action nobody accepted gets attributed to whoever spoke last. Six weeks later the owner has never heard of it and the decision is relitigated from scratch. This skill separates what was actually decided from what was merely discussed, and refuses to manufacture the owner or the date that would make an item look finished.

The rule that does the work

A decision without a named decider is a discussion. An action without a named owner and a date is a discussion. When either is missing, the item goes in the open-questions list with the specific gap stated — no owner named, no date agreed, no decision reached — and, where useful, the sentence that would close it. Do not infer the owner from who raised the topic, who is most senior, who owns the adjacent system, or who has done it before. Every one of those inferences is reasonable and every one of them produces an action that never happens.

The value here is entirely in the refusal. A model asked to summarise a meeting will produce a confident action list unprompted; producing the list is not the skill, declining to invent the missing half of it is.

Prerequisites

• Inputs: the transcript, recording notes, or written notes. Speaker attribution materially improves the output — without it, decisions can be captured but deciders and owners usually cannot, and most items will correctly land in open questions.
• Inputs: the meeting's date, its purpose, and who attended. A date is needed because "by end of week" is meaningless without it.
• Inputs (if checking follow-through): the previous meeting's action list.
• Inputs (useful): the decision rights in play — who is entitled to decide what. Without it, note who stated the decision rather than asserting authority.

If notes were not supplied, stop. Do not reconstruct a meeting from a calendar invite, an agenda or a topic. An agenda records what was intended to be discussed, which is not evidence of anything that was said.

Data handling

Classification: Internal by default, and higher where the subject is. Meetings covering individuals' performance, pay, disciplinary matters, redundancies, customer or client specifics, unpublished financials, legal advice or an investigation take the classification of their subject and a restricted distribution list. If personal data, client positions or account identifiers appear in a transcript, flag it and exclude those specifics from the circulated record — the decision can be recorded without the underlying record.

Two further constraints. Do not attribute a view or a quote to a named person unless the notes support it. And if a meeting was recorded, check that the participants knew.

Procedure

1. Sort every item into one of four buckets before writing anything

An item may fail on one element only. "Priya will draft the proposal" with no date is an open question with the owner already known — record it as owner: Priya · NO DATE AGREED, so the gap is one message away from closing, not a re-run of the meeting.

2. Record each decision with what it needs to survive

What was decided · who decided it · the date · what it supersedes, if anything · the basis or the one or two alternatives rejected · what it commits (money, scope, timeline, headcount) · who must be told.

The rejected alternative is what stops the decision being reopened by someone who was not in the room, and it is the field most often dropped. If no alternative was discussed, say so — a decision with no considered alternative is a real signal.

Where a decision was stated by someone who may not hold the decision right, record it as stated by X · confirmation required from the decision owner. Do not silently upgrade it, and do not quietly discard it either.

3. Record each action in the fixed shape

Owner (a named person, never a team or a function) · the deliverable, stated as something a third party could verify was done · the date, as an actual date · what it depends on · where it is tracked.

"The team will look into it" is not an action. Neither is "improve reporting". If the deliverable cannot be verified as done by someone who was not in the meeting, sharpen it or move it to open questions.

A team name in the owner field is the single most common way an action dies. If only a team was named, record team: X · INDIVIDUAL OWNER NOT NAMED and put it in open questions.

4. Record open questions so they are answerable, not just listed

Each one: the question · why it is open (no owner, no date, no authority present, missing information, disagreement) · who could resolve it · by when it needs resolving. An open-questions list with no route to closure is a list of the meeting's failures, and it will be identical after the next one.

5. Check the previous action list, if supplied

Mark each prior action done, in progress with a revised date, blocked with the blocker named, or not started. An action carried forward three times without a changed date is a signal about capacity or ownership — surface it rather than rolling it silently a fourth time.

6. Assemble and circulate in this order

1. Decisions.
2. Actions — owner, deliverable, date.
3. Open questions, each with the specific gap.
4. Previous actions, with status.
5. Context, kept short.

Circulate to attendees and to everyone named as an owner or affected by a decision, whether or not they were in the room — an owner discovering their action in a status report a month later is a process failure, not an individual one.

7. Self-check before sending

Does every decision have a named decider? Does every action have a named individual and a real date? Has anything been promoted from discussion to decision by the way it is worded — "agreed", "confirmed", "it was decided" — where the notes do not actually support it? Is any owner an inference? If yes to the last two, move it back.

Boundaries

• Not for the recurring project or programme status report these actions feed into; that belongs with the project owner and its own reporting cycle.
• Not for recording a technical or architectural choice with its options, trade-offs and consequences — that is engineering-decision-record, which this routes to when a meeting settles one.
• Not for documenting a repeatable process the meeting described — that is operations-sop-authoring; map it first with operations-process-mapping if the process is not yet understood.
• Not for an incident review, which needs a timeline and contributing factors rather than a decision list — that is engineering-incident-postmortem.
• Not for performance conversations, which are hr-performance-review-coaching and must not be circulated as minutes.
• Not for producing a full narrative transcript summary. Decisions, actions and open questions are the deliverable; everything else is context and should be short.

Hand-offs

• Receives from: the transcript or notes, and the previous meeting's action list.
• Routes to: engineering-decision-record when a technical decision was made and needs its options and consequences documented properly.
• Routes to: operations-sop-authoring when an action is "write down how we do this".
• Routes to: product-roadmap-communication when a decision changes scope, sequence or dates that others are planning against.
• Routes to: legal-compliance-obligation-extraction when a decision commits the organisation under an agreement whose duties are not yet registered.
• Escalates to: the meeting chair when a decision was recorded by someone without the decision right, or when the same open question survives three consecutive meetings.