A RACI matrix example is easiest to understand when you stop staring at a blank template and look at one decision a company makes over and over: approving a discount on a sales deal. Put the same grid in front of three people at the same company and you get three different matrices. Only one of them survives a rule check. This article walks through all three, shows exactly what breaks, and ends with the corrected matrix and the short SOP that sits behind it.
Key takeaways
- A RACI matrix example is only useful if you run it through a rule check, because a grid can look tidy and still leave a decision with nobody in charge.
- Every task needs exactly one Accountable — the person who answers for the outcome, not the person who does the work.
- Adding Consulted roles to a fast decision turns a five-minute approval into a waiting room with no closing time.
- A row with no Accountable is the row that stalls, and stalled rows land back on whoever wrote the matrix.
RACI matrix example: the discount approval
The decision: a rep wants to take a chunk off list price to close a deal this week. Who says yes?
It is a small decision. It is also the kind that generates the most friction, because everyone has an opinion about it and nobody has written down who decides. Here is how three people fill in the same five-task grid.
Version 1: The sales rep who thinks they are being helpful
The rep wants to move fast and not bother anyone, so they take accountability for everything:
- Ask for a discount — R, A: Sales rep
- Approve the discount — A: Sales rep; C: Sales manager; I: Founder
- Set the final price — A: Sales rep
- Send the revised quote — R, A: Sales rep
- Log the deal in the CRM — R, A: Sales rep
What the rule check flags: the rep is Accountable on every single row, including the approval they have no authority to give. The tool marks the repeated Accountable as a single point of failure, and it marks the Consulted sales manager on the approval row as a consultation that never happens in practice — the rep asks nobody and hopes the discount goes through unnoticed.
When the discount is questioned later, the rep is the only person on the hook, and they were never the person with the authority. That is how helpful becomes a bottleneck in reverse.
Version 2: The sales manager who has read about RACI
This manager understands that one person must be Accountable, so they make themselves Accountable for everything — and then, to be thorough, they consult everyone:
- Ask for a discount — R: Sales rep; A: Sales manager
- Approve the discount — R: Sales rep; A: Sales manager; C: Legal, C: Finance, C: Founder
- Set the final price — A: Sales manager; C: Finance
- Send the revised quote — R: Sales rep; A: Sales manager
- Log the deal in the CRM — R: Sales rep; A: Sales manager
What the rule check flags: three Consulted roles on a two-minute decision, and nothing in the matrix says when those three are supposed to answer. The tool also flags the Accountable sitting on rows the manager never touches. In practice the discount waits for three replies that were never requested with a deadline, and the rep starts chasing.
Version 3: The founder who wants to stop being the bottleneck
The founder is tired of approving discounts, so they pull themselves out of the approval and leave it to the team. They leave something else out too:
- Ask for a discount — R: Sales rep; C: Founder; I: Sales manager
- Approve the discount — R: Sales rep; C: Founder; I: Sales manager
- Set the final price — R: Sales rep; C: Founder
- Send the revised quote — R: Sales rep; I: Sales manager
- Log the deal in the CRM — R, A: Sales rep
What the rule check flags: no Accountable on four of the five rows. The no-A flag is the loudest one the tool has, because a row without an Accountable does not get decided — it gets deferred until someone senior enough feels uneasy. In this company, that someone is the founder, so the discount lands on them anyway. The matrix looks decentralized and behaves exactly like a bottleneck.
What the rule check catches
| Version | What the grid looks like | What the rule check flags |
|---|---|---|
| Sales rep | One person Accountable on every row | Repeated Accountable; a consultation that never happens |
| Sales manager | A clear Accountable, plus three Consulted roles on the approval | Consultation bloat with no response deadline |
| Founder | No Accountable on most rows | Orphaned tasks that default back to the most senior person |
| Corrected | One Accountable per row, one bounded exception | Nothing structural — the escalation path is written down |
You can reproduce this yourself in a few minutes: name the roles, list the tasks, click a cell to cycle through blank, R, A, AR, C and I, and let the free RACI matrix generator flag the rows before you share them.
The corrected matrix
One Accountable per row. Consultation only where it changes the answer. An explicit exception path so the founder is in the loop by design, not by default.
- Ask for a discount — R: Sales rep; A: Sales manager
- Approve a discount inside the band — R: Sales rep; A: Sales manager; I: Founder
- Approve a discount above the band — R: Sales manager; A: Founder; C: Finance; I: Sales rep
- Set the final price — R: Sales rep; A: Sales manager
- Send the revised quote — R: Sales rep; A: Sales manager
- Log the deal in the CRM — R: Sales rep; A: Sales manager
The founder appears once, on the exception, with a named role and a defined trigger. That is the difference between being consulted and being ambushed.
The SOP behind the approval task
Write a few lines behind the task and you have a standard operating procedure you can hand to anyone. This is the paragraph that gets exported as a PDF:
Discount approval. The sales rep requests a discount in the deal record with three fields: list price, requested percentage, and a one-line reason. The sales manager approves or rejects inside one business day; if no answer comes back, the deal goes out at list price and the rep can re-request with new information. Discounts inside the band are the manager's call and need no other signature. Discounts above the band go to the founder with the same three fields attached, and the founder answers inside one business day. Finance is consulted only when the discount changes payment terms. Once the decision is made, the rep updates the deal record and the customer hears back the same day. No discount is approved in a chat thread.
That paragraph is the whole point of the exercise. The matrix tells you who decides; the SOP tells everyone what to do while the decision is being made. Together they turn a recurring interruption into a documented path that runs without you.
Quick checklist
- Pick one decision that keeps landing on you — a discount, a refund, a vendor sign-off.
- List the tasks that make up the decision, including the ones that happen after approval.
- Name the real roles, not the people, so the matrix survives a departure.
- Put exactly one A on every row and confirm that person can actually say no.
- Cut Consulted roles down to the ones whose answer would change the outcome.
- Write the SOP in one short paragraph and export the matrix and the SOP as a PDF.
Start with the decision you dread
Pick the decision you are most tired of being pulled into. Fill in the grid, run the rule check, fix the rows with no A, and write the paragraph behind the task. Then share the PDF with the team so the next time the decision comes up, it resolves without a meeting.
The EXIUSS RACI Matrix Engine does the drafting and the flagging for free, and exports the whole thing as a PDF, CSV or text file. A few minutes of writing now, and the decision stops landing on you.