Decision Log for Small Companies: Who Decided What, and Why

Most small companies I work with don't lack decisions. They lack memory of them. Two weeks after a pricing call, the founder, the sales lead, and the ops manager each remember a different version of what was agreed. Six weeks later, someone reopens the same debate because the original context vanished into a Slack thread or a calendar invite. A decision log is the cheapest fix for that drag.

Definition: decision log

A decision log is a lightweight, chronological record of meaningful choices made by the team. Each entry captures the decision, the owner, the date, the alternatives considered, and the rationale.

Definition: decision owner

The decision owner is the person accountable for the choice and its outcome, not necessarily the person who facilitated the meeting where it happened.

What Belongs in a Decision Log

Not every choice needs a log entry. You don't need to record which coffee the office ordered or whether the Tuesday standup moves to 9:15. Log decisions that affect money, people, commitments to customers, or technical direction.

A complete entry includes:

• Decision: what was chosen, in one sentence.
• Owner: who is accountable for the outcome.
• Date: when the decision was made.
• Context: the situation that forced the choice.
• Alternatives considered: what else was on the table and why it lost.
• Rationale: the reasoning, not just the conclusion.
• Review trigger: when or under what conditions the decision should be revisited.

How to Write a Decision Entry (Copy/Paste Template)

## Decision: [short title]
- **Owner:** [name, role]
- **Date:** [YYYY-MM-DD]
- **Context:** [what forced this decision]
- **Decision:** [what was chosen]
- **Alternatives considered:** [option A, option B — and why each was rejected]
- **Rationale:** [the reasoning behind the choice]
- **Review trigger:** [date or condition to revisit]

Where the Log Lives

A decision log only works if it is easy to write and easy to find. For most small companies, that means a shared document, a Notion page, or a dedicated section in your existing status update channel. Do not bury it in a project management tool where only the project manager has edit access.

The log should be visible to anyone who reads your weekly or daily status updates. If a decision changes how a team works, the person writing the status update should reference the log entry by date or link directly to it.

Tool tip (AiAdvisoryBoard.me): Use the log as a visibility layer for your operating rhythm. When you review daily or weekly updates through a Plan → Fact → Gap lens, attach the relevant decision log entry to any gap so the team sees not just that a plan slipped, but which earlier choice created the constraint. See how the 7-day diagnostic surfaces these connections across your company.

Good vs Bad Decision Entries

Bad

Decided to switch vendors. John said it was better.

Good

Decision: Switch payroll provider from Vendor A to Vendor B. Owner: Head of Operations Date: 2024-04-10 Context: Vendor A increased fees by 18% and missed two filing deadlines. Alternatives considered: Stay with Vendor A and negotiate; move to Vendor B; move to Vendor C. Rationale: Vendor B matches our feature set at current pricing and has a 24-hour support SLA. Migration effort is estimated at one week of part-time ops work. Review trigger: 90 days after migration, or if Vendor B misses a filing deadline.

Decision Log as Part of Status Updates

A status update without decision context is just activity reporting. When someone writes "we are still evaluating the CRM," the reader has no way of knowing whether a decision was already made and is waiting on implementation, or whether the team is genuinely stuck.

Add a standing line to your status update template: "Decisions this week" and "Decisions pending." This forces the writer to surface choices and keeps the log current without a separate maintenance ritual.

Tool tip (AiAdvisoryBoard.me): A decision log works best when it is part of the same operating system you use to run the business. If you already capture daily updates, standups, or async check-ins, the log should plug into that flow so decisions and status travel together. See how the 7-day diagnostic maps your current visibility gaps before you add another tool.

Who Maintains It

Assign one person — usually an operations lead, chief of staff, or the founder's executive assistant — to own the log format and remind people to write entries. The owner does not write every entry; the person who made the decision does. The log owner simply ensures entries exist and are easy to find.

In companies under 50 people, the founder often makes most consequential decisions. That makes the log even more important, not less, because the founder's memory becomes the company's institutional memory by default.

Micro-case (what changes after 7–14 days)

A 40-person professional services firm was re-litigating its client onboarding process every month. The ops manager thought the team had agreed to a fixed intake form; the sales lead believed custom proposals were still allowed for enterprise deals. After two weeks of using a decision log attached to their weekly status update, the team had three recorded entries: one locking the intake form as standard, one defining the exception process for deals above $50k, and one assigning the exception approver. The next month, onboarding questions dropped by half because anyone could check the log instead of scheduling an alignment call.

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30–500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

FAQ

Who writes the decision log entries? The person who made the decision writes the entry. A designated log owner maintains the format and follows up on missing entries.

How detailed should each entry be? Enough that someone who was not in the room can understand the choice and the reasoning six months later. Usually that is four to six short lines.

Where should the log live? Wherever your team already reads status updates — a shared doc, a wiki, or a dedicated channel. The key is visibility, not the tool.

Do we log small decisions? No. Log choices that affect budget, headcount, customer commitments, or direction. Everything else is just work.

How often should we review old entries? Quarterly is enough for most small companies. Review entries with a review trigger that has passed, and archive anything that is no longer relevant.

A decision log is not bureaucracy. It is the memory your company needs so you do not pay for the same discussion twice. Start with one shared document, add one entry this week, and make "decisions this week" a standing line in your next status update.

If you want a system that surfaces the Plan → Fact → Gap automatically — every day, across the company — see how the 7-day diagnostic works. https://aiadvisoryboard.me/?lang=en