- A RACI matrix maps four roles to every task: Responsible (does it), Accountable (owns it), Consulted (gives input), Informed (gets told).
- The single rule that makes or breaks it: exactly one Accountable person per row. Two A's means nobody owns it.
- Build it with the team in the room, not alone at your desk. The disagreements that surface are the whole point.
- A RACI says who. It only changes behavior when the steps behind each task are actually written down somewhere people can find them.
A product team I worked with shipped a feature with a broken pricing page live for nine hours. Afterward, the post-mortem turned up the real cause in about two minutes. The PM thought the engineer was running the final go/no-go check. The engineer thought the PM owned it. Both were "responsible." Neither was accountable. So the page went out, nobody pressed the button that would have caught it, and a customer found the bug before the team did.
That's the exact failure a RACI matrix is supposed to prevent. And it's also the failure a badly built RACI quietly causes, because most of them mark three people "Responsible" on the risky row and leave the owner blank.
A RACI matrix is a simple grid: tasks down the side, people across the top, and a letter in each cell saying what role that person plays. Done well, it ends the "I thought you had it" conversation before it starts. Done as a box-ticking exercise, it's a colorful spreadsheet that everyone nods at in the kickoff and nobody opens again. Here's how to build the first kind.
Why most RACI matrices change nothing
I've seen plenty of these charts, and the ones that fail tend to fail the same handful of ways.
They get built alone. A project lead fills in the whole grid at their desk, presents it as finished, and treats any pushback as a threat to the plan. But the conversation is the value. When you assign roles in a room, you find out the data team didn't know they were on the hook for the migration, and you find it out now instead of during the migration.
Every row has two or three A's. Sharing accountability feels collaborative and generous. It's neither. It's how you recreate the broken-pricing-page story, where two owners each assume the other is watching.
Everyone is Consulted on everything. Marking a stakeholder "Consulted" feels polite, so the column fills up. Now a five-step task needs sign-off from nine people and moves at the speed of the slowest inbox. Every C you add is a small tax on every decision.
It's made once and never touched. The team reorganizes, someone leaves, the process shifts, and the chart still names a person who changed teams two quarters ago. A RACI that doesn't match who actually does the work teaches people to ignore it.
What R, A, C, and I actually mean
The letters are easy to recite and easy to misuse. The difference between Responsible and Accountable is where most teams go wrong, so it's worth being precise.
Responsible is the person doing the hands-on work. A task can have more than one R if several people genuinely share the doing. Write the support reply, run the script, draft the contract.
Accountable is the single owner. They sign off, and if it goes sideways, they're the one explaining what happened. On small tasks the R and the A are the same person. On bigger ones they split: an engineer is Responsible for the fix, the team lead is Accountable for the decision to ship it. There is always exactly one A.
Consulted means you actively ask for their input before you act, and you wait for the answer. It's a two-way conversation. Reserve it for people whose input actually changes what you do, not everyone who likes to be in the loop.
Informed means you tell them once it's done. One-way, no reply needed. This is where most "Consulted" people actually belong. Legal doesn't need to weigh in on the wording of every release note; they need to know it went out.
How to build a RACI matrix in five steps
The method is short. The discipline is in step two and step four, where it's tempting to take the easy answer.
1. List the tasks that actually need an owner
Not every micro-step. Pick the ten to fifteen decisions and deliverables where confusion shows up: approvals, handoffs, the moment work crosses from one team to another. Frame each as a real thing that gets done — "approve the refund," "publish the help article" — not a vague area like "communication."
2. Put the roles across the top, not the names
Use job roles, not people's names. "Support Lead," not "Priya." People change seats; the chart shouldn't break every time they do. It also keeps the conversation about the work instead of about personalities.
3. Fill in one A per row first
Before anything else, go row by row and name the single Accountable owner. Doing the A column first forces the hard call early, while everyone's still in the room. If a row has no obvious owner, you've found a gap that would have bitten you later. If it has two candidates, you've found a turf question worth settling now.
4. Add R, then be stingy with C and I
Mark who's Responsible for the doing. Then add Consulted and Informed sparingly. For every C, ask: does their input genuinely change the outcome, or do they just want visibility? If it's visibility, they're Informed. This single filter keeps your process from drowning in sign-offs.
5. Walk every named role through their row
Read the chart back to the people in it. "Support Lead, you're Accountable for the escalation call and Consulted on the refund. Sound right?" Watch for the flinch. Every surprised face is a misalignment you just caught for free. This is the same move that makes an documented process stick: it isn't real until the person doing it agrees it's real.
A copy-paste RACI template (with example)
Steal this. Tasks down the left, roles across the top, one letter per cell. Here it is filled in for a customer-offboarding process, so you can see what "one A per row" looks like in practice.
RACI matrix: Customer offboarding
| Task | Account Mgr | Support | Finance | Eng |
|---|---|---|---|---|
| Confirm cancellation request | A | R | I | – |
| Process final invoice | C | – | A R | – |
| Export customer data | I | C | – | A R |
| Revoke account access | I | I | – | A R |
| Send offboarding summary | A R | I | I | I |
Read it: every row has exactly one A. R = does the work, C = asked first, I = told after, – = not involved. Blank columns of I's are a hint to drop a role from the chart.
To make your own, swap in your tasks and roles and keep three rules in front of you: one A per row, an R on every row (someone has to do it), and a hard look at every C before it stays. If a row ends up all I's and no R, the task has no doer and the process will stall there.
The mistakes that turn a RACI into wallpaper
Beyond the build itself, a few patterns reliably kill a RACI after launch.
Assigning roles by politics, not by work. Giving a senior stakeholder an A on a task they'll never actually own keeps the peace in the meeting and changes nothing on the ground. The chart has to match who really does the work, or people route around it.
Confusing a RACI with a plan. The matrix says who, not when or how. It pairs with a timeline and with the actual procedures. On its own it can tell you the owner of "deploy the release" without anyone knowing the deploy steps.
Letting it drift. Put an owner and a review date on the chart itself, the same way you would for any SOP. When the team changes shape, the RACI is the first thing that goes stale, and a stale one is worse than none because it looks authoritative while being wrong.
Going too granular. If your rows read like a step-by-step list — "open the dashboard," "click export" — you've built the wrong artifact. Those are work-instruction steps. A RACI sits one level up, at decisions and deliverables. The steps live in the guide the owner follows.
From chart to actually doing the work
Here's the part most RACI guides skip. A finished matrix tells the Account Manager they own "send the offboarding summary." It does not tell them what goes in the summary, which template to use, or where the data comes from. So the new Account Manager who inherits that A still pings the team channel asking how to actually do it. The confusion didn't disappear. It moved from "who" to "how."
A RACI is only as good as the documentation sitting behind each owned task. The owner needs a real, step-by-step guide they can open and follow. That pairing — one clear owner, plus the exact steps for what they own — is what turns a chart into behavior.
This is the gap WriteHow is built to close. Once your RACI names the owner of a task, you record yourself doing that task once, and WriteHow drafts a step-by-step guide from the recording: ordered steps, screenshots, and annotations, with sensitive details auto-blurred. You review and approve it before anyone sees it, so the AI does the tedious first draft and you keep the final say. If your owners sit across regions, the same guide can be published in 50+ languages without rebuilding it. The RACI says who owns "export customer data." The guide shows that owner exactly how, even on their first day in the role.
Build the matrix with the team in the room. Name one owner per row. Be ruthless about the Consulted column. Then write down the steps behind each owned task so the chart actually changes what people do. That's the difference between a RACI matrix that sticks and one that ends up as wallpaper in a kickoff deck nobody reopens.
Frequently asked questions
What does RACI stand for?
Can a task have more than one Accountable person?
What is the difference between Responsible and Accountable?
When should I use a RACI matrix?
How is a RACI matrix different from a process map?
One owner is half the job
Name the owner with a RACI, then let WriteHow turn a single recording into the step-by-step guide they follow — screenshots, auto-blur, and 50+ languages. AI drafts it, you approve it.
See how WriteHow helps