Workflow metrics reveal improvement only when they distinguish value-creating work, waiting, rework, exceptions and outcome quality. A faster average can hide an ageing tail; more completed cases can hide poorer decisions.
Define each measure from process events and specify its owner, segment and gaming risk. Use a balanced set small enough to drive action.
Start with the decision
Ask what the process owner may change: staffing, priority, rule, automation, training or policy. Choose measures that distinguish those options. A metric nobody uses in a decision is reporting inventory.
Record the desired outcome and possible harm. For example, reducing approval time must not increase unauthorised decisions or later correction.
Define elapsed and touch time
Elapsed time runs from agreed start to end event. Touch time is active handling. Their difference reveals waiting, although system timestamps may need state rules to approximate effort.
Report median and a high percentile as well as average. Segment urgent, standard and exceptional cases rather than comparing unlike work.
Measure queues and ageing
| Metric | Definition example | Gaming risk |
|---|---|---|
| Work in progress | cases started but not terminal | closing and reopening to reduce count |
| Queue age | time since entering current waiting state | moving cases between queues |
| First ownership | receipt to accountable assignment | automatic assignment with no action |
| Blocked share | cases waiting on named dependency | failing to record blocked state |
| Oldest case | maximum age by priority/variant | excluding inconvenient categories |
Expose rework
Count returns to an earlier state, repeated data requests, reopened cases and corrections after completion. Define legitimate iteration separately from avoidable defect.
Trace the first cause: unclear input, wrong rule, missing authority, poor data or downstream rejection. A rework rate without cause becomes a blame measure.
Measure exception density
Track the share of cases leaving the designed path, exception type, resolution effort and owner. A low exception rate with high impact may still justify control; a high rate suggests the “exception” is actually normal work.
After automation, compare exception capture. An apparent improvement may come from cases failing silently outside the system.
Protect outcome quality
Choose a measure the recipient values: correct first-time decision, fulfilled request, accurate record, compliant approval, on-time delivery or resolved issue. Use sampling and control evidence where the outcome is not directly observable.
Balance speed with quality and risk. Set explicit guardrails that can stop or redesign an automation.
Work through one metric set
For an approval workflow, a balanced set might include median elapsed time, 90th-percentile age, touch time, share returned for missing information, decisions later corrected and cases without accountable owner. Segment standard and exceptional requests.
If elapsed time falls while corrections rise, the change is not an unqualified success. The paired measures reveal that speed shifted effort downstream.
Validate the event data
Check missing timestamps, impossible state order, duplicate cases, changed identifiers and clock or calendar assumptions. Compare a sample with source records. A precise chart based on inconsistent event definitions can drive the wrong intervention.
Document how cancellations, reopenings and merged cases affect numerator and denominator. Apply the rule consistently across periods.
Use thresholds for investigation, not punishment
A threshold should trigger review of the process and evidence. Individual performance comparisons can encourage premature closure, avoidance of difficult cases or hidden rework. Use role and complexity context before attributing cause.
Publish metric limitations beside results. This makes responsible use easier and builds trust when definitions evolve.
Check flow reliability
Measure completion without manual rescue, failed integrations, retry age, duplicate events and cases with inconsistent state. System uptime alone does not show whether the workflow produces dependable outcomes.
Reconcile input events, terminal outcomes and open cases for material processes. Investigate unexplained difference.
Use a metric definition card
- name and business question;
- numerator, denominator and time boundary;
- included and excluded variants;
- source events and data-quality checks;
- segments and review frequency;
- owner, action threshold and gaming risk;
- paired guardrail measure.
Version definition changes so trends do not compare different calculations without disclosure.
Read distributions and cohorts
Compare percentiles, age bands and process variants. Follow cases started in the same period when backlog makes completion counts misleading. Annotate policy, staffing and system changes.
Small samples need caution. Use the cases to learn rather than declaring a trend from normal variation.
Run the improvement loop
Baseline, select one constraint, make a bounded change, monitor intended and guardrail measures, and review qualitative evidence. Decide to retain, revise or roll back. Then allow enough time for the process to stabilise before the next change.
Real improvement reduces the constraint and preserves outcome quality. The dashboard is useful only when it makes that decision clearer.
Retain the definition card, baseline, change date and decision record. When a later team sees a trend, it can distinguish a genuine process shift from a changed calculation, seasonal mix or missing data. This continuity turns metrics into operational memory.
Remove measures that no longer influence action, and add a new one only with a named question. A smaller trusted set protects attention and reduces the temptation to interpret random movement as performance.