Most RACI chart examples are abstract: generic columns, generic roles, nobody learns anything. This raci chart example uses one decision you probably deal with every week — approving a customer refund — and shows the same grid filled in three different ways by three different people, then run through the rules to see what each one got wrong.
The point is not the refund. The point is that a five-minute decision can be documented once, in a single grid, and then it stops landing on anyone.
Key takeaways
- A support rep who marks themselves Accountable on every row hasn't built a matrix, they've built a permission slip — and the rule checker will flag it immediately.
- Putting three people in Consulted on a two-minute decision doesn't spread the responsibility, it multiplies the waiting.
- A matrix with no Accountable at all is the most common failure: everyone is Responsible, nobody decides, and the refund stalls until the founder steps in.
- The corrected version assigns exactly one A, keeps C to the people whose input actually changes the outcome, and pairs the grid with a short SOP so the decision runs the same way every time.
Why a real example beats a template
A blank RACI template tells you the letters stand for Responsible, Accountable, Consulted and Informed. It doesn't tell you where people go wrong, because the blank grid has no people in it yet.
The failures show up at the moment of filling. Someone reads about RACI, decides it sounds reasonable, and then quietly encodes their existing habits into the grid: the person who wants to be helpful takes every row, the person who has just enough theory over-consults, and the person who is drowning in decisions builds a matrix that grants them no relief at all.
So here is the same task — approving a customer refund — filled in three times. The decision itself is ordinary: a customer asks for money back, someone has to say yes or no, and the customer needs an answer.
The task: approving a customer refund
Strip it to its parts. A refund request arrives. Someone reviews the order and the claim. Someone decides the amount and whether it's approved. Someone moves the money. Someone records it. Someone tells the customer.
The step that hurts is the decision itself, and that is the row every one of the three matrices below gets wrong in a different way.
Matrix 1: The support rep who thinks they're being helpful
The rep wants to be dependable, so they fill the grid out like this:
| Task | Support Rep | Finance Manager | Founder |
|---|---|---|---|
| Log the refund request | A | ||
| Decide approval | A | ||
| Process the payment | A | ||
| Record the refund | A | ||
| Notify the customer | A |
The intent is good. The grid is useless. Every single row has one person Accountable and nobody else involved at all. That is not a role clarity document; it's a statement that the rep does everything and owns everything.
What the checker flags: the matrix repeats a single role across every Accountability. When one person is Accountable for everything, nothing is actually being divided, and there is no separation between doing the work and owning the outcome. The rep has also been made Responsible for processing a payment they almost certainly don't touch, which means the grid now misdescribes reality.
The practical damage: when the rep takes a refund request they can't approve, and the grid says they're Accountable for approval, there's no rule telling them to escalate. So they either guess, or they ask someone, and the decision is back to being ad hoc.
Matrix 2: The finance manager who has read about RACI
The finance manager has absorbed the theory and comes back with this:
| Task | Support Rep | Finance Manager | Founder | Legal |
|---|---|---|---|---|
| Log the refund request | R | I | I | |
| Decide approval | R | A | C | C |
| Process the payment | R | I | ||
| Record the refund | R | I | C | |
| Notify the customer | R | I |
This looks far more like a proper matrix: there's an A on the decision row, there's an R, there are C's and I's. And on a two-minute decision, the decision row now requires input from the founder and from legal before it can close.
What the checker flags: three Consulted roles on one decision row. Consulted means their input can change the outcome — it is not a courtesy copy. Making the founder and legal Consulted on every routine refund converts a yes-or-no call into a three-way conversation, and the finance manager has just built a decision that cannot move quickly.
The second issue is quieter: the finance manager made themselves Accountable while the rep is Responsible for the decision. That part can work — the rep prepares and recommends, finance owns the call — but only if the threshold for when it escalates is written down. Without that, the rep doesn't know which refunds they can just recommend and which need finance's attention.
The practical damage: every refund now waits on two people who mostly don't need to weigh in. The finance manager has documented a bottleneck and called it governance.
Matrix 3: The founder who wants to stop being the bottleneck
The founder is tired. Refunds keep arriving in their inbox. So they draw the grid they think solves it:
| Task | Support Rep | Finance Manager | Founder |
|---|---|---|---|
| Log the refund request | R | I | |
| Decide approval | R | R | |
| Process the payment | R | ||
| Record the refund | R | ||
| Notify the customer | R |
Look at the decision row: two R's, no A. The founder removed themselves from the grid but never named who now owns the outcome. They spread Responsibility around and stopped there.
The checker flags: no Accountable on the approval row — the single most common rule break in a RACI chart. Responsible means does the work. Accountable means the one throat to choke when it goes wrong. With two Responsible parties and no Accountable, the decision belongs to whoever feels bravest that day, and when it's disputed or unusual, it climbs back up to the founder anyway.
The practical damage: nothing changed. The founder still gets every hard refund, plus now they get the arguments about who should have decided.
The three failures side by side
| What was filled in | The rule it breaks | What it feels like day to day |
|---|---|---|
| One person Accountable for every row | Accountability isn't divided; the grid misdescribes the work | Nothing escalates cleanly; hard calls land back on someone |
| Three Consulted on one decision | C is for input that can change the outcome, not for courtesy | Routine refunds wait on people who don't need to weigh in |
| No Accountable on the decision row | Every decision needs exactly one A | Refunds stall until a senior person intervenes |
The corrected matrix
Here is the version that holds. One task, one Accountable, Consulted limited to input that genuinely changes the outcome, Informed kept to the people who need the result and not the debate.
| Task | Support Rep | Finance Manager | Founder | Customer |
|---|---|---|---|---|
| Log the refund request | A/R | I | I | |
| Decide approval | R | A | C | |
| Process the payment | I | A/R | ||
| Record the refund | A/R | I | ||
| Notify the customer | A/R | I | I |
The decision row now reads: the rep is Responsible (they gather the facts and make the recommendation), finance is Accountable (they own the call and the consequence), the founder is Consulted only when the refund crosses a threshold the team defines, and the customer is Informed of the result.
That's the whole fix. One letter moved, two letters removed.
The SOP behind the row
A grid tells you who decides. It doesn't tell you what good looks like when they do it. That's the paragraph behind the row — a few lines that become a standard operating procedure:
Refund approval: the support rep logs the request in the help desk with the order ID, the reason, and the requested amount. They check the request against the refund policy and recommend approve or decline. Refunds within the standard threshold are approved by the rep on the record; anything above the threshold, anything involving a disputed charge, and any repeat refund to the same customer go to the finance manager with the rep's recommendation attached. Finance decides within one business day and records the decision and reason on the ticket. The rep notifies the customer once the decision is recorded. The founder is consulted only on policy exceptions, not on individual refunds.
That's it. Five minutes of writing, once. Now the rep knows exactly what they can approve, finance knows what lands on them and when, the founder has been removed from the routine path without being removed from the exceptions, and the next refund doesn't start a conversation.
Start with one decision
Don't matrix your whole operation. Pick the decision that keeps landing on you — refunds, discounts, scope changes, time off, whatever it is — and fill in one row honestly. Then check it against the rules: exactly one Accountable, Consulted only where input changes the outcome, Informed only where the result matters, and no row with two A's or none.
You can do that on paper. Or you can build it in the free RACI matrix generator at https://tools.exiuss.com/raci-matrix, which lets you list the roles and tasks, click a box to cycle through blank, R, A, AR, C and I, flags where the matrix breaks RACI rules, and exports the whole thing as PDF, CSV or text. It also drafts the SOP behind each task from your own inputs — you write a few lines and it helps you turn them into a full standard operating procedure.
One decision, documented once. Then it stops landing on anyone.
Quick checklist
- Pick one recurring decision that keeps reaching a senior person.
- List the tasks that make up that decision as separate rows.
- Assign exactly one Accountable per row — no row with two A's or none.
- Cut every Consulted that can't actually change the outcome.
- Write the SOP paragraph behind the decision row: threshold, escalation path, record, notification.
- Export it and put it where the team already works.