Most companies make good decisions and then lose them. A supplier is chosen, a process is changed, a tool is switched off. Six months later someone asks why, nobody remembers the reason, and the discussion starts again from nothing. Or worse, the decision is quietly ignored because only half the team ever heard it.
This article is for an owner, managing director or operations lead who wants a light habit that prevents this. It is about recording a decision after it has been made. For the question of who gets to make it, see decision rules for choices several people sign off.
Why a record, and why one page
A decision record is not minutes of a meeting and not a policy. It is a short note that answers one question for the person who finds it later: what did we agree, and would we still agree today?
One page is a deliberate limit. A longer document is written once and never read; a page can be written in ten minutes straight after the conversation, while everyone still remembers it. If you cannot fit the decision on a page, it is usually two decisions.
The five fields
Use the same fields every time. The fixed shape is what makes the records easy to scan.
- What was decided. One or two sentences, in plain words. Write it so that someone outside the meeting would understand it. "We will move customer orders from the shared spreadsheet to the new order tool from 1 March" is a decision. "Orders to be improved" is not.
- Why. The main reason and the one or two alternatives that were rejected, each with a short reason. This is the most valuable field. A choice without its reason cannot be reviewed; you can only accept or overturn it.
- Who. The person who carries it out, and the people who must be told. One name for the first, not a team. If nobody can be named, the decision is not finished.
- By when. The date by which the first visible step happens. Not the end of the whole project - the first step.
- When to revisit. A calendar date, and the one thing you will look at on that date. For example: "15 June - are order errors lower than the current monthly count?"
That is the whole template. Resist adding a risk matrix, a sign-off table or a section called "background". If those are needed, link to them.
The review date is the part people skip
Most teams that keep records write the first four fields and leave the fifth blank. Without it the record is only an archive of the past.
A review date does two things. It lets people accept a decision they are not fully sure about, because they know it will be looked at again. And it gives you a natural moment to stop things that are not working, without anyone having to admit a mistake - the date simply arrives and the question is asked.
For most operational choices, three months is a good default: long enough for the effects to show, short enough that nobody has forgotten the context. Faster for anything with a trial period, slower for a supplier contract with a yearly cycle. On the review date, ask only what you wrote down, then do one of three things: keep it, change it, or drop it. Write the outcome at the bottom of the same page.
Which decisions deserve a record
Not every choice needs a page. A useful test is two questions:
- Is it costly or slow to reverse? (A new supplier, a new tool, a change of a process other teams depend on.)
- Do other people have to act on it, or will new colleagues have to live with it?
If the answer to either is yes, write it down. If both are no, skip it. Ten records a year that people actually read are worth more than a hundred that nobody opens.
Where to keep them
Keep all the records in one place that the whole management team can search. A shared folder with one file per decision, named with the date and a short title, is enough. A table at the top of a shared document that lists date, title and status works too. The tool matters much less than two rules:
- One place. If records live in e-mail, chat and personal notebooks, they will not be found.
- Never edit an old record. If the decision changes, write a new record that says "replaces the decision of 12 March" and mark the old one as replaced. The history of why you changed your mind is useful in itself.
An example
What: From 1 February, supplier invoices are approved in the accounting system, not by e-mail. Why: Approvals by e-mail were lost twice last quarter and took five days on average. We considered a shared mailbox (rejected: still manual) and a full purchasing module (rejected: too large for current volume). Who: Jana carries it out; the three department heads are told by Friday. By when: First invoice approved in the system by 10 February. Revisit: 10 May - how many invoices are still approved by e-mail, and is the average approval time shorter?
Five short lines, and a new finance colleague can understand the situation in a minute.
Common mistakes
- Recording the choice but not the reason. Later it can only be obeyed or overturned, not judged.
- Writing it a week later. Details and rejected options are already forgotten.
- Naming a team instead of a person. Nobody feels responsible.
- Skipping the review date. The record becomes an archive and the decision is never tested.
- Recording everything. People stop reading, and the important records get lost among trivial ones.
- Using the record to assign blame. It exists to help the next decision, not to judge the last one.
Checklist
- Write the record the same day, in ten minutes
- Five fields: what, why, who, by when, revisit
- Name one person who carries it out
- Set the review date and the one question for it
- Store it in one searchable place
- Replace old records instead of editing them
If your decisions involve new software, a two-page documentation for an internal tool is a good companion: the record explains why the tool exists, the documentation explains how it works. A regular twenty-minute operations meeting is a natural place to read out new records and to check which review dates are due.
Sources
- Our related articles linked above.
- The template and the three-month default are a working practice, not a standard; adapt them to the size of your company. The example is invented for illustration. No client results or market figures are claimed in this article.