RAPID Decision-Making Model: Bain's Framework for Clear Decision Roles

By Brian Tr · Updated Oct 10, 2026

RAPID is a decision-roles tool from Bain & Company. It names five roles in any significant decision: Recommend, Agree, Perform, Input, and Decide. Each person gets a defined part, and exactly one person holds the final call (the "D"). The aim is to remove the confusion over who proposes, who advises, and who decides.

This guide explains each role, the Agree versus Input distinction that trips most teams up, how RAPID compares with RACI and DACI, and how to run it step by step. You'll also get a role chart template you can copy and examples across business functions.

Key Facts

• What it is: a framework for assigning roles in a decision process, so accountability is clear before the debate starts.
• Origin: developed by Bain & Company and described by Bain partners Paul Rogers and Marcia Blenko in the January 2006 Harvard Business Review article "Who Has the D? How Clear Decision Roles Enhance Organizational Performance".
• The five roles: Recommend (R), Agree (A), Perform (P), Input (I), Decide (D).
• Not a sequence: the letters spell a word, not a workflow. Bridgespan, which adapted the tool with Bain's permission, stresses that the acronym doesn't specify the order of steps.
• Not about speed alone: the same source says the point is clarity and accountability at the appropriate pace, not the fastest possible pace.
• One D: one person (or one group with a stated voting rule) makes the final decision and commits the organization.
• Trademark: RAPID is a registered trademark of Bain & Company, Inc.
• Best for: cross-functional decisions with many stakeholders, such as pricing changes, reorganizations, major hires, and market entry.

What is the RAPID decision-making model?

RAPID is a way to assign roles in a decision process. According to Bridgespan's guide, it clarifies who provides input, who shapes the decision and ultimately decides on it, and who carries it out afterwards.

The idea behind it is simple. Most decision pain isn't a shortage of smart people. It's that nobody is sure who is supposed to do what. The HBR article's summary makes the case that decisions drive results: every success, failure, and missed opportunity traces back to a decision someone made or failed to make, and companies that let decisions stall inside the organization hurt their performance whatever their industry, size, or strategy.

So RAPID doesn't tell you what to decide. It tells you who recommends, who must be consulted, who has to sign off on feasibility, who executes, and who has the final say. That's why it sits comfortably next to strategy tools like the decision matrix. The matrix helps you compare options. RAPID helps you decide who gets to pick one.

A quick note on naming: RAPID is a Bain & Company trademark. When you adapt it inside your own company, keep the name attributed to Bain, or use a neutral label like "decision roles chart."

The five RAPID roles

Recommend (R)

The recommender runs the decision process. They gather facts, collect input from the right people, and develop a formal proposal for whoever holds the D. Bridgespan notes this is where the bulk of the work happens, and that the role carries a lot of influence because the recommendation shapes what the decider sees.

One person should own the R, though it can be a small task force if it has a clear way to settle disagreements internally. A good recommender has broad access to information and credibility with both the people giving input and the person deciding.

Agree (A)

The A is the role most teams misuse. Someone with the A must agree with the final recommendation, but the role is used for only some decisions. Think of the finance lead who sets the budget ceiling, the lawyer who explains the legal limits of a contract, or the engineer who specifies a safety requirement.

The A exists to help the recommender reach a workable proposal, not to veto a decision after the fact. Bridgespan's guidance is to use it sparingly and limit it to the person's own area of expertise. If you have six people with an A on a single decision, you haven't clarified anything. You've rebuilt the committee.

Perform (P)

The performer (or team) carries out the decision once it's made. It's usually smart to name the P early. When the people who have to execute are left out until the announcement, the plan tends to collide with reality. Giving them an I as well lets them raise implementation concerns before the recommendation is final, and they're more likely to back the outcome.

Input (I)

People with the I provide information and advice to the recommender. That can include anyone with relevant knowledge, anyone significantly affected, and outsiders such as customers, partners, or experts. Input is consultation, not a vote. The decider isn't obliged to follow the advice, and the recommender decides how to weigh conflicting views.

Bridgespan warns about the failure mode: when input is poorly gathered or ignored, it can feel like it's only for show.

Decide (D)

The D makes the final decision and commits the organization to act. Ideally this person understands the trade-offs and sits close to where the decision will be implemented. If a group holds the D, such as a board, it should agree in advance how it will decide: majority vote, or consensus with the chair breaking a tie.

You'll hear people in RAPID-using organizations ask, "Who has the D?" That's the title of the HBR article for a reason. But the Bridgespan guide cautions that the D isn't the only role that matters.

