Approval workflow metrics: measure cycle time, rework, and SLA risk

Approval workflow metrics should show four things together: how long decisions take, where requests wait, how often work returns for correction, and whether the workflow follows its service and control rules. A useful scorecard combines cycle time, stage dwell time, queue age, SLA compliance, first-pass completion, throughput, and exception rates.

Do not start with a dashboard. Start with a measurement specification that defines each clock, event, cohort, denominator, and segment. Otherwise, two teams can report the same metric name and measure different things.

Source review: August 12, 2026. The examples use illustrative data, not Formaloo customer results or universal benchmarks.

Write the measurement specification before the dashboard

A metric becomes trustworthy when another analyst can reproduce it from the same records. Give every measure a short contract with six parts:

1. Unit: State whether one row represents a request, approval stage, decision, event, or approver assignment.
2. Start and end events: Name the exact timestamps. For example, start at “valid request submitted” and end at “final decision recorded.”
3. Time basis: Choose elapsed hours, business hours, or business days. Record the timezone and holiday calendar.
4. Cohort: Decide whether the report groups requests by submission date, completion date, or current open state.
5. Denominator: Define which requests qualify. Exclude test records and cancellations only through a documented rule.
6. Segments: Preserve request type, risk band, value band, department, route version, and outcome so teams compare like with like.

APQC defines cycle time as the total time from the beginning of a process to the end, including active work and waiting. That definition works for an end-to-end view. It does not tell you which stage created the delay, so the scorecard also needs stage and queue measures.

Use three clocks to separate delay from active work

One average approval time hides too much. Track three clocks that answer different questions.

• End-to-end cycle time: Time from a valid submission to the final outcome. Use it to measure the experience of the requester and the reliability of the whole workflow.
• Stage dwell time: Time from entry into one review stage to exit from that stage. Use it to compare finance, legal, security, manager, or executive stages without losing the route context.
• Queue age: Current time minus the ready or assigned time for an open item. Use it to find requests that need attention before they breach an SLA.

Stage dwell time still includes waiting, clarification, absence, and active review. Do not rename it “approver work time” unless the workflow captures a separate work-start and work-stop event. The distinction matters because the fix for missing evidence differs from the fix for insufficient review capacity.

Seven approval workflow metrics form a useful core scorecard

1. Median and tail cycle time show typical service and risk

Calculate cycle time for every completed request, then report the median and a tail percentile such as P90. The median describes a typical request. P90 shows the duration that 90% of completed requests met or beat.

Report the mean only as a supporting value. A few very old requests can pull the mean upward and hide the experience of most requesters. Segment cycle time by request type, complexity, risk, and route version before drawing a conclusion.

2. Stage dwell time locates the constraint

For each stage, subtract its entry time from its exit time. Compare the median, P90, and share of total cycle time across stages. A stage that consumes most of the end-to-end time deserves investigation, but the metric alone does not identify the cause.

Pair dwell time with queue depth, return reasons, missing evidence, reassignment, and request complexity. IBM's current Kanban metrics guidance uses time in each workflow state, aging work in progress, throughput, and processing time per state to reveal delays and rework.

3. SLA compliance measures reliability

SLA compliance = eligible requests completed within the SLA ÷ all eligible completed requests × 100.

Track end-to-end and stage-level SLAs separately. Also count open requests at risk before they breach. Microsoft's current Power Automate monitoring guidance separates queued work, processed work, SLA violations, and items at risk. That distinction helps operations teams intervene before a late request turns into a historical statistic.

Do not mix paused time, incomplete requests, or approved exceptions into the calculation without an explicit policy. Publish both the rule and the rate.

4. First-pass completion and rework reveal input quality

First-pass completion = completed requests with no return to an earlier stage ÷ all completed requests × 100.

Rework rate = completed requests that returned to an earlier stage at least once ÷ all completed requests × 100.

Add rework events or revision rounds when one request can loop several times. Microsoft defines rework as repeated activities and separates self-loops from wider loops in its process-mining guidance. For approvals, a return from legal review to the requester and back to legal forms a useful rework loop.

Always pair the rate with a reason code. Missing attachments point to intake design. Conflicting comments point to review criteria. A material evidence change may represent necessary control, not waste.

5. Throughput and work in progress expose accumulating queues

Throughput = requests completed during a period. Work in progress = open requests at a point in time.

Compare arrivals with completions. When intake exceeds throughput for several periods, the open queue grows even if the median cycle time for recently completed items still looks stable. That lag makes work in progress and queue age valuable early warnings.

Break work in progress into age bands such as within target, approaching target, breached, and materially overdue. Use the organization's actual SLA windows instead of borrowed thresholds.

6. Routing exceptions show policy and configuration gaps

Track no-match routes, manual reassignments, delegations, escalations, overrides, skipped stages, self-approval conflicts, and changed approvers. Divide each count by the requests eligible for that event, then segment by route version.

A rising no-match rate often signals missing data or incomplete routing rules. A high override rate may indicate that the approval matrix no longer matches operational reality. Neither result proves misconduct.

7. Measurement completeness protects every other metric

Count requests with missing start times, end times, stage events, outcome codes, route versions, or stable IDs. A polished chart cannot repair incomplete event data.

