A decision log is a simple, running record of the decisions your team makes, why it made them, and who made them. It sounds like admin, yet it can answer a question that can eat hours in a small business: “Wait, why did we decide that?” Without a record, the same debate can return every few months, often with different people in the room and none of the original reasoning. This guide shows how to set up a lightweight decision log, what to put in each entry, and how to keep it alive without extra meetings.

Who this guide is for

This guide is for small business owners, studio founders and small-team leads who make dozens of choices about clients, pricing, process and tools. It suits design studios, agencies and service businesses where decisions can be made quickly in calls or chat threads and then forgotten. You only need a shared document or spreadsheet to start.

Where the decision log idea comes from

The practice is borrowed from software teams. In a 2011 post, Michael Nygard described the Architecture Decision Record, a short document that captures one significant decision. The ADR community site describes an ADR as capturing a single decision and its rationale, and calls the collection of all of them a project’s decision log.

Nygard’s reasoning applies well beyond software. In his post, he points out that when people do not know why a past decision was made, they tend either to blindly accept it or to blindly change it. Both are risky. Accepting an outdated choice keeps you stuck, while reversing a choice without knowing its reasons can undo something that was protecting the business. A decision log keeps the motivation behind earlier decisions visible, so newer team members can understand the original context.

What a decision log entry should include

Nygard’s format has five parts: title, context, decision, status and consequences. For a small business, a slightly expanded version works well:

Two details from Nygard’s post are worth copying. First, he recommends writing the decision in full sentences in active voice, starting with “We will…”. Second, he advises listing all consequences, not just the positive ones. Honest downsides can help stop the next person from reopening the debate, because they can see the trade-off was already weighed.

How to set up a decision log in an afternoon

1. Pick one home. Use a single shared document, spreadsheet or wiki page that everyone can find. One location matters more than the format.
2. Create the template. Copy the fields from the table above into a reusable block or columns.
3. Agree what counts as a decision. A useful test is: would someone ask “why did we do this?” in six months? If yes, log it. Daily task choices do not belong here.
4. Name an owner. One person checks the log weekly and nudges people to add missing entries. In a small studio, this can be the operations lead or the founder.
5. Back-fill a few recent decisions. Add three to five recent choices that people still discuss, such as pricing, client communication rules or file handover standards. This gives the team examples to copy.
6. Link it from where work happens. Pin the log in your team chat and link it from project templates and meeting notes.

Keeping the decision log useful over time

Supersede, do not delete

Decisions change, and that is fine. Nygard advises that when a decision is reversed, you keep the old record and mark it as superseded. In practice, add a new entry with the new decision and link the two. The history then shows how thinking evolved, which helps when a similar question comes up again.

Capture decisions where they happen

Some small-team decisions happen in a quick call or a chat thread. To catch them, end meetings with a short prompt: “Did we decide anything that belongs in the log?” Similarly, when a chat thread reaches a conclusion, the person who started it adds the entry and posts the link back in the thread.

Keep entries short

Nygard suggests a whole record should be one or two pages long. For a small business, a few short paragraphs can be enough. If an entry is getting long, the context probably belongs in a separate document that the entry links to.

Point to the log when old debates return

The real value shows up when someone raises a settled question. Instead of re-arguing, share the entry and ask, “Has anything in the context changed?” If it has, write a new proposed entry. If not, the decision stands, and the conversation can end quickly.

Decision log or meeting notes?

Meeting notes and a decision log can look similar, but they do different jobs. Meeting notes record what was discussed on a given day, in the order it came up. A decision log records only the outcome and its reasoning, organised so you can find it later without remembering which meeting it happened in.

A few things do not belong in the log:

• Routine task assignments. “Sam will update the homepage copy” belongs on your task board.
• Open discussions. If nothing has been decided yet, log it as “Proposed” or leave it out until there is an outcome.
• Personal or sensitive matters. Keep people issues in the appropriate private records, not a shared team log.
• Client-confidential detail. Summarise the decision and link to the client file instead of copying sensitive information.

Keeping the log focused makes it quicker to scan, which in turn makes it easier for people to check it before reopening a topic.

Worked example: a seven-person web studio

Consider a hypothetical web studio that keeps debating whether to offer ongoing website maintenance. Each time a client asks, the topic resurfaces in the weekly meeting, and each time the discussion starts from scratch.

The founder writes entry DL-009. The context notes that maintenance requests arrive irregularly, nobody on the team enjoys the work, and two past maintenance clients created urgent requests that disrupted project schedules. The options considered were offering maintenance in-house, referring clients to a partner, or offering a 30-day post-launch support window only. The decision reads: “We will offer 30 days of post-launch support on every project and refer longer-term maintenance to a partner.” Consequences list a possible loss of recurring income and the need to agree a referral process.

Three months later, a new project manager suggests adding a maintenance plan. Rather than restarting the debate, the founder shares DL-009. The project manager points out that a new hire now has the skills and interest to handle maintenance, which changes the context. As a result, the team writes DL-021, which supersedes DL-009 with a small pilot. The discussion takes ten minutes instead of an hour, and the reasoning for both decisions stays on record.

Decision log template

Copy this block for each new entry:

• ID: DL-[number]
• Title: [short noun phrase]
• Date: [date] · Decision-maker: [name] · Status: Proposed / Accepted / Superseded by DL-[number]
• Context: [what is happening, constraints, who is affected]
• Options considered: [option A], [option B], [option C]
• Decision: We will [action].
• Consequences: [what changes, including the downsides]
• Review date: [optional]

For more ways to build simple, repeatable routines like this into your team, browse our business systems articles.

Key takeaways

A decision log gives a small team a shared memory of what it decided and why. Keep one log in one place, use a short template with context, options, decision, consequences and status, and name an owner to keep it current. When a decision changes, add a new entry and mark the old one as superseded rather than deleting it. Over time, the log can let your team spend its meeting time on new questions instead of re-arguing old ones.

Written by the Design Productive Editorial desk. Disclosure: this guide contains no affiliate or sponsored links.