Agree vs Input: the distinction that matters

Both roles feed the recommendation. The difference is what happens if they object.

A practical test: if someone's "no" would genuinely make the decision unworkable (a legal block, a budget cap, a safety rule), they hold an A. If their view is useful but the decision could still stand without their blessing, they hold an I.

Common decision bottlenecks RAPID helps expose

Mapping roles tends to surface the same problems:

• No D at all. Everyone assumes someone else will decide, so the issue circles for weeks.
• Two or more Ds. Two leaders each think the call is theirs. Teams get contradictory instructions.
• Too many As. Reviewers pile up and each one can quietly stop progress.
• An R who isn't empowered. The recommender has no access to data or no standing with the decider, so proposals get redone.
• A P who hears about it last. The team executing finds out the decision only after it's final.
• Input that disappears. People are consulted, hear nothing back, and stop contributing.

None of these need a new strategy. They need someone to write down the roles.

RAPID vs RACI vs DACI vs consensus

RAPID is often confused with responsibility-assignment charts, but it answers a different question. RACI maps who does the work on a task. RAPID maps who shapes and makes a decision. If you want the full RACI breakdown first, see what is a RACI matrix and RACI vs RASCI vs DACI.

Use RACI to run a project's work, RAPID to settle the big calls inside it, and consensus only where buy-in matters more than speed. For ready-made RACI layouts, the RACI template examples page is a good companion.

How to use RAPID step by step

Step 1: Define the decision

Write the decision as a question with an answer: "Do we enter the German market in 2027?" A vague decision ("improve onboarding") can't have a D. If it's really several decisions, split them and give each its own chart.

Step 2: Name the D first

Pick the decider before anyone else. Choose someone with authority over the outcome who is close to where it will be carried out. If the D is a group, write down its voting rule.

Step 3: Assign the R

Choose the person who will do the analysis and build the proposal. Make sure they have access to data and credibility with the D.

Step 4: Decide who has an A

Ask for each candidate: would their "no" make the decision unworkable? If not, move them to an I. Keep the A list short, and tie each A to a specific constraint, such as budget or compliance.

Step 5: List the Inputs and the Performers

Include people who know the subject, people it affects, and the team that will execute. Putting the P on the input list helps surface implementation problems early.

Step 6: Agree on how and when

Set a deadline, a format for the recommendation, and how input will be collected. The chart says who. The process says how.

Step 7: Decide, communicate, and close the loop

Once the D decides, the decision is announced to the Performers and to those who gave input, along with the reasoning. Then the P executes. Keep the chart with the decision record so people can see how it was made.

RAPID role chart template

Copy this table into a doc or spreadsheet, one chart per decision. Put one name in R and one in D. Add names to the other columns as needed.

Rules to print under the table:

1. Exactly one D. If a group holds it, write the voting rule here: ______
2. One R, or a small task force with a stated tie-break.
3. Each A must name the constraint it protects (budget, legal, safety, technical).
4. Every P is also consulted as an I before the recommendation is final.
5. Inputs get a short note on what was decided.

RAPID examples by business function

These are hypothetical and meant to show the shape of a chart.

Notice the pattern. The A holders are specialists whose objection is a real constraint. Everyone else with an opinion goes under I.

RAPID dos and don'ts

Do

• Name the D before anything else. If you can't, the decision isn't ready.
• Keep the A list short. Tie each A to a rule, a limit, or a regulation.
• Involve the P early. The people who will execute should help shape the recommendation.
• Close the loop on input. Tell contributors what was decided and why.
• Use it for decisions that matter. Reserve it for cross-functional or high-stakes calls. For complex, ambiguous situations, a sense-making tool like the Cynefin framework can help you decide how to approach the problem before you assign roles.

Don't

• Don't treat the letters as a sequence. They're roles, not stages.
• Don't let the R and D collapse without checks. When one person holds both, they still need to weigh real input, as Bridgespan points out.
• Don't use an A as a hidden veto. If the objection isn't a constraint in their field, it's an I.
• Don't confuse input with a vote. Consultation informs the decider. It doesn't bind them.
• Don't draw a chart and then ignore it. A chart only helps if people follow it, and that depends on leaders reinforcing it. This is part of strategy execution more broadly, and it links to structure and shared values in the McKinsey 7S framework.

Learn more

• Decision matrix: compare options once you know who decides.
• Cynefin framework: match your decision approach to the kind of problem.
• Strategy execution: turn decisions into delivered results.
• McKinsey 7S framework: check that structure, systems, and culture support your decision rights.
• What is a RACI matrix: the task-level companion to RAPID.