The failure this prevents
A customer emails about a damaged item. Two people see it. Both assume the other is handling it because both have handled one before. Nobody replies for two days.
Nothing went wrong with anyone's judgement. The problem is that "who deals with damage claims" was never decided, so it gets decided implicitly, differently, every time. Implicit ownership works while the team is small enough to read each other, and stops working shortly after.
A RACI is the formal fix. The name is off-putting and the corporate versions are bloated, but the underlying idea is simple and it takes an hour for a small store.
What the letters mean, briefly
- Responsible. Does the work. Can be more than one person, though fewer is better.
- Accountable. Owns the outcome. Exactly one person, always. This is the letter that does the work.
- Consulted. Asked before a decision is made.
- Informed. Told afterwards.
For a team under about ten people, R and A carry nearly all the value. C and I matter for bigger decisions and can be left off most rows without losing anything.
The rule that matters: exactly one Accountable per row. Two accountable people is the same as zero, which is the failure you are trying to fix.
A starter grid
Adapt rather than copy. The roles below are functions, not job titles, and one person will hold several in a small store.
| Area | Accountable | Responsible |
|---|---|---|
| Order fulfilment and dispatch | Ops lead | Whoever is on shift |
| Stock levels and reordering | Ops lead | Ops lead |
| Supplier relationships | Owner | Owner |
| Customer emails and complaints | Support lead | Support, VA |
| Damage and loss claims | Support lead | Support lead |
| Refunds above a set value | Owner | Support lead |
| Returns processing | Ops lead | Whoever is on shift |
| High-risk order decisions | Owner | Ops lead |
| Product listings and pricing | Owner | Marketing |
| Promotions and campaigns | Marketing | Marketing |
| Store settings and apps | Owner | Owner |
| Staff access and offboarding | Owner | Owner |
Building yours in an hour
- List the areas, not the tasks. Ten to fifteen rows. If you are past twenty you are listing tasks, which produces a document nobody reads.
- Assign Accountable first, and force one name. When you cannot decide, that row is the one causing your failures. Resist writing two names or a team.
- Add Responsible where it differs. Often it is the same person. Only fill it in when it genuinely differs.
- Mark the thresholds. Refunds above what value need the owner? Which decisions can the person on shift make alone? Ambiguity about limits is as costly as ambiguity about ownership.
- Read it aloud to the team. Not circulated, read. Disagreement surfaces in the room and stays silent in an inbox.
The rows that cause arguments
Three areas reliably produce disagreement, and the disagreement is the useful part.
Customer complaints that are partly operational. A late delivery is a support problem and a fulfilment problem. Someone has to own the customer outcome even though the cause sits elsewhere. Split it: support owns the customer, ops owns the cause.
Stock decisions with a marketing cause. Marketing pushes a product, it sells out, ops is blamed. The real gap is that marketing was not Consulted on stock depth before the campaign. This row is where the C in RACI earns its place.
Anything the owner has not delegated but does not do. Common and awkward. The owner is nominally accountable for a dozen areas and actively involved in three. The remaining nine have no real owner while appearing to. Better to delegate explicitly or accept they are unowned than to leave a name on a row that means nothing.
Making it live somewhere useful
A RACI in a document that nobody opens has no effect. It works when it is where the work happens.
Practically, that means two things. First, the grid should be pinned or linked somewhere the team already looks, rather than in a folder. Second, and more usefully, the ownership should be reflected in how work is actually assigned: if support owns damage claims, damage claims should arrive as tasks assigned to a named person, not as messages in a general room that everyone can see and nobody owns.
That is the connection between this document and daily practice. The grid decides who owns what; task assignment enforces it one item at a time. A grid without enforcement drifts back to implicit ownership within a month. Our post on turning messages into tasks covers the enforcement side.
Reviewing it
Twice a year, and whenever someone joins or leaves. A departure is the moment a RACI proves its value: instead of discovering over six weeks what that person quietly owned, you have a list.
That alone justifies the hour. Most small teams learn the full scope of a role only after the person holding it has gone, and by then the knowledge has left with them.
Common questions
Is a RACI overkill for a team of four?
The full corporate version is. A one-page grid with Accountable and Responsible columns is not, and four people is around where implicit ownership starts to fail.
Can two people be accountable for the same area?
No. That is the specific failure the framework exists to prevent. Two accountable people produces the same outcome as none.
What if the owner is accountable for everything?
Common in small stores and usually inaccurate. If the owner is not actively involved in an area, the row has no real owner. Delegate it explicitly or acknowledge it is unowned.
How often should it be reviewed?
Twice a year, plus whenever anyone joins or leaves. A departure is when the document earns back the hour it took to write.
Where should it live?
Somewhere the team already looks, and reinforced by how work is assigned day to day. A grid that only exists as a document drifts back to implicit ownership within weeks.