RACI Chart for a Small Team: Who Owns Each Recurring Job, One Accountable Name per Row, and a Slack Check That Keeps It Live

It is the 3rd of the month and the client invoices have not gone out. The account lead thought the bookkeeper sent them. The bookkeeper was waiting for the account lead to confirm the hours. The founder finds out when a client asks why there is no bill, and spends the afternoon sending them by hand.
A RACI chart is the standard fix for "I thought you were doing that". It is a table with the work down the side, the people across the top, and one letter in each cell: R for Responsible (does the work), A for Accountable (owns the result), C for Consulted, I for Informed. This guide builds one for a team of 5 to 100 people that already runs in Slack. The payoff is a one-page chart of the recurring jobs that actually slip, one Accountable name on every row, and a weekly check that tells you when the chart has stopped matching reality, so you are not the one chasing.
Why ownership gaps happen on small teams
A commenter on Hacker News who had worked at a large company described how a complicated org chart and RACI make it easy to do little work and hide once a company reaches about a thousand people, while in smaller organisations too many people see you. That is one person's report. On a small team everyone can see everyone else's work, and things still slip, because the job sits between two people who each reasonably think the other has it.
Three patterns cause most of it:
- The job was never assigned, only inherited. Whoever did payroll inputs the first time kept doing them, until they went on holiday.
- Two people both think they own it. The account lead and the bookkeeper both touch invoicing, so each assumes the other sends.
- The owner left or changed role. The chart, if one exists, still names them.
The common guides are written for projects. Asana's RACI guide frames the chart around project tasks and deliverables, and even says a RACI may be unnecessary for small teams with simple tasks and clear roles because it adds admin work. That advice fits a five-person project, but small firms mostly lose recurring work, which project charts leave out.
Start from recurring jobs, not projects
Build the RACI chart from recurring jobs, not from projects, because at a small firm the work that falls through the cracks is the monthly invoice run, not the one-off launch.
A launch has a kickoff, a deadline and people paying attention. A monthly job has none of that. It runs because someone remembers, and the month someone forgets, nothing warns you until a client, an employee or the bank does. So the rows of your chart should be the jobs that repeat on a calendar or on a trigger: every month, every new client, every renewal, every new hire.
To find them, scroll back through the last two months of your ops or general channel and list every request that started with "did anyone", "who is", or "I thought you". Each one is a candidate row. Add anything with a legal or money deadline even if it has not slipped yet.
A RACI chart template for ten small-firm recurring jobs
Here is a starting chart for a made-up 12-person services firm. The names are roles; replace them with real names (more on that below). Copy it into a Google Sheet, a Notion page or a Confluence page, wherever your team already keeps documents.
| Recurring job | Founder | Ops lead | Bookkeeper | Account lead | Rest of team |
|---|---|---|---|---|---|
| Send client invoices (monthly) | I | C | A, R | C | - |
| Chase overdue invoices (weekly) | I | - | A, R | C | - |
| Approve and pay vendor bills | A | R | R | - | - |
| Payroll inputs and timesheets | I | A, R | C | - | R |
| Onboard a new client | I | C | C | A, R | I |
| Renew software subscriptions | C | A, R | I | - | I |
| Insurance and license renewals | A | R | I | - | - |
| New hire accounts and laptop | C | A, R | I | - | I |
| Monthly numbers for the team | A | R | R | C | I |
| Update the operations manual | C | A | - | C | R |
Read across one row. "Send client invoices": the bookkeeper both does it and owns it, the ops lead and the account lead are asked (hours, scope changes), the founder hears it is done. If invoices do not go out, there is one name to ask, and it is not the founder's.
Three rules make this table work:
- Exactly one A per row. Asana, FitSmallBusiness and the Oregon toolkit all say this; Asana puts it as there should be only one Accountable role per task. The Oregon Department of Administrative Services RACI toolkit defines the accountable party as the one who owns the result and has the authority to make the final decision. If two people hold that authority on one row, neither can settle it.
- At least one R per row. A row with an A but no R is a job someone owns and nobody does.
- Few Cs. Each C is someone who has to answer before the work moves. Add one only when the work is wrong without their input.
When a small team should merge R and A
On a team under about 20 people, let one person be both Responsible and Accountable on most rows and spend the effort on the one rule that matters: exactly one Accountable name per row.
This is a recommendation, and the sources do not fully agree on the details. Asana notes that on small teams one person can hold both R and A. FitSmallBusiness's guide to RACI charts says there should be only one Responsible and one Accountable person per task, and the Oregon toolkit goes further and says to assign only one party to each of the four roles. Other guides allow several Rs. For a small firm the disagreement mostly does not matter, because the same person usually does and owns the job. Where it does matter, follow this rule:
- One person does the whole job: write "A, R" in one cell. Most of your rows will look like this.
- Two people do parts of it (the ops lead preps vendor bills, the bookkeeper pays them): give both an R and keep a single A above them.
- A row has two people who both feel like the A: that is the row that causes your double work or your gaps. Decide it in a conversation, not in the spreadsheet.
Do not spend a meeting on whether the account lead is C or I on subscription renewals; settle the single A and move on.
Names, not job titles
Many templates use job titles across the top so the chart survives when people change. At a firm with one bookkeeper and one ops lead, the role is the person, and a role name hides the moment the person leaves. Use names in the cells, and keep a short note at the top of the doc listing who holds each role today. When someone leaves, the rows with their name are the rows to fix that week.
Agree it with the people on the chart
The Oregon toolkit's advice to involve the team in building the RACI is the step small firms skip, and the reason a founder's chart gets ignored. Share the draft in Slack, ask each person to check the rows with their name, and wait for an explicit yes on every A. An A someone never agreed to is not an owner.
A Hacker News commenter argued that RACI charts belong in meetings too: required attendees should be the Rs, and everyone else can be updated out of band. The same idea works for the chart review. Only the people who hold an A or R on a disputed row need to be in that conversation.
Keep the chart live with a weekly Slack check
Every guide warns that the chart goes stale. FitSmallBusiness calls the regular updates an administrative burden, Asana says charts go stale when priorities change, and the Oregon toolkit tells you to update it continuously to reflect current practice. None of them says who triggers the update or how. Without a named trigger, the update usually falls to the founder, who has the least time for it.
Make a weekly scheduled check list the rows with no Accountable name or more than one, and post them where owners already answer, so the chart stays live without someone policing it.
With the Kipwise agent installed in Slack, this is one request. Here is a made-up example in an #ops channel:
> @Kipwise every Monday at 9am, open our "Who owns what" Google Sheet and list any row with no A, more than one A, no R, or a blank "last checked" date. Post the list here and name the person in the Founder column for each one.
What happens, based on what the agent does today:
- Setting up the scheduled task shows an Approve or Deny card once. Later runs do not ask again.
- Each Monday it reads the sheet with the Google Drive access of the person who set up the job, using the same tools and permissions as a live request from them, and posts the result in the channel.
- People reply in that thread. Plain replies continue the conversation without a new mention: "Priya owns subscription renewals now, update row 6."
- Any edit to the sheet waits for an Approve card from the person who asked. Nothing changes in the doc on its own.
- You can list or cancel the job and ask what happened on previous runs, including failures.
Deciding who owns a job stays with people. The agent finds the rows that need a decision and puts them in front of the right person; it does not pick an owner. Our guide to scheduling recurring AI agent jobs in Slack covers how these jobs run unattended and what to watch.
Once every row has an owner, two related checks become easier. Open loops in threads can be chased to the named person, which is what our guide to keeping follow-ups from falling through the cracks in Slack covers. And a weekly status round can ask each A directly instead of the whole channel, as in our guide to getting team status updates in Slack without an ops coordinator.
Failure modes and how to handle them
The chart lists every task anyone ever did. A 60-row chart nobody reads protects nothing. Keep it to the jobs that repeat and that hurt when they slip. FitSmallBusiness makes the same point for project charts: list key tasks, leave out routine admin.
The founder is the A on everything. Then the chart records the current bottleneck and changes nothing. If your name is the A on more than a third of the rows, pick the three you most want off your plate and hand the A to the person who already does the work.
Someone is A on a job they cannot decide. The Oregon definition ties accountability to the authority to make the final decision. If the ops lead is A on vendor bills but needs the founder's sign-off above a set amount, write the threshold into the row ("A up to $2,000, founder above") instead of making the founder A for all of it.
The check posts the same rows every week. Rows that keep coming back are usually disputed. Move the discussion out of the weekly post into a short conversation with the two people involved, then record the result.
People leave and the chart keeps their name. Make "fix the RACI rows" a line on your offboarding checklist, and put a "last checked" date on each row so the weekly check catches rows nobody has looked at in a quarter.
How to tell it is working
Give it a month, then look for three signs:
- The "did anyone" and "who is doing" messages in your ops channel drop. Count them in the two weeks before and after.
- The weekly check posts fewer rows each week, and the rows it does post get answered in the thread the same day.
- When a job slips, the first message is to one named person, not to the channel.
If none of those move, the chart is probably too long or the As were assigned without agreement. Shorten it and go back to the people on it.
Is this worth doing before you hire a coordinator?
A founder who wants an operations coordinator often wants someone to track who owns what, because today the founder does it. A RACI chart for the ten jobs that slip, plus a check that runs every Monday, takes that tracking off the founder without a new hire. If you still need a coordinator afterwards, they start with a chart where every recurring job already has a name next to it.
The Kipwise agent costs $10 per user per month with a minimum of three users; see Kipwise pricing for the trial and plan details.
What to do next
Today, scroll back through the last two months of your ops channel and write down every request that began with "did anyone" or "I thought you". Put those jobs in the rows of the RACI chart template above, put one name in each A cell, and send it to the people on it for a yes before Friday.



