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.
Filling it in when you disagree
The rows that produce argument are the valuable ones, and the argument is the point rather than an obstacle. Three patterns come up repeatedly.
Two people both think they own it. Usually harmless and occasionally expensive, because both act and the customer gets two answers. Decide by asking who is accountable for the outcome rather than who does the work, since the second can be shared and the first cannot.
Nobody wants it. Almost always a task that is unpleasant, unclear, or both. Assigning it to whoever objects least does not work. Break it into smaller pieces and the ownership usually becomes obvious, or accept that it is genuinely nobody's and decide whether it needs doing at all.
The honest answer is the owner, for everything. Common in stores under five people and worth confronting. If the owner is accountable for twelve rows and actively involved in three, the other nine have a name against them and no real owner. Delegate explicitly or mark them unowned; a name that means nothing is worse than a blank, because it stops anyone asking.
Using it when something goes wrong
The grid earns its keep during a failure, not during a planning session.
When something is dropped, the useful question is not who is at fault. It is whether the row existed, and whether the person named knew they owned it. Most dropped work traces to one of three things: no row, a row with two names, or a row whose owner had never been told out loud.
Fixing the grid takes two minutes and prevents the same failure recurring. Assigning blame takes longer and prevents nothing.
What a RACI does not solve
Worth being clear, because the document can create false confidence.
It does not create capacity. Naming an owner for twelve areas across three people does not make three people able to cover twelve areas, and a grid that looks complete can disguise a staffing problem by making it appear organised.
It also does not substitute for authority. Someone accountable for refunds who has to ask before issuing one is not accountable, whatever the grid says. The two documents work together: this one names the owner, and your decision thresholds say what that owner is allowed to do without checking.
Keeping it to one page
The version that survives is short. Ten to fifteen rows, two columns, one screen.
Every addition beyond that reduces the chance anyone reads it, and an unread grid provides exactly the same coverage as no grid while creating the impression of coverage. If your list is running past twenty rows, you are listing tasks rather than areas, and the fix is to group them.
Where to keep it
Pinned where the team already works, not filed in a drive. A grid nobody can find during a disagreement is a grid that does not exist, and the disagreement is exactly when it earns its keep.
The hour it takes
List the areas, assign one accountable name to each, add the thresholds, and read it aloud to the team. That last step is what turns a document into an agreement, and it is the one most often skipped.