The Decision Document

The weekly status report tells people what happened. This template is for the moment before that — when a real choice is on the table and someone has to actually pick. It’s the artifact for deciding well and leaving a trace of why.

Most bad decisions aren’t bad because someone chose wrong. They’re bad because nobody was quite sure a decision had been made, nobody could remember why, or everyone assumed someone else was the one deciding. A decision document fixes all three at once: it forces the choice into the open, records the reasoning, and names the single person who owns the call. This page gives you the blank template, shows you how to use it, walks through a filled-in example with honest trade-offs, and ends with a short exercise.

The difference between a decision and a discussion

Here is the distinction the whole template rests on. A discussion is people talking about a problem. A decision is a specific choice, made by a specific person, on a specific date. They feel similar in the room — everyone leans in, points get made, heads nod — which is exactly why teams so often mistake one for the other. You leave a good discussion feeling aligned, and three weeks later discover nothing was actually chosen.

Writing is what forces the line between them. It’s easy to talk your way around a choice — to stay in the warm, agreeable fog of “we’re all basically on the same page.” It is much harder to write down “We will do X, not Y, decided by Priya on 8 July.” The blank fields on this template are uncomfortable on purpose. They will not let you fill them in without naming the thing you are actually choosing, the thing you are giving up, and the person accountable for it. That discomfort is the tool doing its job.

The evidence — decisions rarely stick without a record

Studies of organizational decision-making generally find that a large share of decisions people believe were “made” in a meeting were never acted on — often because attendees left with genuinely different understandings of what had been agreed. The written decision is the cheapest known fix: a short record, shared and confirmed, collapses the range of interpretations down to one. You are not adding bureaucracy; you are preventing the far more expensive re-litigation later.

The template

Copy this straight into a doc. It fits on one page on purpose — if it doesn’t, the decision is probably several decisions wearing a trench coat, and you should split it.

DECISION: <one sentence naming the choice, phrased as a decision, not a topic>

Decider:   <ONE named person who owns this call>
Date:      <the date the decision was made>
Status:    <Proposed | Decided | Revisited on ______>

CONTEXT
  Why are we deciding this now? What changes if we don't decide?
  (2–4 sentences. Enough for a stranger — or future-you — to understand
  the situation without being in the room today.)

OPTIONS CONSIDERED
  Option A — <name>
    Upside:   <what's good about it>
    Downside: <the honest cost / risk — do not leave this blank>
  Option B — <name>
    Upside:   <...>
    Downside: <...>
  Option C — <name>  (include only if genuinely on the table)
    Upside:   <...>
    Downside: <...>

THE CALL
  We will: <the chosen option, stated plainly>
  Because: <the reasoning — why this option's trade-offs beat the others'>
  We are accepting: <the specific downside we're knowingly taking on>

REVISIT IF
  <the condition or date that would make us reopen this — e.g. "if cost
   exceeds $X", "if churn hasn't dropped by Q4">

Six things are non-negotiable, because they are the six ways decisions go wrong: the decision (stated as a choice), the context (so it can be understood later), the options with honest downsides, the call and its reasoning, one named decider, and the date.

Why each field earns its place

• DECISION, phrased as a choice. “Pricing” is a topic. “Do we move to annual-only billing?” is a decision. If you can’t phrase it as a question with a chooseable answer, you’re not ready to decide — you’re still in discussion.
• The honest downside on every option. This is the field people most want to skip, and the most important one. An option with no downside listed is a warning sign: either you haven’t thought hard enough, or you’ve already decided and are staging a fake comparison. Every real option costs something. Name it.
• “We are accepting.” Naming the downside you’re choosing to live with is what separates a decision from wishful thinking. It also protects the decider later: when the accepted cost shows up (it will), the record shows it was a known trade-off, not a blindside.
• One decider. More on this below — it’s the single field that prevents the most common failure of all.

How to use it

Write it before the final conversation, not after. The draft is the agenda. Circulate the DECISION, CONTEXT, and OPTIONS sections ahead of time; use the meeting to pressure-test the trade-offs and let the decider make the call; fill in THE CALL live or immediately after. A decision doc written only as a retroactive record is useful, but written in advance it also makes the discussion sharper.

Match the weight to the stakes. As the toolkit overview argues, overhead should match the stakes. A reversible, cheap choice deserves a one-line note in chat — “Going with vendor A, cheaper and faster to onboard — @Sam, shout if not.” Reserve the full template for decisions that are expensive, hard to undo, or that many people will build on. Writing a formal document for a choice you could reverse in an afternoon is process worship.

Confirm, then close. Once THE CALL is filled in, share the final doc and give people a short, explicit window to object — “speak now.” Then mark it Decided and stop debating. The document’s quiet superpower is that it lets you end the discussion cleanly, because there is now one authoritative answer to “so what did we decide, and why?”

The common trap — the fake comparison

The most common way a decision document goes wrong is the fake comparison: the author has already picked Option A, so Options B and C are written as obvious losers with inflated downsides and no real upside. This isn’t deciding; it’s manufacturing a paper trail to justify a foregone conclusion — and readers can smell it. If you catch yourself unable to write a genuine upside for the options you’re rejecting, you either don’t understand them well enough to reject them, or you’re not actually asking a question. The test: could a reasonable colleague read your options and pick a different one? If not, it’s not a decision document, it’s an announcement.

A filled-in example

A small café chain (four locations) is deciding whether to build its own online-ordering system, buy an off-the-shelf platform, or keep taking orders by phone. Here’s the document its operations lead wrote.

