An approval may take ten minutes of judgment and three days of waiting. Adding reminders can shorten some delays, but it does not explain why the request waited: the approver lacked information, was unavailable, had no clear authority, or received more work than the role could handle.
Approval design should begin with decision latency. The goal is to place a complete, relevant question in front of an authorized person early enough for the answer to matter. The number of clicks in the workflow is a secondary concern.
For operations leaders, the central choice is how to allocate decision rights and attention. Which requests need review, which reviewers can work independently, which decisions can be delegated, and what happens when a deadline approaches? A dependable design preserves necessary judgment while removing waiting that serves no useful purpose.
A box labeled “manager approval” is insufficient. State what the manager is deciding and which evidence could change the answer. Is the question commercial acceptability, resource availability, technical suitability, or permission to depart from a policy?
Separate different decisions rather than sending every reviewer the same undifferentiated request. A technical specialist should not be asked to approve a commercial concession merely because both issues appear on one form.
Identify whether the reviewer has genuine discretion. If the rule is clear, the evidence is reliable, and the action is within an authorized boundary, a manual approval may add little. The relevant policy owner must decide whether the control can become validation, delegated authority, or a later check.
Do not remove review solely because most requests are approved. A high approval rate can indicate that the control works upstream or that the reviewer provides useful advice before formal submission. Investigate the function before changing it.
Track when a request becomes ready for decision, when it enters a reviewer’s queue, when review begins, when clarification is requested, and when the decision is recorded. Not every system can capture each point automatically, so sample observation may be necessary.
Distinguish time waiting for information from time waiting for an available decision maker. A workflow that pauses the clock whenever clarification is requested can make approval performance look good while the business still experiences delay.
Keep both the overall elapsed time and the component times. The overall measure represents the business experience; the components reveal where an intervention might help.
Examine age and distribution, not only the average. A small group of old requests can carry urgent consequences while most approvals are quick. Segment by decision type, completeness, complexity, and reviewer role before drawing conclusions about performance.
Little’s Law relates the long-run average number of items in a stable system to throughput rate and average time in the system. It is useful for checking whether observed backlog and elapsed time are consistent, provided the population, boundaries, and observation conditions match. It does not promise the completion time of a particular request. John D. C. Little, A Proof for the Queuing Formula.
For a hypothetical illustration, suppose a consistently defined approval process completes 12 requests per working day and has an average of 18 open requests over a representative stable period. The implied average elapsed time is 1.5 working days. This includes all time within the defined boundary, not just time actively reviewing.
If demand exceeds decision capacity for a sustained period, the backlog will grow. More urgent labels cannot create capacity. Leaders must reduce unnecessary arrivals, improve request quality, change delegation, add qualified coverage, or alter the service expectation.
Do not use a simple average calculation as a staffing model for a volatile queue. Arrival bursts, review-time variation, priorities, and absences matter. Use deeper analysis when the consequences justify it.
Sequential approval is appropriate when one decision genuinely depends on another. It is wasteful when independent reviewers wait for each other merely because the workflow was configured that way.
Identify the dependency explicitly. A commercial reviewer may need the technical option before deciding cost, while a scheduling reviewer can assess timing in parallel. Launch independent reviews together, then join the results at the point where combined judgment is necessary.
Define what happens if one reviewer requests a change. A revised request may invalidate another review, or it may affect only one part. Version the relevant evidence so the final decision does not combine approvals of different proposals.
BPMN provides constructs for describing activities, events, and gateways, including parallel flow. The notation can express the routing choice; it cannot establish that two business judgments are truly independent. That requires the owners’ agreement. OMG, BPMN 2.0.2.
Consider a hypothetical company managing office fitout projects. A client requests a layout change during installation. The project coordinator sends the request to a design lead, then a commercial manager, then a scheduling manager, and finally the project sponsor.
Case review shows that the scheduling manager could assess access and sequencing immediately, but waits for the first two approvals. The sponsor routinely returns requests because the final package does not make the combined cost and completion-date effect clear. Several requests sit with a design lead who is away from the project for part of the week.
The redesign separates the decisions. Design assesses feasibility and identifies the option under review. Scheduling evaluates the relevant timing implications in parallel where it has enough information. Commercial review uses the defined option and cost evidence. The sponsor receives a concise decision package that distinguishes confirmed consequences from assumptions.
A deputy design lead has explicitly delegated authority for a defined set of changes and access to the necessary records. Matters outside that boundary go to the original authority or a named escalation route. The workflow does not assume that another available employee can make the decision safely.
The request also carries a “decision needed by” date tied to the installation sequence. If that point approaches without a decision, the project owner chooses among delaying the affected work, proceeding with the existing approved design, or seeking an authorized alternative. Silence is not treated as approval.
The pilot tests a minor change, an option revised after initial review, a missing cost assumption, and the absence of the primary reviewer. It measures total decision time, repeated clarification, invalidated approvals, and work delayed while waiting. The hypothetical example does not claim that parallel routing eliminates all delay; dependent judgments still take time.
Delegation needs a scope, duration, authority limit, and evidence requirement. The deputy must know which decisions they may make and when to refer a case.
Test access and capability in advance. A deputy who cannot see the relevant records or interpret the proposal cannot provide meaningful coverage. Include the role in training and scenario reviews rather than treating delegation as an emergency administrative setting.
Make active delegation visible to requesters and other reviewers. Prevent conflicting decisions by two people who both believe they own the case. Record who made the decision and under which authority.
Review delegation when roles or policies change. An old temporary delegation can become an unintended permanent permission if nobody owns its expiry.
Escalation should clarify the issue, consequence of delay, options, and authority required. Repeatedly forwarding the original request to more senior people often increases noise without improving the decision.
Set escalation triggers around business need and queue age. A time-sensitive operational decision may need an earlier intervention than an ordinary planning request. Protect the normal queue from unnecessary priority inflation.
Give the escalation recipient a defined responsibility. They may reassign the decision, resolve a conflict, approve an exception within authority, or change the plan. If they cannot do any of those things, the escalation path is cosmetic.
Avoid default approval through timeout unless the relevant business and control owners have explicitly designed and authorized that behavior for the specific case. In many consequential decisions, a safe default is to pause or retain the last approved state.
A decision package should state the requested decision, options, relevant evidence, material consequences, deadline, and unresolved assumptions. Keep it proportional to the case.
Use conditional fields so routine requests remain simple while unusual cases supply the additional evidence they need. A long universal form can create incomplete or invented answers and discourage timely submission.
Provide feedback at the point of entry where practical. If a missing contract reference always causes rejection, validate it before the request reaches the approver. If the requirement is genuinely uncertain, offer a clarification route rather than forcing the requester to guess.
Track repeated return reasons. A high volume of clarification on one field may reveal poor instructions, an impossible information requirement, or a disagreement about policy. Fix the source rather than blaming each requester separately.
Approval queues accumulate notifications easily. Send alerts when they support a decision, and provide a useful consolidated view of outstanding work. The reviewer should be able to distinguish new, aging, blocked, and deadline-sensitive requests.
Allow a deliberate review cadence where the business can tolerate it. Batching can be efficient for low-urgency decisions, but the resulting wait should be understood and communicated. Do not accidentally batch urgent work behind a weekly meeting.
Monitor overrides and reassignment patterns. They can reveal that the nominal approval structure differs from the one the business actually uses. Review whether the formal design should change rather than allowing an unofficial parallel process to persist.
Buyers should ask workflow suppliers to demonstrate absence cover, revised evidence, parallel-review invalidation, and an approaching decision deadline. A successful happy-path approval says little about the queue mechanics that determine real latency.
The best approval workflow gives a qualified person a clear question at the right moment, with workable authority and a credible response when conditions change. Technology can make that design dependable. It cannot substitute for the organizational decision about who is allowed and equipped to decide.
