DACI decision-making template (+ DACI vs RAPID)

DACI is a decision-making framework that gives one decision four clearly named roles: Driver, Approver, Contributors, Informed. It's widely credited to Intuit, where it's said to have started as a decision-focused take on the RACI matrix, and was popularized for software teams by Atlassian's Team Playbook, which also ships a DACI template in Confluence. This page has a copy-paste DACI template, a worked example, a DACI vs RAPID vs RACI comparison, and the common ways it goes wrong.

The four DACI roles

Role	Who	What they do	How many
Driver	Usually the PM, tech lead or project owner	Gathers stakeholders and information, scopes the decision, and gets it made by the agreed date	One
Approver	The person accountable for the outcome	Makes the final call	Exactly one
Contributors	Subject-matter experts	Give recommendations and input. No vote	As many as needed
Informed	People affected by the outcome	Told the decision once it's made. Not consulted	As many as needed

The rule that matters most, and the one Atlassian's play stresses: one Approver. Everything else in DACI is there to make that one person's call well-informed and on time.

DACI template (Confluence or Notion)

Paste this into a Confluence page or a Notion page. In Confluence, put the top table inside a Page Properties macro and label the page daci so a Page Properties Report can list every open decision. In Notion, turn the table rows into database properties (Person for roles, Status, Date).

# DACI: [The question, e.g. "Which analytics vendor do we standardize on?"]

| Field         | Value                                           |
| ------------- | ----------------------------------------------- |
| Driver        | @one-person                                     |
| Approver      | @one-person                                     |
| Contributors  | @names                                          |
| Informed      | @names or teams/channels                        |
| Status        | Not started / In progress / Decided             |
| Impact        | Low / Medium / High                             |
| Decide by     | YYYY-MM-DD                                      |
| Outcome       | (filled in when decided)                        |

## Background
Why this decision is needed now. What happens if we don't decide.

## Relevant data
Research, metrics, customer feedback, costs. Link sources.

## Decision criteria
What a good answer must do, in priority order. Agree these with the
Approver before comparing options.

## Options considered

| | Option A | Option B | Option C |
| --- | --- | --- | --- |
| Description | | | |
| Pros | | | |
| Cons | | | |
| Cost / effort | | | |
| Meets criteria? | | | |

## Contributor input
@name: summary of their recommendation and reasoning.

## Decision
Approver: @name. Date: YYYY-MM-DD.
Chosen option and a short rationale. Note any dissent.

## Action items
- [ ] Task, owner, date
- [ ] Notify Informed group (channel/email)
- [ ] File in the decision log (link)

The structure follows the sections in Atlassian's DACI play (details, background, data, factors, options, action items, outcome), with a criteria step pulled forward so options are judged against something agreed in advance.

A worked DACI example

An illustrative example for a fictional 40-person software company:

# DACI: Which product analytics tool do we standardize on?

| Field         | Value                                              |
| ------------- | -------------------------------------------------- |
| Driver        | @priya (Product Ops)                               |
| Approver      | @marco (VP Engineering)                            |
| Contributors  | @lee (data eng), @noor (design), @dana (growth)    |
| Informed      | #product, #engineering, Finance                    |
| Status        | Decided                                            |
| Impact        | Medium                                             |
| Decide by     | 2026-11-07                                         |
| Outcome       | Option B, self-hosted open-source analytics        |

## Background
Two teams use different analytics tools. Metrics don't match between
dashboards, and both contracts renew in December.

## Decision criteria
1. Event data stays in our own cloud account (customer contracts)
2. Growth team can build funnels without SQL
3. Annual cost under the current combined spend

## Options considered
| | A: Hosted vendor X | B: Self-hosted OSS | C: Warehouse + BI only |
| --- | --- | --- | --- |
| Data residency | No | Yes | Yes |
| Funnels without SQL | Yes | Yes | No |
| Cost vs today | Higher | Lower (infra + ops time) | Lowest |

## Contributor input
@lee: B is fine if we budget about a day a month of ops time.
@dana: C is a non-starter for the growth team.

## Decision
Approver: @marco, 2026-11-05. Option B. Only option meeting criteria 1 and 2
within budget. @dana prefers A for ease of use but commits.

## Action items
- [ ] @lee: deploy and migrate event tracking by 2026-12-01
- [ ] @priya: announce in #product and #engineering
- [ ] @priya: file DEC-031 in the decision log

DACI vs RAPID vs RACI

	DACI	RAPID	RACI
Built for	Making a specific decision	Making a specific decision	Assigning responsibility for tasks or deliverables
Origin	Credited to Intuit; popularized by Atlassian	Bain & Company	Project management practice (responsibility assignment matrix)
Roles	Driver, Approver, Contributors, Informed	Recommend, Agree, Perform, Input, Decide	Responsible, Accountable, Consulted, Informed
Final decision-maker	Approver (one)	Decide (one)	Accountable (one per task)
Veto role	None	Agree: narrow veto (e.g. legal, compliance)	None
Execution named?	No	Yes (Perform)	Yes (Responsible)
Best for	Product and engineering teams that want something light	Large or regulated orgs where some functions must sign off	Ongoing work and project task ownership

Rough guide: use DACI for most team-level product and engineering decisions. Use RAPID when a function like legal or security genuinely needs veto rights and you want that explicit. Use RACI for who does what on a project, not for one-off decisions.

Common DACI mistakes

• Two Approvers. "Product and Engineering both approve" means nobody does. Pick one, or split the decision.
• Driver and Approver are the same person on every decision. Sometimes fine for small calls, but if it's always the case, DACI is just adding paperwork to how you already decide.
• Treating Contributors as voters. Contributors inform the call. Counting their opinions turns DACI back into decision by committee.
• No decide-by date. The Driver's job is to get the decision made by a date. Without one, the page stays "In progress" forever.
• Roles assigned after the debate. Fill the table first. Arguing about options before agreeing who decides is how DACI pages end up as long comment threads.
• Informed never actually told. Put "notify Informed" in the action items and tick it.
• The outcome stays on the DACI page. The DACI page is the process. Once decided, file the outcome somewhere people look for current decisions: a decision log, a Confluence decision register, or an ADR for architecture calls. For bigger technical changes, the Driver's work often happens through an RFC.

After the decision

DACI is good at making a decision. It doesn't help much with what happens next: the decision needs to stay findable and be followed by people who weren't on the page, including AI coding agents that start every session with no memory of it. That's where decision drift begins.

Lockstep handles that step. It drafts decision entries from Slack, Jira and Confluence (including DACI pages), sends each to its owner, usually the Approver, for one-click approval, and briefs engineers and coding agents on the approved ones. It's open source and early. Keep running DACI the way you do; Lockstep is for making sure the outcome is remembered. For other options, see the decision log tools comparison.