DECISION: How should we take online orders across all four cafés —
          build our own, buy a platform, or stay phone-only?

Decider:   Dana Okafor (Operations Lead)
Date:      8 July 2026
Status:    Decided

CONTEXT
  Phone orders are overwhelming staff at peak hours and we're losing
  walk-ups while the till is tied up on calls. Two competitors nearby now
  take app orders. We need something running before the autumn rush. If we
  don't decide this month, we lose the build/onboarding window entirely.

OPTIONS CONSIDERED
  Option A — Build our own ordering system
    Upside:   Fully fits our menu and workflow; no per-order fees; ours to
              change forever.
    Downside: We have no software team. Realistically 4–6 months and a
              contractor we can't afford; high risk of it never shipping.
  Option B — Buy an off-the-shelf ordering platform
    Upside:   Live in ~2 weeks; someone else handles payments, updates, and
              support; proven with cafés our size.
    Downside: ~6% fee per order and a monthly fee; limited menu
              customization; we depend on their roadmap and pricing.
  Option C — Stay phone-only
    Upside:   Zero cost or change; staff already know it.
    Downside: The problem we're trying to solve stays unsolved; we keep
              losing walk-ups and fall further behind the two competitors.

THE CALL
  We will: Buy the off-the-shelf platform (Option B), starting with one
           café as a two-week pilot before rolling out to all four.
  Because: It's the only option that solves the problem before the autumn
           rush. Building is beyond our means today, and staying phone-only
           just accepts the loss we're trying to stop.
  We are accepting: The ~6% per-order fee and dependence on the vendor's
           pricing. We judge that cost smaller than the walk-up revenue
           we're currently losing at peak.

REVISIT IF
  Order volume grows enough that the 6% fee outweighs building our own, OR
  the vendor raises prices sharply — reassess "build" at that point.

Notice what the honest downsides do. Option A isn’t strawmanned — it has a real upside (fits us perfectly, no fees forever). It loses on a specific, named risk: no team, no time. That’s a decision, not an announcement, because a reasonable person could have weighed those trade-offs differently — and the record shows exactly why Dana didn’t.

Why recording the reasoning matters

The single most valuable line in that example is “We are accepting the ~6% fee, because that cost is smaller than the walk-up revenue we’re losing.” Here’s why. Six months from now, someone will look at the vendor invoices, see thousands in fees, and ask — reasonably — “why on earth are we paying this? We should build our own.” Without the record, the team re-opens the entire debate from zero, having forgotten the build option was already considered and rejected for concrete reasons.

With the record, the conversation is completely different. You pull up the doc and ask a much sharper question: “Has the thing changed that we said would make us revisit?” Maybe it has — order volume grew, building is now worth it, and reopening is the right call. Maybe it hasn’t, and you close the discussion in two minutes. Either way you are revisiting a decision with new information, not re-litigating a settled one out of amnesia. That is the entire point of recording the reasoning: it lets the decision be challenged intelligently and reopened deliberately, instead of relitigated by whoever happens to be annoyed by the cost this quarter.

Case study — Amazon’s written-decision culture

Around the 2000s, Amazon famously banned slideshow presentations for significant decisions in favor of a narrative memo — a written document read silently at the start of the meeting. The reported logic is precisely this template’s logic: prose forces a clarity that bullet points let you dodge. You cannot write “we will do X because Y, accepting downside Z” in full sentences without actually confronting the trade-off — whereas a slide can hide a hand-wave behind a confident bullet. The lesson isn’t the specific format; it’s that writing the reasoning down changes the quality of the thinking that goes into it. The document isn’t just a record of a good decision — making you write it is part of what makes the decision good.

Name one decider, or no one decides

Now the field that prevents the most common failure of all. Look again at the template: Decider is one named person. Not “the team.” Not “leadership.” Not “we.” One human name.

The failure this guards against is subtle and everywhere: the decision that everyone assumed someone else had made. When ownership is diffuse — “the group decided” — responsibility evaporates. Nobody feels authorized to make the final call, so it drifts; or everyone feels the call is partly theirs, so it gets quietly re-opened by whoever disagrees; or the decision genuinely never happens and each person leaves the room assuming a colleague would carry it. A choice owned by everyone is owned by no one.

Naming a single decider does not mean that person decides alone. They gather input, they hear the room, they may lean heavily on the people closest to the work. But when the discussion is done, one identifiable person says “here’s the call” and puts their name on it. That’s what makes the decision real. This is the same idea the RACI matrix formalizes for whole projects — the “A” for Accountable is always exactly one person — and the decision document is its smallest, sharpest instance: one choice, one owner, one date.

The common trap — “the team decided”

Watch for the passive voice around decisions: “it was decided,” “we’re going with,” “the consensus was.” These phrases feel collaborative and safe, but they hide the fact that no one has actually taken ownership. When something later goes wrong, “the team decided” means no one is accountable and no one learns; when it needs revisiting, no one has the standing to reopen it. The fix is almost rude in its simplicity: ask out loud, “Who is the decider on this?” If the room goes quiet, you have found a decision that was never really made.

Try this

Think of a choice your team is currently circling — the one that keeps coming up in meetings without ever resolving. Copy the blank template into a doc and fill it in this week, doing the two hardest parts honestly: write a genuine upside for every option (including the ones you’re inclined to reject), and put a single named person in the Decider field. Then circulate it with one question: “Is this the decision, and is [name] the decider?” You will usually learn one of two things — that the choice is easier than it felt once the trade-offs are on the page, or that no one had actually been assigned to make it. Both are worth finding out.