Many meetings repeat not because a team made no decision, but because the decision lost its context as soon as the meeting ended. A week later, someone who was absent asks why; a month later, when the result is weaker than expected, people remember the agreement differently. Work returns to the meeting table, and the group must reconstruct the evidence, alternatives, and trade-offs it already considered. A short decision log, updated at the right moment, can reduce this loop without turning management into more paperwork.
A decision log is not a detailed set of minutes. It is a shared reference point for choices that affect resources, priorities, customers, or coordination. Its purpose is not to prove who was right. It helps people carrying out the work understand which decision guides them, what information supported it, and when they should surface it for reconsideration. Used well, it makes initiative clearer rather than slowing progress through repeated requests for permission.
Record what must be remembered, not the whole meeting
Each entry needs only five answers. What was decided? Who owns putting it into work? Which evidence or assumptions matter most? Which alternatives were not chosen, and why? On what date or signal will the team revisit the decision? These questions make a meeting end with an actionable choice rather than a full list of opinions that leaves no one sure what happens next.
The rationale should be short enough to be read, but honest about assumptions. A business that holds its price for the coming quarter, for example, is not simply “protecting market share.” It may be assuming that service capacity can still meet demand, competitors have not changed their pricing structure, and customers are more sensitive to total cost of use than to list price. If those assumptions change, the decision should be reopened. Writing them down tells the team what to monitor instead of waiting for poor results before starting the argument again.
| Record field | Minimum content | Operating value |
|---|---|---|
| Decision | One sentence beginning with a verb: choose, stop, prioritise, or test. | Removes ambiguity about what was agreed. |
| Owner | One person or role accountable for turning the choice into work. | Separates the decision-maker, implementer, and consulted parties. |
| Basis | The applicable data, assumptions, and constraints. | Preserves context so later readers do not have to guess. |
| Review signal | A review date or threshold that requires escalation. | Enables disciplined adjustment before a crisis. |
Put the log where work happens
A perfect form in a folder that few people open creates no value. Put the log beside the place where the team manages its project, quarterly objectives, or operating meeting; link to data, plans, and relevant people when needed. A simple rule helps: someone joining the work should be able to find the decision shaping their task within minutes, without sending a chain of messages for the history.
Not every choice deserves an entry. Routine work with an established process, small adjustments that can quickly be reversed, and information-only exchanges do not need a log. Prioritise choices that are hard to reverse, cross unit boundaries, create commitments to customers, or set a precedent for later choices. This selectivity keeps the document high-signal rather than turning it into an overloaded archive.
Example: changing how customer requests are received
A service team receives many urgent requests through several channels. At the start of the month, it decides that urgent requests will be accepted only through one shared form, with the shift manager triaging them within 30 minutes. The log names the operations lead as owner, records three weeks of evidence that chat requests caused missed and duplicated assignments, and sets two consecutive weeks above the agreed slow-response threshold as the review signal. When a sales manager later asks to reopen chat for large customers, the team can assess that proposal against the same criteria instead of relitigating the whole change.
Make the review point part of the decision
Many organisations revisit a decision only when someone is unhappy. A better approach identifies the review date or trigger from the outset. For an experiment, that might be completed orders, error rates, or customer feedback after four weeks. For an investment choice, it might be cost movement, supplier progress, or a regulatory change. The more specific the signal, the less likely a team is to be pulled into changes driven by emotion or by the loudest voice.
A review does not deny the original decision. It is a learning mechanism: has new evidence changed the underlying assumption, or is the result different because implementation fell short? Separating these possibilities matters. When the assumption still holds but execution is weak, the team should repair implementation. When the assumption is wrong, the team has a reason to change direction without turning adjustment into a search for blame.
Start small and build a shared habit
A team does not need a complex system on day one. A shared table, with each item limited to a few lines and completed before the meeting ends, is enough. In the first two or three weeks, the meeting lead can reopen a few earlier entries to check progress and review signals. Once people see that the log reduces repeated questions, hidden changes, and time spent rebuilding context, it becomes part of the operating rhythm.
The value of a decision log is not the number of entries it contains. It is the team’s ability to connect a current action to an agreed choice, rationale, and responsibility. When that thread is intact, meetings can spend more time on new information and the next decision instead of trying to remember what everyone previously said.