Report the share of eligible requests that each metric covers. If only 63% of requests have usable stage timestamps, show that limitation next to the dwell-time result instead of presenting a precise-looking number as complete.

An illustrative cohort shows how the metrics work together

Consider 100 completed software-purchase requests. The numbers below illustrate a diagnostic method, not a target.

• The median end-to-end cycle time is 2.1 business days, while P90 reaches 8.4 days.
• Eighteen requests breach their end-to-end SLA, so SLA compliance equals 82%.
• Twenty-three requests return to an earlier stage, which produces a 23% request-level rework rate and 77% first-pass completion.
• Fifteen of those 23 returns cite missing security or contract evidence.
• The legal stage owns the longest P90 dwell time, but the longest cases also contain the most missing-evidence returns.
• Weekly intake averages 24 requests while throughput averages 20. Work in progress grows by about four requests per week.

The data does not support “legal reviews too slowly.” It supports two testable hypotheses. First, incomplete intake creates avoidable rework before legal can make a decision. Second, demand exceeds total completion capacity. Improve required evidence and routing validation first, then measure the same cohort definitions again. If queue age remains high after rework falls, investigate capacity, delegation, and route design.

Build a dashboard around decisions, not decoration

A practical approval dashboard needs five views.

1. Outcome strip: Completed volume, median cycle time, P90 cycle time, SLA compliance, and first-pass completion for the selected cohort.
2. Open-work aging: Current requests by stage and age band, with SLA-at-risk and breached items visible.
3. Stage view: Dwell-time distribution, work in progress, throughput, and return rate for each stage.
4. Exception view: No-match routes, reassignments, delegations, escalations, overrides, and skipped reviews by rule version.
5. Segment controls: Request type, risk, value, department, region, route version, and outcome.

Show distributions and counts alongside rates. A 50% breach rate from two requests needs different treatment from a 12% breach rate across 2,000 requests. Keep the affected records available for authorized investigation.

Do not turn the scorecard into an approver leaderboard

Raw person-level averages create bad incentives. Approvers may inherit different risk, complexity, volume, evidence quality, or working calendars. A security reviewer who stops an unsafe request should not look worse than a manager who clears routine purchases.

Use person or team views to balance queues, arrange delegation, and investigate process conditions. Apply these guardrails:

• Compare similar request types and risk bands.
• Separate waiting for evidence from waiting for a decision.
• Show volume and distribution, not one average.
• Review route design before assigning blame.
• Pair speed with rework, exceptions, and control outcomes.
• Protect access to person-level performance data.

Instrument the workflow with a minimum event model

Each request needs a stable ID. Each lifecycle event should record the request ID, workflow and rule version, request type, stage, event name, timestamp, actor or service identity, current owner, outcome, reason code, due time, and evidence version when relevant.

At minimum, capture valid submission, assignment, stage entry, review opened when available, decision, return for correction, resubmission, reassignment, escalation, override, cancellation, and final closure. Preserve the event sequence needed for the approval audit trail.

Do not silently overwrite the event that a report needs. A current status explains where the request sits now. Historical events explain how it arrived there.

Formaloo can connect the request, workflow, and operating views

Start with a request form that captures the fields used for routing and segmentation. Formaloo's current approval workflow guide uses request type, budget, supporting files, an internal status, and an Assignee field. Keep internal fields admin-only on the public form.

Use On submit for the initial route. Use On update when a status or other internal field change should trigger the next action. Define milestone and reason fields that match the measurement specification instead of trying to infer every event later.

Operations teams can create Table and Kanban data blocks for current work, then apply saved filters for stages, departments, outcomes, or age-related fields. Formaloo documents sorting and filtering for Table, Kanban, and Gallery data blocks. Its current chart guide covers charts based on supported form fields and response trends.

Use a separate analytics environment when the scorecard requires median and P90 duration, business-calendar calculations, cross-system events, or process-mining root-cause analysis. Confirm Assignee, status, integration, access, and reporting requirements for the enterprise deployment before finalizing the data model.

Use a 30-day loop to improve one constraint at a time

1. Week one: Freeze metric definitions, add missing events and reason codes, and test timestamp completeness.
2. Week two: Build the baseline by request type, risk band, and route version. Do not set a universal target from mixed work.
3. Week three: Choose one evidence-backed constraint, such as incomplete intake, a threshold gap, a growing queue, or missing delegation. Change one primary mechanism.
4. Week four: Compare the same cohort definitions. Check cycle time, tail risk, rework, SLA compliance, open aging, exceptions, and control outcomes together.

Keep the change only when the full scorecard improves without weakening control quality. Record the change date and route version so later analysis can separate the experiment from normal variation.

Book a demo to design and deploy a measurable enterprise approval workflow in Formaloo.

Sources

• APQC: Cycle time in days to approve a capital project
• Microsoft Learn: Rework metrics
• Microsoft Learn: Metrics and recommendations for Power Automate
• IBM Docs: Kanban metrics and reports
• Formaloo Help Center: How to build an approval workflow
• Formaloo Help Center: How to sort and filter submissions data
• Formaloo Help Center: How to add charts to projects