Most operational software has an approvals feature. Very few have an approvals system. The difference shows up about eighteen months into a rollout, when the same shape of request — a vendor renewal, a hiring requisition, a discount above a threshold — has accumulated four parallel routes, three exception paths, and one spreadsheet that quietly overrides all of them.
Why approvals break
Approvals fail in two directions. They become bottlenecks, where the right person is unreachable or the rule is too rigid. Or they become noise, where everyone is a required approver and nobody is actually accountable. Both outcomes feel like a tooling problem and are almost always a design problem.
An approval is a contract between a request, a policy, and a person. When any one of those three is unclear, the system degrades — slowly, and then all at once. — Internal note, cohort 01 implementation review
The three shapes
Almost every approval workflow we've seen across CRM, ERP, and procurement contexts reduces to one of three shapes. Knowing which shape you're designing for is the single most useful framing decision you can make.
- Linear. A single ordered chain. Best for low-volume, high-stakes decisions where each approver adds a distinct judgment.
- Parallel. Multiple approvers act independently. Best when domains are non-overlapping — finance, legal, and the requesting manager, for example.
- Conditional. The route is computed from the request's attributes. Best for volume, but the most expensive to maintain.
A practical default
Start linear. Move to parallel only when you can name the non-overlapping domains. Move to conditional only when you have a written policy that already describes the routing logic in prose.
Escalation as a first-class object
The most common reason approval systems silently rot is that escalation is treated as an afterthought — a timeout setting, a reminder email. In a well-designed system, escalation is its own object with its own owner, its own SLA, and its own audit trail. It is not a fallback; it is a path.
A useful test: can a new operator, on their first week, read the system and tell you what happens to a stalled approval at 24 hours, 72 hours, and 7 days? If the answer requires tribal knowledge, the escalation model is not yet a first-class object.
Audit trails that hold up
An audit trail is not a log. A log answers what happened; an audit trail answers why. The distinction matters when an auditor, a regulator, or a future version of yourself asks how a decision was made eighteen months ago.
The minimum useful audit record captures four things: the request as it stood at the moment of decision, the policy that was in force, the person who approved (or delegated), and the rationale — even if that rationale is a single sentence.
Measuring approval health
Three metrics, watched together, tell you almost everything about how an approval system is performing in production.
- Time-to-first-touch. How long a request waits before any approver looks at it.
- Escalation rate. The percentage of requests that hit an escalation path. A rising number is usually a routing problem, not a people problem.
- Override rate. The percentage of approvals that bypass the defined path. Anything above five percent suggests the path is wrong.
Where to start
If you are inheriting an approvals system that has drifted, resist the urge to redesign it end-to-end. Pick the single highest-volume request type, model it cleanly in one of the three shapes, instrument the three metrics above, and run it for one quarter. The rest of the work becomes obvious.
Approvals are unglamorous infrastructure. Done well, they disappear into the background of an operation — which is precisely the point.