A Green Dashboard and Falling Satisfaction
Meridian Health's IT leadership reviews a 22-metric service desk dashboard every week. Over two quarters, average speed to answer fell from 90 to 35 seconds, first-contact resolution rose from 61% to 74%, and every metric on the dashboard shows green. In the same period, user satisfaction fell from 4.1 to 3.3 out of 5, reopened tickets doubled, and 30% of contacts now arrive through a chat channel that is not counted in the dashboard at all. The service desk manager wants to add seven more metrics to 'show the real picture'; the CIO wants one page that tells her whether service is getting better. No outcome or end-to-end customer measure currently exists.
1. Explain why the dashboard is green while satisfaction is falling, and identify the measurement weaknesses you would raise with leadership.
Read the worked answer
The dashboard is measuring activity inside one team, not the outcome the user experiences. Symptoms map to recognisable measurement failures:
- Narrow scope / incomplete data. A channel carrying 30% of demand is not counted, so the reported picture is a subset presented as the whole. Speed-to-answer and FCR are computed on a shrinking share of reality.
- Optimising the metric, not the outcome. Speed to answer measures how fast the phone is picked up, not how fast the user is working again. Agents can hit it by answering and transferring. Rising first-contact resolution with doubled reopenings is the classic signature of a ticket being closed rather than resolved.
- Lagging-only set. Every metric describes what already happened inside the desk. Nothing is leading, and nothing reflects the user's journey across teams.
- Volume of measures without purpose. 22 metrics with all-green thresholds usually means thresholds were set for comfort, not for decision-making. A metric that cannot trigger an action is decoration.
What to say to leadership. The green dashboard is not lying; it is answering the wrong question. Adding seven more internally-focused metrics will make the reporting worse, because it further dilutes attention and adds more ways to look successful.
Also challenge the satisfaction figure's role. 3.3 is the only customer-sourced number on the table, which means the organisation currently trusts internal proxies more than the people it serves.
2. Design the measurement and reporting approach that would let the CIO answer 'is service getting better?' from one page. Justify your choices.
Read the worked answer
Start with purpose, then metrics. The one page exists to support a decision: where to intervene. So define the questions first - is the user's outcome improving, is demand being absorbed, are we creating rework, is our capacity adequate - and select a small set that answers them.
Proposed structure (one page, three layers).
- Outcome layer (lagging): user satisfaction and a defined end-to-end measure such as time from contact to user working again, measured across all channels including chat. This is the layer the CIO reads first.
- Driver layer (leading): reopening rate, percentage of contacts resolved at first point of contact across channels, backlog age, demand volume and mix. These explain movement in the outcome layer and are what managers act on.
- Health/context layer: coverage of data sources and confidence in the numbers, so nobody reads a partial picture as complete.
Rules that make it work.
- One agreed definition per metric, with the data source and owner documented; fix the chat channel gap before publishing.
- Explicit thresholds tied to an action or escalation, not to a colour.
- Separate operational reporting (daily, team level, many measures) from governing-body reporting (monthly, few measures, trend plus narrative). The 22-metric view can survive as an operational tool as long as it is not presented as the service story.
Judgement point. Resist adding metrics to prove a point. The credible move is to fix the rework and reopenings - which the driver layer makes visible - and let the outcome measure recover.