Disclosure: This article links to a third-party programme, and BizBot may have been compensated for that placement. We would rather flag it than leave you guessing. How we evaluate software.
Most operations teams are measured on how much they did. Tickets closed, projects shipped, invoices processed. These are easy to count because the tools count them for you, and they are what ends up in the monthly deck.
They are also the wrong numbers. Activity tells you the team was busy. It does not tell you whether the work got faster, cheaper, more reliable, or less likely to come back. The gap between those two kinds of measurement is where a lot of ops careers stall, and where a lot of software gets bought for the wrong reason.
Activity metrics versus outcome metrics
An activity metric counts events. An outcome metric describes a property of the process that produced them.
Take supplier invoice processing. The activity metric is invoices processed per week. It rises when volume rises, when someone works late, or when a colleague quits and the remaining two absorb the load. None of that tells you anything about the process itself.
The outcome metrics ask different questions. How many days between an invoice arriving and being approved for payment? What share go through without anyone touching them twice? What does it cost to process one, all in?
Some more pairs from ordinary admin work:
- Support. Activity: tickets resolved. Outcome: share of contacts that repeat something the same customer raised last month.
- Onboarding. Activity: new starters processed. Outcome: how many had a working laptop, accounts and payroll record on day one.
- Order fulfilment. Activity: orders shipped. Outcome: share shipped correctly first time, with no return or credit behind them.
Activity numbers are not useless. They are denominators — you need them to calculate the outcome numbers. That is a good reason to keep collecting them and a bad reason to report them alone.
Five measures a small team can instrument without a data warehouse
You do not need a warehouse or a BI team for these. Four of the five come out of a well-configured project tool and a spreadsheet. Each is also easy to misread, so each is paired with the way it lies to you.
Cycle time
Elapsed time from the moment a request enters your queue to the moment it is done from the requester’s point of view. Not the time you spent on it — the time they waited.
It is the most useful number in most admin processes, because waiting is where the cost hides. Work taking forty minutes of effort and two weeks of calendar time is a queueing problem, not a capacity problem, and needs a different fix.
How it misleads: averages hide the cases that hurt. If most requests clear in a day and a few take weeks, the mean looks fine while the slow ones generate every complaint. Use the median and the 90th percentile together. Be strict about the start point: if the clock starts when someone picks the item up rather than when it arrived, you have measured your own diligence, not the requester’s wait.
First-pass yield
The share of items that go through the process correctly without intervention, correction or a second pass.
This shows how much of the day goes on exceptions, and it is the honest test of whether an automation works. A rule that handles the easy majority cleanly and dumps the rest into a manual queue has not removed work, it has concentrated it.
How it misleads: it is very sensitive to how you define “correctly”, and teams under pressure quietly widen the definition. It also punishes processes that deliberately include review — a contract going to legal has not failed first-pass, it was designed that way. Decide which touches count as exceptions before you start, and write it down.
Rework rate
The share of completed items that come back: reopened tickets, reissued invoices, corrected payroll entries, returned orders.
Rework is the closest thing to a quality signal admin work produces, and it is usually invisible: reopened work looks like new work in the activity count. A team can look more productive precisely because it is doing the same job twice.
How it misleads: it depends entirely on whether people reopen the original record or open a new one. If your help desk makes reopening awkward, agents raise a fresh ticket and your rework rate looks excellent while the actual problem is untouched.
Backlog age
Not how many items are waiting, but how long the oldest have been waiting and how that is moving.
Backlog count is an activity metric in disguise. It can stay flat while the composition rots underneath, because easy items get cleared and hard ones accumulate. Age catches that. If your oldest open item is aging faster than the calendar, you have a category of work nobody owns.
How it misleads: it is trivially gamed by closing old items as “no longer relevant”. That is sometimes the right call and sometimes a way to make a chart look better, and the metric cannot tell the two apart.
Cost per transaction
Loaded cost of running the process — salaries, licences, outsourced steps — divided by the items it handled.
This turns an ops argument into a finance argument, and it is what makes or breaks the case for a tool purchase, because the licence sits in the numerator next to the labour it is meant to displace.
How it misleads: it drops when volume rises whether or not anything improved, since most of the cost is fixed. It also rewards cutting the review steps that keep rework down. Never read it without first-pass yield beside it.
Where the numbers actually come from
In a small business the raw material for all five already exists. It is just scattered.
Cycle time timestamps live in the project tool. Reopen data lives in the help desk. When the request was first made, by whom and against which account lives in the CRM. Cost lives in the finance system and in payroll.
No one of those tools is the problem. The problem is that a ticket, a deal and an accounting line refer to the same work under three different identifiers, with no field connecting them. So the report gets built by hand: three CSV exports on the first Monday of the month, reconciled in a spreadsheet, badly.
That is usually diagnosed wrong. It is an integration problem, not a dashboard problem. A BI tool on top of four systems that share no key just renders inconsistent data faster. The fix is duller: agree on a shared identifier, push it into every system that touches the process, and use an automation platform to keep records in step. Our guide to automation and integration tools covers how those platforms are priced and where they fail quietly, and the Zapier and Make comparison is a fair starting point.
If you do outgrow spreadsheet reconciliation — high volume, real-time answers, several systems feeding one view — that is where operational reporting in a data warehouse starts to earn its cost. Most small teams reach that point far later than the vendors suggest.
Problem, measure, tool category
A rough map from the thing you notice, to the thing that shows it, to the software category that instruments it.
| Problem you feel | Measure that shows it | Tool category that instruments it |
|---|---|---|
| “Everything takes forever but nobody looks busy” | Cycle time, median and 90th percentile | Project or task management with status timestamps |
| “We keep fixing the same things” | Rework rate, reopen rate | Help desk or ticketing with reopen tracking |
| “The automation did not save any time” | First-pass yield | Workflow automation with run and error logs |
| “Requests fall through the cracks” | Backlog age of the oldest open items | Shared queue or intake form feeding one system |
| “We cannot justify the headcount” | Cost per transaction, with volume | Accounting or finance system, plus time tracking |
| “Nobody agrees on the numbers” | All of the above, from one source | Integration platform before reporting platform |
We have guides for two of those categories: project management tools for small teams, and help desk software, where the Zendesk and Freshdesk comparison covers how differently the two treat reopened tickets.
When measurement makes things worse
Three common failure modes.
The metric gets gamed. Any measure attached to an individual’s performance review will be optimised, usually not in the way you intended. Measure agents on tickets closed and tickets get closed prematurely. Measure first response time and you get an empty acknowledgement in minutes and no answer for two days. That is not a character flaw in your team, it is what happens when you point an incentive at a proxy. Team-level measures, read as a trend rather than a target, are much harder to distort.
The dashboard nobody reads. A dashboard not attached to a specific recurring decision is decoration. Before building one, name the meeting it will be opened in and the person who will be asked about it. If neither exists, you are building a screensaver — and the cost is ongoing, because someone maintains it forever.
Instrumenting what you were never going to change. Measurement is not free. It costs configuration, discipline in how fields get filled in, and the tax of a process with extra steps. If the answer to “what would we do if this number were bad?” is “nothing, that is how the finance calendar works”, do not measure it. Track two or three things you can act on.
There is a quieter fourth: measuring a process before it is stable. If the way work gets done changes every fortnight, your trend line is measuring your own reorganisations.
The career part, grounded
The reason any of this matters to a career is narrow. The people who move up in operations are the ones who can name a number they moved.
Not “I improved our invoice process”, but: here was median approval time before, here it is now, here is what first-pass yield did over the same period, and here is what we changed — a shared intake form, one identifier carried between the finance system and the project tool, two approval steps removed. That works in an interview, a review, and a business case. It survives scrutiny because it is falsifiable.
Almost nobody has that sentence, because almost nobody instruments the before state. The most useful thing you can do this quarter is baseline one process you already intend to change. It costs a few hours, and it is the difference between claiming an improvement and demonstrating one.
Formal study is one route to the framework side of this — operations management, process design, cost accounting. There are several: an internal secondment, a professional certification, a short course, or a degree taken part-time, such as the online business programmes at Northwest Missouri State University, which cover operations management and analytics for people studying alongside a job. Whether that is worth the money and the years depends on where you are and what your employer recognises. It is not a substitute for the baseline: the vocabulary helps you explain the number, it does not produce the number.
Start with the process that annoys you most. Find out how long it actually takes and how often it has to be done twice. You will usually be surprised. That is the point.
More on this topic
Browse all 52 articles on HR & People Ops.
