Meeting Notes or a Decision Record? Save the Reason, Not Just the Conversation

Meeting notes can accurately record a conversation while leaving the final decision difficult to find. A colleague reading them later may see several suggestions without knowing which was adopted, who owns it, or what assumptions would cause the team to reconsider. A decision record answers that narrower set of questions.

You may need both. Notes can preserve discussion and actions; a short decision record can preserve the outcome and rationale. The record is useful when a choice affects future work, involves a meaningful tradeoff, or is likely to be questioned after the original participants move on.

Recognize when the extra record is worth writing

Use a record for decisions such as selecting an integration approach, changing an operating policy, or accepting a constraint that another team must understand. Do not turn every small preference into a formal document. The effort should match the cost of losing the reasoning.

The GOV.UK governance principles emphasize evidence, decision authority, and clear boundaries. The following format is an editorial way to make those responsibilities visible in a small team; it is not a mandated government template.

Write the question before the answer

State the problem in terms that remain understandable later. “Choose tool B” is an answer. “How will the team receive and assign incoming support requests while the current mailbox is retired?” explains the decision being made. Include the relevant deadline and constraints without reproducing every sentence from the meeting.

Name the scope. If the decision applies only to a pilot team or one project phase, say so. Otherwise, a limited experiment can be mistaken for a permanent organization-wide rule. Link to the source material rather than pasting entire reports into the record.

Keep the alternatives real

List the plausible options considered and the reason each was accepted or rejected. A useful alternative should have been genuinely available, not invented afterwards to make the chosen option look inevitable. Include doing nothing or delaying when those were realistic options.

Separate facts from assumptions. “The vendor confirmed this export format” is a different kind of evidence from “We expect fewer than fifty cases a month.” Both can matter, but the second should remain visible as something that may change.

A compact example

For an imaginary team evaluating a shared request process, a record might read:

Question: How will incoming requests be assigned during a four-week pilot?

Decision: Use the approved shared inbox with one rotating triage coordinator and one named owner per request.

Reason: The current volume can be handled with existing tools; the main failure is unclear ownership.

Alternatives: A new ticketing tool is deferred until the pilot establishes requirements. Unassigned group handling is rejected because duplicate replies already occur.

Owner and review: The operations lead reviews assignment delays and missed handoffs after four weeks. A sustained increase in volume or an unmet audit requirement triggers an earlier review.

The example is deliberately limited. It does not claim that a shared inbox is suitable for every organization or that a pilot proves long-term suitability. It gives a future reader enough information to evaluate whether the original reasoning still applies.

Make approval and status unambiguous

Label the record proposed, accepted, superseded, or withdrawn according to your team's process. Identify the person or group authorized to decide. If approval is required, do not infer it from a lack of comments in a document that may not have been read.

Record the actual decision date and link to the discussion or approval evidence where appropriate. Protect sensitive material under the organization's access rules. A decision record should improve accountability without becoming an unnecessary repository of personal or confidential information.

Preserve changes without rewriting history

When circumstances change, add a new decision or mark the old one as superseded with a link. Correct factual errors transparently. Avoid silently rewriting the original rationale to match what the team believes now; that makes it harder to learn from the earlier choice.

The revisit condition is especially valuable. It can name a date, a changed assumption, a measured problem, or a dependency becoming available. A clear trigger prevents both endless reconsideration and indefinite loyalty to a decision whose premise no longer holds.

Distinguish an assumption from an acceptance condition

An assumption explains why an option seems workable: expected request volume, availability of a colleague, or a vendor feature described in documentation. An acceptance condition says what must be demonstrated before the decision can be put into effect. Keeping them separate prevents a tentative premise from becoming an unearned completion claim.

For the inbox example, the team might assume that current request volume remains modest. It might require an acceptance check that every coordinator can access the approved inbox and assign a harmless test request. The assumption could trigger a future review; the acceptance check must pass before the pilot begins.

Record unresolved conditions explicitly. An accepted direction can still be blocked from implementation by a missing approval or a failed prerequisite. Use a status that communicates that distinction rather than writing approved and leaving readers to infer that every operational step is complete.

Keep minority concerns without preserving every debate

A useful record can state that a concern remains and how it will be monitored. It does not need to reproduce every disagreement or attach a person's name to every objection. Follow the organization's expectations for attribution and confidentiality, and focus on the substance that a future decision maker needs.

For example, one option may be selected despite an unresolved concern about peak workload. The record can say that the pilot excludes the busiest season and therefore cannot establish peak suitability. That is more useful than either deleting the concern or allowing the record to become a transcript of the entire discussion.

Use the record in the next review

When the review date arrives, read the original question, assumptions, and acceptance conditions before evaluating the result. Ask which predictions held, which changed, and whether the evidence supports extending the decision's scope. Do not judge a limited pilot as though it had promised to solve every related problem.

If the team decides to continue, document what has actually been learned. If it changes direction, link the new record and explain the changed evidence. A reversal can be a reasonable result of a well-designed experiment; the record should make that reasoning visible instead of treating the earlier choice as something to hide.

This review also tests the document itself. If colleagues cannot tell why the option was chosen without asking the original author, improve the structure for future records. The goal is useful organizational memory, not a growing collection of documents that require their authors to interpret them.

Put the record where the work points to it

Link the record from the relevant project, operating procedure, or configuration documentation. A beautifully written decision that nobody can find will not prevent repeated debate. Give it a descriptive title based on the question so future searches have a chance of reaching it.

Use meeting notes for the conversation and the decision record for the durable explanation. The test is simple: can a colleague who was absent identify what was decided, why it was reasonable at the time, and what would justify changing it? If so, the record is doing useful work.