Team Decision Record: The ADR Concept for Business

A team decision record is a short document that captures one important business decision: why it came up, what was decided, why, what was rejected, and who has the authority to change it. It is the architecture decision record (ADR) idea, applied to the calls that shape a company rather than its code.

Engineering teams have written ADRs for years, because the alternative is a system nobody can explain. Business teams face the same problem with pricing, hiring plans, market choices and policies, and usually without any record at all. The record does not need to be long. It needs to survive the meeting where the decision was made.

What makes ADRs work, and why it carries over

Three features make architecture decision records useful, and all three apply to business decisions.

Every record has the same fields, so readers can find the conclusion without wading through prose. Every record has a status (proposed, accepted, replaced), so readers know whether it is current. And every record lists the options that were rejected, so nobody proposes the losing option again in six months without knowing why it lost.

The team decision record template

Field	What to write
Title	Short and specific. "Pricing: annual plans only for new customers," not "pricing discussion"
Status	Proposed, accepted, or replaced by a later record
Context	The situation that forced the decision, in two or three sentences
Decision	One sentence, stated as a fact
Why	The two or three reasons that tipped it
Options rejected	What else was considered, with one line on why each lost
Consequences	What this commits the team to, what it makes harder, what it makes unnecessary
Authority	Who decided, and what it would take to reopen it
Date and review	When it was decided, and when to look at it again

A worked example: a pricing decision

Field	Entry
Title	Pricing: annual plans only for new customers
Status	Accepted
Context	Customers on monthly plans leave sooner and need more support than annual customers. Enough customers already choose annual plans to show the model works for us.
Decision	From the start of next quarter, new customers can buy annual plans only. Existing monthly customers keep their plans.
Why	Annual customers stay longer and cost less to support. Annual contracts also suit how larger customers buy, through a yearly budget and one invoice.
Options rejected	Raise the monthly price: likely to cut sign-ups more than it would help retention. Offer a monthly trial that converts to annual: the problem is commitment, not trial length.
Consequences	Fewer self-serve sign-ups at first. Sales needs new answers for customers who ask for monthly billing. Revenue becomes easier to forecast.
Authority	CEO and head of revenue. Reopen only with their approval and new evidence that sign-ups fell more than expected.

The record runs about two hundred words. A new account executive can read it in a minute and answer a customer's "why no monthly plan?" without asking anyone.

Decision log vs decision record

The two are easy to confuse. A decision log is a list: one row per decision, every decision, in date order. A decision record is a document: one decision, explained in full. Most teams need both. The log tells you what was decided. For the decisions that matter most, the log row links to a record that tells you why.

A simple test: if a decision took more than one meeting to make, or will be questioned by someone who was not there, it deserves a record. Everything else gets a row in the log.

How the record changes as the company grows

At twenty people, most decisions are made by a handful of people who all remember why. The record mainly helps new hires catch up. At two hundred people, the people affected by a decision often never met the people who made it. The record becomes the only way they learn what was decided and who to ask. That is also when decisions start getting made twice, by different teams, unless the records are easy to find.

The format does not need to change as you grow. What changes is the discipline around it: one place to keep records, a clear owner for each area, and a rule that a decision is not final until it is written down. A decision authority map helps with the second part.

Where to keep business decision records

Keep them in one place that everyone affected can read and search. A section of your team wiki works. A Notion database with a fixed template works. If your engineering team already keeps ADRs in a repository, a parallel folder for business records keeps both in the same format. What does not work is a mix of chat messages, shared docs and verbal agreements.

How to start without adding bureaucracy

Pick one area where your team most often reopens past decisions: pricing, hiring or go-to-market. Write three or four records for important past decisions in that area. Then agree that new decisions in that area are not final until they have a record.

Once people find that the records answer "why did we choose this?" in a minute instead of an afternoon, the habit spreads to other areas on its own. For how records fit with logs, authority maps and audit trails, see the guide to a system of record for decisions.

Where StandIn fits

When a team runs on StandIn, anyone can ask what was decided and who owns the call, and get an answer sourced to the person who did the work. If the head of revenue is on holiday when sales asks about annual-only pricing, their StandIn answers from the decision record, in their words, with the source. It never guesses about a decision nobody wrote down. See how StandIn works for leadership teams.