Why Do Approval Flows Keep Getting Longer? —— A Three-Step Method for Judging and Reducing Process Nodes
A company engaged in industrial product distribution had 7 approval nodes in its procurement payment process in 2023, which increased to 12 by 2026. Each addition was a response to an incident: one overpayment led to an additional financial review, one supplier collusion led to a procurement director's signature, and one invoice issue led to a tax position. Over three years, 5 nodes were added and none were removed. The end-to-end cycle extended from 8 days to 21 days, and the management's solution was to "submit plans in advance" — essentially shifting the time pressure to the front end while leaving the problem untouched.
First, let's draw a conclusion: The primary driver for the increasing length of approval flows is not the growing risk but the transfer of responsibility. Adding a node means someone shares the burden when an incident occurs; removing a node means no one benefits and the remaining person must bear the risk alone. Therefore, in any organization, the approval chain will only grow in one direction. To reduce nodes, relying on "optimization awareness" is ineffective; instead, a calculable criterion must be used: When was the last time this node changed the approval outcome?
1. The First Criterion: Result Change Rate
Definition: Result Change Rate = Number of cases returned, modified, or rejected at this node during the statistical period ÷ Total number of cases passing through this node. It is recommended to use a 12-month statistical period; less than 6 months is insufficient for a representative sample and can be easily skewed by a few large cases.
| Result Change Rate | What This Node Does | Disposition Recommendation |
|---|---|---|
| Over 10% | Real decision-making, real risk control | Retain, and set an SLA (e.g., 4 working hours) |
| 3%~10% | Substantive review value | Retain, consider merging with nodes at the same level |
| 1%~3% | Marginal review | Convert to notification or post-approval sampling |
| Below 1%, for 6 consecutive months | Just passing through | Delete |
| 0%, and no external basis | Signature ceremony | Delete, no discussion needed |
This table explains most of the reasons why approval flows get longer: in a company with 12 nodes, typically 4~5 nodes have a result change rate consistently below 1%. Their actual function is not to control risk but to provide evidence that the signatory is aware of the matter.
However, using only the ratio can lead to a fatal mistake. A group once cut a node for legal review of sales contracts based on this standard — the node had only 4 returns in a year, with a ratio of less than 0.5%, but each return involved responsibility clauses worth millions. Therefore, a second criterion must be added: the amount level of a single interception.
Rank nodes by the expected interception value: Result Change Rate × Average amount involved in a single interception. A node that intercepts 4 times a year with an average amount of 800,000 RMB has an expected interception value of 3.2 million RMB, far exceeding its management cost and must be retained. Another node that returns 60 cases a year with an average amount of 3,000 RMB has an expected interception value of 180,000 RMB, and its authority should be delegated to system rules rather than keeping a signature position.
The order of criteria is: First, look at the amount level; second, look at the change rate; and third, check for external basis. Only nodes that score low on all three can be deleted.
2. Why It Only Gets Longer: Four Mechanisms
Mechanism One: Accident Ratchet. Adding a node after an incident is the least costly and most easily accepted response in an organization; however, there is no one responsible for "this node should be reviewed periodically." The ratchet only turns in one direction.
Mechanism Two: Responsibility Transfer Masquerading as Risk Control. Signing off psychologically means "I know about it," but institutionally it is recorded as "I reviewed it." When the actual review action takes only 30 seconds, increasing the number of nodes only spreads responsibility, not reduces risk.
Mechanism Three: Multiplicative Effect of Co-signing. The cycle for co-signing by three departments is not the sum of their times but the "slowest one" plus "rework and resubmission." With a rework rate of 20%, the actual time for one co-signing is nearly 1.6 times that of the slowest department — this is why adding a co-signing department increases the cycle by 40% rather than just 10%.
Mechanism Four: Organizational Overlap. A newly established department automatically inherits the approval authority of related processes; however, when departments are merged or dissolved, the approval authority is not automatically withdrawn. After three years of organizational adjustments, several nodes remain in the process that "no one is responsible for, but the system is still waiting for their approval."
3. Three Steps to Reduce Nodes
Step One: Data Collection, Calculate Three Numbers
From the process logs of OA, BPM, and ERP, extract four columns: case number, node, arrival time, and departure time, plus the action (approve/return). Calculate three numbers:
- Number of nodes and median waiting time for each node
- Waiting Time Ratio = Total waiting time ÷ End-to-end cycle
- Result Change Rate (as defined in the previous section)
Passing line: The total effective processing time of approvers should be less than 5% of the process cycle. If a 9-day process involves less than 4 hours of signing actions, optimizing approval efficiency can save at most 4 hours — the real issue is the waiting time. This is why process mining must be done first; see How Far Off Are Process Diagrams from Real Processes? for data collection methods.
Step Two: Judgment, Five Disposition Methods Instead of a One-Size-Fits-All Approach
| Disposition | Applicable Scenario | Typical Example | Supporting Actions |
|---|---|---|---|
| Delete | Change rate below 1% and no external basis | Deputy department head's duplicate review, pure "acknowledgment" sign | System logs handle the traceability |
| Merge | Multiple people at the same level reviewing the same information | Three vice presidents signing the same form | One representative signs, others are copied |
| Convert to Notification | Need to be informed but not to make decisions | Finance's acknowledgment of procurement requests | Notification does not block the process |
| Tiered Authorization | Risk strongly correlated with amount | Reimbursement, procurement, discount approval | Authorization by amount, not by position |
| Retain and Label | Explicitly required by contracts, regulations, or audits | External contract signing | Label the basis separately to prevent misdeletion in the next round |
The key to this table is the last row. Any node that cannot be deleted must have its basis written into the process; otherwise, it will be considered redundant and deleted in the next round of simplification, only to be added back with interest during the next audit.
Step Three: Solidification, Three Supporting Measures Are Essential
① Authorization Matrix in the System, Not in Documents. If any tier of amount, category, or customer level is missing, the system defaults to the strictest path — reducing 5 levels in the document but still 12 levels in the system. The test is straightforward: disable the account of an authorized person at a certain tier and see if the process automatically skips or gets stuck.
② Post-Approval Sampling Instead of Pre-Approval Full Inspection. After deleting a node, the corresponding risk is mitigated by monthly sampling of 5%~10%; issues found in sampling must be traced back to individuals, otherwise, sampling will degenerate into mere form-filling.
③ Circuit Breaker Clause. Within 3 months of node revocation, if the corresponding error rate or overpayment rate exceeds 20% above the baseline, the node is automatically restored and the criteria are reviewed. This must be written into the policy — otherwise, an incident will trigger an emotional rollback, adding back all the deleted nodes.
4. Three Common Mistakes
Mistake One: One-Size-Fits-All "Maximum Three Levels of Approval." The hierarchy is reduced, but the only node with an amount threshold is cut, leaving two pure reviews. The number of nodes decreases, but the risk increases. Reducing nodes means eliminating "actions that do not change the outcome," not "hierarchy."
Mistake Two: Treating Electronic Signatures as Node Reduction. Moving approvals from paper to online reduces the processing time of a single node from 4 hours to 10 minutes, but the waiting time remains the same — still waiting for leaders to return from business trips to click the mouse. Such projects typically reduce the cycle by only 15%, but are often reported as "90% efficiency improvement."
Mistake Three: Reducing Nodes Without Sampling. Nodes are deleted, but sampling is not established. Three months later, an overpayment incident occurs, and all nodes are added back, plus two more. This is the second turn of the accident ratchet, and this time, no one dares to suggest simplification again.
5. What Numbers to Look at After the Changes
| Indicator | Typical Pre-Change Value | Post-Change Target | Success Criteria |
|---|---|---|---|
| Number of Approval Nodes | 9~12 | 4~6 | Reduce by more than 40% |
| End-to-End Cycle (Median) | 8~12 days | 2~4 days | Shorten by more than 50% |
| First-Pass Rate | 40%~60% | 80% and above | Improve by 20 percentage points |
| Error Rate / Overpayment Rate | Baseline | Within 10% of the baseline | No deterioration |
| Weekly Time Occupation of Approvers | 10%~15% | Less than 5% | Reduce by two-thirds |
If the error rate deteriorates by more than 20% in any of the five indicators, it indicates that the wrong nodes were deleted, and no matter how good the other numbers look, it cannot be considered a success.
6. Who Should Be Responsible for Reducing Nodes
Reducing nodes should not follow the process of "seeking opinions from all departments," as this effectively gives the veto power to those who are most resistant to change — each department will only demand more protection for itself. The correct approach is: the process owner responsible for the cycle proposes the plan, and finance and legal departments only provide veto opinions (with explanations). The general manager makes the final decision. Using one month for judgment and one month for piloting is much more effective than holding coordination meetings for three months.
In a Nutshell
Approval flows do not get reduced because no one is responsible for the cycle, not because of increased risks. First, calculate the result change rate and expected interception value for each node, then apply the five dispositions (delete, merge, convert to notification, tiered authorization, retain and label) separately. Finally, use sampling and circuit breaker clauses to manage risks — if the order is reversed, the deleted nodes will grow back within half a year.
Knowledge code: 16.1.2 Author: QTank
This article belongs to the "Digitalization and AI Zone · Process Digitalization" direction. The accompanying node value judgment table and authorization matrix template are being organized and can be viewed in the resource library.