How to map roles and responsibilities in a process
How to map roles and responsibilities across a process: one accountable owner per step, lanes for the roles that act, and a RACI only where the diagram cannot carry the answer.
Mapping roles and responsibilities means giving every step exactly one accountable owner, placing it in that owner's lane, and recording who else must be consulted or informed.
The short version
- Exactly one accountable role per step. Two is the same as none.
- The lane is the assignment: responsibility is position, not a separate document.
- Consulted and informed are different relationships; record them on the step.
- The test for ownership is who gets chased when it is late.
- A RACI matrix that lives in another file will disagree with the process within a year.
Why "who owns this?" is so often unanswerable
Ask who owns a step and you get one of three answers: a confident name, a department, or a pause. The pause is the useful one. It almost always means two teams each believe the other is accountable, and that belief has been surviving because nothing has forced the question: the step has been getting done by whoever noticed, or not at all, in a way that only shows up as a delay somewhere downstream.
The discipline that fixes it is single accountability: exactly one role answerable for each step, even when several people do the work. Everyone else is consulted or informed, which is a genuinely different relationship and should be recorded as one. Two accountable owners is the same as none, because when it is missed neither of them was wrong.
A swimlane diagram carries most of this natively: the lane is the accountable role, so responsibility is a property of position rather than of a separate table. The example below is a vendor onboarding process across five functions. Open the spreadsheet panel: the Vertical lane column is the responsibility assignment, which means it stays correct when the process changes, unlike a RACI matrix maintained in a different file.
Responsibility, read off the lanes
Vendor onboarding across five functions. The Vertical lane column beneath the canvas is the responsibility assignment.
Requester versus process owner
The requester raises the need; procurement owns the check for an existing vendor and the due-diligence pack. Whoever asks for something is rarely accountable for the process that follows, and conflating the two is the most common mapping error.
Four reviews, four owners
Legal on contract terms, finance on credit, security on data protection, then a risk tier. Each review sits in one lane. A single "due diligence" step owned by procurement would hide three accountabilities that genuinely belong elsewhere.
Who decides, not who prepares
Procurement holds the due-diligence gate; legal holds the contract. The role that prepares the evidence is not automatically the role that decides on it, and putting the decision in the preparer's lane quietly documents a control weakness.
Separation of duties, drawn
Bank verification and vendor master data both sit with finance, with a callback loop between them, and the person who verifies must not be the person who edits the record. Where the diagram cannot show that constraint, write it on the step.
How it works
Map the process first
Get the steps and decisions down before arguing about ownership. Responsibility discussions held without a shared picture of the work run on generalities, and generalities are exactly where two teams can both feel they are covering something.
Assign one accountable role per step
Use the lane. The test is simple: who gets chased when the step is late? Not who cares about it, not who reports on it. If two names come up, keep asking until one of them is the answer, because that ambiguity is the finding.
Separate deciding from preparing
Check every decision. The role that assembles the evidence is often not the role that should make the call, and where the chart shows them as the same lane you have documented a control weakness rather than a process.
Record consulted and informed on the step
Put the other parties in the step's comment: who must be asked before it proceeds, and who needs to know afterwards. Keeping them on the step rather than in a matrix is what stops the two from drifting apart.
Look for the patterns that indicate trouble
A lane with one box probably is not a lane. A role appearing in every step is either a bottleneck or a manager who should not be in the flow. And a step whose lane nobody will claim is the real output of the exercise.
Get each role to confirm their own lane
Send the chart to each lane owner and ask them to confirm or correct only their own steps. Confirmations at that level are meaningful; a group nod to a whole diagram is not, and it is the mechanism by which unassigned steps survive a review.
Mistakes to avoid
Two accountable owners
Shared accountability is the polite version of none. Several people can do the work; exactly one should be answerable for it.
Departments as owners
"Finance" cannot be chased. A role can. Departments as lanes hide the handoffs happening inside them.
A RACI in a separate file
Matrices maintained apart from the process diagram diverge from it, usually within a couple of process changes, and then both are consulted and they disagree.
Naming individuals
Charts naming people are wrong at the next reorganisation and awkward to review. Name the role and keep the roster somewhere else.
Map your own roles and responsibilities
Open the vendor onboarding example as your own chart, rename the lanes to your roles, and reassign the steps.
Related guides
Frequently asked questions
What is the difference between responsible and accountable?
Responsible is who does the work; accountable is who answers for it being done. They are often the same person and do not have to be: a service desk agent may be responsible for closing a ticket while the service owner is accountable for closure quality overall. The rule that matters is that accountability is singular. Multiple responsible parties is normal; multiple accountable ones means nobody is, because when the step is missed neither was wrong.
Do I need a RACI matrix if I have a swimlane diagram?
Usually not. The lane already carries accountability, and the sequence already shows who acts when, which is most of what a RACI communicates, in a form people will actually look at. Add the consulted and informed parties to each step's notes and the matrix becomes redundant. Where a separate RACI genuinely helps is a process spanning many teams where governance requires a signed-off table; even then, generate it from the process rather than maintaining it alongside.
How do I handle a step where nobody will claim ownership?
Leave it unassigned on the chart and escalate it as an open question. The temptation is to allocate it to the most plausible team so the diagram looks finished, but an unowned step that has been quietly working is a risk somebody should decide about, and burying it in a lane removes the only evidence you had. Unassigned steps are among the most valuable findings a mapping exercise produces.
Should managers appear as a lane?
Only where they perform steps: an approval, a decision, an escalation. A manager lane that appears at every step usually indicates either a genuine bottleneck or a mapping habit of adding oversight to everything. Both are worth surfacing, and the diagram makes either obvious the moment the lane is drawn.