Ask a shared services director how the operation is performing and you will usually be shown cost per transaction. It is the metric the industry standardised on, it benchmarks neatly against peers, and it is the number that appears in outsourcing business cases. It is also nearly useless as an early warning signal. Cost per transaction tells you what happened after everything has already gone wrong or right. It falls when volumes rise and stays flat while quality collapses. By the time it moves in the wrong direction, the problem it reflects is six months old and is being discussed in a steering committee rather than fixed on the floor. The metrics that predict problems are different, less flattering, and largely absent from management packs.
Why the Standard Dashboard Fails
The typical back office scorecard reports volume processed, cost per transaction, service level attainment against an agreed target, and headcount. Each is a lagging measure of activity, and together they can describe an operation that is quietly deteriorating as one that is performing well. A team can hit its service level by processing the easy items first and letting difficult ones age. It can reduce cost per transaction by pushing exceptions back to the requester, moving the work upstream rather than removing it. It can report high volume while its rework rate climbs, because reprocessed items are counted twice as throughput. None of that is dishonest. It is what happens when you measure output rather than condition.
The Metrics That Actually Warn You
First-pass yield. The proportion of items that complete the process correctly without touching a human exception queue, being returned, or requiring correction. This is the single most informative back office metric and the least commonly reported. A falling first-pass yield precedes every cost and service problem that follows it, usually by a quarter or more. Rework rate. How often work is redone. Rework is pure waste, it is invisible in throughput figures, and it demoralises teams. Measuring it usually reveals that a small number of process steps or upstream sources generate most of the rework — which makes it actionable. Aging distribution, not average age. An average masks the shape of the problem. Ten items at five days and one item at ninety days averages well and contains the item that becomes a complaint, a write-off or an audit finding. Report the distribution and the tail. Exception reasons, categorised. Not how many exceptions, but why. Missing purchase order, price mismatch, unapproved vendor, incorrect bank detail. The category tells you where the upstream defect is; the count tells you only that there is one. Queue age at the start of the day. A simple, brutal measure of whether the operation is keeping up. Rising start-of-day backlog is the earliest visible sign of capacity or quality trouble. Upstream defect source. Which department, system or supplier generates the items that fail. Back office teams absorb upstream sloppiness invisibly; attributing it is what gets it fixed. Cycle time by percentile. Median and ninetieth percentile, not mean. The customer experience of a process is defined by the tail, and the tail is where the risk sits. Straight-through processing rate for automated paths. Where automation exists, the percentage of items it completes without human intervention is the honest measure of whether the automation is working or has become an expensive pre-sorter.
| Signal | Question for the daily review |
|---|---|
| First-pass yield | Which work needed an exception or correction? |
| Rework rate | Which steps or sources create repeated work? |
| Aging distribution | Which unresolved cases sit in the oldest tail? |
| Exception reasons | What defect prevented completion? |
| Start-of-day queue age | Is the unresolved backlog aging? |
| Upstream source | Where did failing items originate? |
| Cycle-time percentiles | Which cases take longer than typical? |
| Straight-through rate | What completed without human intervention? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What Good Measurement Changes
The practical difference is what happens in the daily meeting. An operation reporting volume and cost discusses whether it hit target. An operation reporting first-pass yield, exception categories and aging tails discusses which upstream source caused this week's defect spike and who is going to talk to them. The first conversation manages the number. The second fixes the cause. This matters disproportionately in outsourced arrangements. A provider measured on cost per transaction and service level has every incentive to optimise for those two figures, which frequently means handling the easy volume efficiently and returning difficulty to the client. A provider measured on first-pass yield and exception reduction is incentivised to fix the process, which is what the client actually wanted to buy.
Building a Metric Set That Works
- Report leading and lagging together. Cost per transaction still belongs in the pack. It should sit next to first-pass yield and aging tails so the trend can be explained rather than merely observed.
- Measure quality at the point of failure, not at the end. Errors caught internally are cheap; errors that reach a customer or an auditor are not. Track both separately.
- Categorise every exception. If the exception reason is recorded as "other" more than a small fraction of the time, the category list is wrong and the data is worthless.
- Attribute defects to their source. Publish which upstream teams and suppliers generate the most failures. Visibility alone changes behaviour faster than any escalation process.
- Use percentiles, not averages, for anything time-based. Averages hide exactly the cases that create risk.
- Keep the set small. Six to eight measures that drive action beat thirty that produce a monthly reading exercise.
- Review the definition annually. Metrics drift as processes change, and a definition nobody has checked for three years is being gamed somewhere.
- Put the metrics in the service contract. In outsourced operations, what is measured is what is managed. Leading indicators belong in the schedule, not in a quarterly review deck.
The Version of This Problem Arriving Now
Automation and AI in back office processes make good measurement more important, not less, because they change where errors are generated and how visible they are. An AI-assisted process can show excellent throughput and cost per transaction while producing a small percentage of confidently wrong outputs that no human reviewed. Straight-through processing rate looks superb; first-pass yield measured properly — including items that completed automatically but incorrectly — tells a different story. The metric set for automated processes needs an addition: the accuracy of items processed without human review, sampled and checked independently. Without that, throughput measures are measuring speed of production, not correctness — which is exactly the failure mode that cost per transaction has always had, with a faster engine behind it. The principle from 2010 holds and gets sharper each year. Measure the condition of the process, not the volume of its output.
Common Questions
What is first-pass yield in a back office context?
The proportion of transactions that complete correctly the first time, without exception handling, return to the requester or correction. It is the earliest reliable indicator of process health.
Why is cost per transaction a poor management metric?
It is a lagging measure that improves with volume regardless of quality, and it can be reduced by pushing exceptions upstream rather than resolving them. It reports outcomes long after the causes could have been addressed.
Which metrics predict back office problems earliest?
First-pass yield, rework rate, start-of-day queue age, aging distribution tails, and categorised exception reasons attributed to their upstream source.
How should automated or AI-assisted processes be measured?
Alongside straight-through processing rate, sample and independently check the accuracy of items completed without human review. High throughput with unverified accuracy is not a performance result.
Operations Metrics Design — Outpace replaces activity reporting with a small set of leading indicators that show where your process is failing and who upstream is causing it.