Why approval chains break as you grow, and how to design ones that don't

In a young company, approvals are easy. Someone needs a leave day, an expense reimbursed or a new hire, and they ask the founder. The founder knows everyone, sees everything and decides in a minute. Nobody writes down a policy because nobody needs one.

That arrangement quietly stops working somewhere between twenty and fifty people. Requests pile up in one inbox, decisions slow down, and the people who actually know whether a timesheet is right or a claim is reasonable are not the ones deciding. This article looks at why approval chains break as you grow and how to design ones that keep working at a hundred people and beyond.

Why "send it to the founder" stops working

The founder-as-approver model fails for three reasons, and they all arrive at once.

• Volume. Leave requests, timesheets, expense claims, comp-off, hiring requests and resignations grow roughly in line with headcount. At fifty people, a single approver can easily face dozens of requests a week, most of them routine.
• Knowledge. The founder no longer knows whether an engineer really worked on a Saturday or whether a client visit justified a taxi fare. The reporting manager does. Approval by someone without the facts is a rubber stamp.
• Bottlenecks. When one person travels, falls ill or is simply busy closing a deal, everything waits. Employees learn that approvals are slow and start working around the process.

The fix is not to remove approvals but to spread them across the people best placed to judge each part of a request, in a clear and predictable order.

Designing the order of approvers by role

A good approval chain answers one question at each step: what does this person know that the previous one did not? The roles most companies draw on are:

• Reporting Manager: knows whether the work was done, whether the time off can be covered and whether the expense was for a real business purpose.
• HR: checks policy, eligibility and records.
• HR Director: handles exceptions and decisions with people consequences.
• Finance: confirms amounts, tax treatment, budgets and payment.
• CFO: signs off spend above a threshold or outside budget.
• CEO: reserved for decisions that genuinely need the top, such as new headcount outside the plan.

Define chains in terms of these roles rather than named individuals. "Reporting Manager, then Finance" keeps working when a manager changes, when a new team forms or when your finance lead goes on leave and someone else covers. A chain built from names needs editing every time the organisation chart moves.

Keep chains as short as they can be while still putting the right knowledge in front of each request. Every extra step adds delay and dilutes responsibility. If a step never changes a decision, remove it.

A sample approval matrix

The table below is an example to adapt, not a recommendation for every company. Your own matrix will depend on your size, your risk appetite and how your teams are organised.

Each request keeps the chain it started with

Policies change. You might add Finance to timesheets, or move expense approval from HR to the CFO once spend grows. The question is what happens to requests already in progress when that change is made.

The safe answer is that they keep the chain they started with. When a request is raised, copy the chain as it stands at that moment onto the request itself. Later changes apply to new requests only. Without this, a claim that was one step from payment can suddenly need two more approvals, or a request can land with someone who has never seen it and has no context. Employees experience this as the rules changing under their feet, and auditors see a trail that no longer matches the policy in force at the time.

Skipping a step when the only approver is the requester

Role-based chains create an awkward edge case. The HR Director files an expense claim, and the chain says HR Director. Or the only person in Finance submits their own timesheet with Finance as a step. Nobody should approve their own request, and the request should not sit forever waiting for someone who does not exist.

The clean rule: if nobody other than the requester could take a step, that step is skipped and the request moves to the next one. It is recorded as skipped, not approved, so the trail stays honest. Where a step can be taken by several people in a role, the others take it and the requester is simply excluded.

It is worth checking your chains for cases where skipping leaves no meaningful approval at all, for example a CEO's expense claim. Decide explicitly who reviews those, rather than letting the system decide by accident.

Rejections, visibility and approval SLAs

A rejection needs a reason

A rejected request with no explanation creates a second conversation by chat or email, and often a resubmission with the same problem. Make a comment mandatory on every rejection. It forces the approver to be specific, gives the employee something to fix, and leaves a record of why the decision was made.

One list of everything waiting

Approvers who have to check five different screens for leave, timesheets, expenses, comp-off and resignations will miss things. Give every approver a single list of every request waiting for them, across every type, with a link to where each one is decided. Include what they decided recently, so they can answer "did I approve that?" without searching.

Target times for each step

Set an expected turnaround for each kind of request, for example two working days for a timesheet or five for an expense claim. Publish it so employees know what to expect. Review requests that exceed it regularly, and look for patterns: a single approver who is always late, or a step that consistently adds days without changing outcomes.

The audit trail

Every approval system should be able to answer, for any request: who raised it and when, which chain it followed, who decided each step and when, what they said, and which steps were skipped and why. That trail matters for internal disputes, for statutory audits of expenses and payroll, and for reviewing your own process.

Keep the trail on the request itself rather than in email threads. Email is easy to lose, hard to search and rarely complete. A trail that sits with the record is there when someone needs it, years later if necessary.

A short checklist when reviewing your approval design:

1. Is every chain defined by role rather than by name?
2. Does each step add knowledge the previous step lacked?
3. Do in-flight requests keep the chain they started with?
4. What happens when the requester is the only possible approver?
5. Does every rejection carry a reason?
6. Can every approver see everything waiting for them in one place?
7. Is there a target time, and does anyone look at breaches?
8. Can you reconstruct any decision from the record alone?

Putting it into practice

Good approval design is mostly about clear rules applied consistently: the right roles in the right order, chains that do not shift under in-flight requests, no self-approval, reasons for every rejection and a single place to see what is waiting. Once these are in place, the founder can step out of routine decisions without losing control.

In Techno Team Via, the admin sets the approval hierarchy for each module, including expense claims, timesheets, comp-off and resignations, choosing from Reporting Manager, HR, HR Director, Finance, CFO and CEO. Each request copies its chain when it is made, so later changes never move it; a step nobody but the requester could take is skipped; and My Approvals lists every approval waiting and decided in one place. To see it configured for your organisation, book a demo of Techno Team Via.