Who owns each step? Assigning responsibilities and permissions
You've documented the process on a single page. The next question is simple, and in small and mid-size companies it stalls more work than any software gap: who owns each step? A written process without assigned roles stays a nice document, and execution remains hostage to whoever remembers or whoever happens to be free.
Three things people constantly confuse
Before assigning anything, separate three words that get used interchangeably but are not the same thing:
| Concept | The question it answers | Example |
|---|---|---|
| Execution | Who does the actual work? | Procurement prepares the purchase order |
| Approval | Who says yes or no? | The department manager approves within a set limit |
| Permission | What is this role allowed to see or change? | Can view prices but not edit them |
Confusing them produces the familiar situation: an employee is accountable for an outcome but lacks the permission to deliver it, so they ask a colleague to do it for them, and ownership dissolves between the two. When it runs late, there is nobody to ask.
A worked example: a purchase order
Take a simple purchasing process and map it onto roles. The rule while mapping: exactly one executor and one approver per step. Multiple executors means, in practice, that nobody executes.
| Step | Executes | Approves | Is informed |
|---|---|---|---|
| Purchase request | Department employee | Department manager | Procurement |
| Collecting quotes | Procurement | None | Department manager |
| Awarding the supplier | Procurement | Finance manager above the set limit | Management |
| Receiving the goods | Warehouse keeper | None | Procurement |
| Approving the invoice for payment | Accountant | Finance manager | Department manager |
The roles above are illustrative. In a five-person company one person may hold two of them, and that is fine as long as it doesn't break the next rule.
The segregation of duties rule
The oldest and simplest rule in operational control: never put two opposing powers in the same pair of hands.
- Whoever requests a purchase does not approve it
- Whoever approves a payment does not execute it
- Whoever receives goods does not count the stock alone
- Whoever books an entry does not review it
This isn't about suspecting your staff. The point is that every amount passes under two sets of eyes, so an arithmetic error is caught before money leaves — and the employee's own record is protected if a later review asks about a transaction that passed through their hands alone.
Segregation of duties protects the honest employee before it constrains the dishonest one.
Attach permissions to roles, not to people
The most common mistake is building permissions around names: this person sees the sales report, that person edits prices. A year later the first has moved to another department, kept the old permissions, and had the new department's permissions stacked on top. That silent accumulation is what quietly ruins access control in growing companies, and it only surfaces when something goes wrong.
The alternative is three steps: define the roles first — there are usually few (department manager, accountant, warehouse keeper, procurement, employee) — then attach permissions to the role, then place people into roles. Moving an employee between departments becomes one role change instead of an audit of twenty scattered settings.
What happens when someone is away
What breaks approval chains isn't disagreement — it's leave and travel. For every approver, write down three things: a named backup defined by role rather than by person, the limit that backup is allowed to approve, and how long to wait before escalating to the level above. Without those three, one person's absence becomes a full stop for an entire process, the team routes around it through calls and messages, and the approval chain you built quietly stops existing.
Quick checklist
- Every step has one executor, written as a role and not a name
- Every approval has a clear limit, above which it escalates automatically
- No single role both requests and approves
- Every approver has a defined backup and an escalation window
- Permissions are attached to roles and reviewed on every transfer or promotion
- Every step leaves a written trace: who did what, and when
Finish this step and you've prepared the single most useful input for any management system: an agreed table of roles and permissions — instead of one improvised during setup and corrected later, after everyone has already gotten used to the wrong version.