You can measure a service two ways, and confusing them is how you end up with every dashboard green and nobody better off. One set of numbers tells you whether the service is being produced well. A different number tells you whether producing it's doing any good. They're not the same question, and most operating models only ever answer the first.
The good news is that service measurement isn't a blank page. Government reference models have been typing services for years, and the pattern that falls out is clean: a service is measured on three families of metric, and knowing which family answers which question is most of the skill.
The three families
Every service can be measured on efficiency, quality, and effectiveness.
Efficiency is cost. Cost per transaction, cost per case, cost per unit of output. The same childcare subsidy costs the agency under a dollar to process through self-service and about thirty dollars in person. That gap is an efficiency number. Efficiency asks: what does it cost us to produce this?
Quality is the service measured against what the client was implicitly promised. It has five dimensions, worth naming because teams forget most of them:
- Responsiveness: how quickly
- Accuracy: how correctly
- Availability: when and where it can be reached
- Reliability: how consistently
- Simplicity: how much effort the client has to spend
Quality asks: are we producing it to the standard the client expects?
Effectiveness is different in kind. It measures whether the output is actually moving the outcome the service exists to achieve: outcome achievement, take-up, reach. For the subsidy, effectiveness isn't "did we pay it accurately and cheaply" but "did the family end up self-sufficient." Effectiveness asks: is producing this doing any good?
Two of them are the service level; one is the outcome
Here is the distinction that organises everything. Efficiency and quality both measure the output against client expectations. Together they're the service level, and they answer one governance question: are we getting this done well? That's the Deliver question in the Design4 cycle, and it's where a service-level agreement lives. Cost, speed, accuracy, availability, reliability, simplicity: all of it describes how well the service produces its output.
Effectiveness measures something the service level can't see: the output's contribution to the outcome. It answers a different governance question: are we getting the benefits? That's the Discover question, and it's where the service either justifies its existence or quietly fails to. A service can be fast, cheap, accurate, and available around the clock, and still move nothing that matters. The service level would be all green. Effectiveness is the only family that would catch it.
So the two questions a board actually asks map cleanly onto the families. Efficiency and quality answer "are we getting them done well." Effectiveness answers "are we getting the benefits." Miss the split, and you will answer the first question beautifully and mistake it for the second.
Why the split has a practical shape
There's a reason efficiency and quality feel patternable while effectiveness feels bespoke, and it isn't an accident. Services can be typed, and the type carries most of its own metrics. A financial-support service, a licensing service, an advisory service: each comes with a standard activity pattern and a standard set of efficiency and quality measures. You don't invent "cost per transaction" or "time to decision" from scratch. The service type hands them to you.
Effectiveness is the one family the type can't supply, because outcome contribution is specific to the program the service serves. The reference model can tell you how to measure whether a subsidy is paid accurately and cheaply. It can't tell you whether paying it moves families off assistance, because that depends entirely on what this particular program is for. Efficiency and quality come from the service type; effectiveness comes from the strategy. That division is worth remembering, because it tells you which numbers you can reuse and which you have to derive.
The trap
The trap is now easy to name. It is measuring efficiency and quality, watching them go green, and calling the service a success. This is the most common failure in operating-model measurement, and it has a name: Measurement Theatre. The service level is immaculate. The board asks what value was delivered and receives a progress report about cost and speed. Nobody asked the effectiveness question, so nobody noticed the outcome never moved.
It is a comfortable trap, because efficiency and quality are the easy numbers. They are patternable, they're quick to instrument, and they nearly always improve when you work on them. Effectiveness is slower, program-specific, and sometimes says something you didn't want to hear. A service model that only measures the easy two isn't lying; it's just answering the wrong question with great precision.
How to use it
For every service in your operating model, define all three, and label which question each answers.
- Efficiency and quality, together, are the service level. Set them as a real agreement: this output, at this cost, at this speed, this accurately, this reliably, this available. That is your answer to "are we getting it done well," and it's what you hold the service owner to day to day.
- Effectiveness is the outcome contribution. Derive it from what the service is for, not from the service type. That is your answer to "are we getting the benefits," and it's what you take to the board.
The discipline is to hold both. A service with a green service level and no effectiveness measure is a candidate for Measurement Theatre. A service with an effectiveness target and no service level is a good intention with no operational grip. You need the two ends: the output measured well, and the outcome it's supposed to move.
Map each service and its three families on the free Service Operating Model Canvas, and see how the whole service-oriented operating model is instrumented. Next, read why outputs aren't outcomes. The Closing the Strategy-Execution Gap course connects service measurement back to the strategic choices it's supposed to serve.