Leaders Insights
Leaders Insights

Stay at the top of your field, a little every day.

DomainsMarketingDataFinanceAI
ResourcesLearnTestToolsBlogGlossary
© 2026 Leaders Insights — All rights reserved.
Tracks/Data in the public sector/Data in the public sector/Reading service metrics like a public agency operator
1/4+150 XP

Data in the public sector

1Reading service metrics like a public agency operator+1502Building open data that citizens and journalists actually use+1503
Measuring outcomes when services take years to pay off
+150
4Governing privacy and equity on legacy systems+150

Reading service metrics like a public agency operator

# Reading service metrics like a public agency operator

Open any big city's 311 dashboard (the non-emergency service request system residents use to report potholes, broken streetlights, noise complaints, and more) and you will see a number that jumps out: total requests. Last month, 84,000. Up 12 percent. Someone in a budget meeting will point at that number and ask whether the city is doing better or worse.

The honest answer: that number alone tells you almost nothing.

This lesson teaches you to read service metrics the way a seasoned agency operator does, separating the noise of raw volume from the signals that actually describe performance.

Why raw request volume misleads

Request volume measures how much residents are asking for. It does not measure how well the agency responds, or whether the underlying problem is getting better.

Volume goes up for reasons that have nothing to do with service quality:

  • A new reporting app launched. More people report the same number of potholes. Volume spikes. Streets did not get worse.
  • A viral social media post tells residents to report a specific issue. One neighborhood floods the system.
  • A storm creates a genuine surge in downed trees and flooding reports.

Each of these produces the same rising line on a chart, but they mean completely different things. An operator never reads volume in isolation.

There is also a darker version of the trap. If a city celebrates "record 311 engagement," it may be rewarding a system that generates complaints rather than one that solves problems.

Workload metrics versus outcome metrics

Here is the core distinction. Learn it and you will read any public dashboard more clearly.

Workload metrics count activity: requests received, cases opened, calls answered, inspections conducted. They describe effort and demand.

Outcome metrics measure whether the thing residents actually care about improved: Was the pothole filled? How long did it take? Did the streetlight get fixed?

Workload tells you how busy the agency is. Outcomes tell you whether being busy accomplished anything.

A concrete example

Two neighborhoods each report 500 potholes in a month.

  • Neighborhood A: average repair time 4 days, 95 percent closed.
  • Neighborhood B: average repair time 21 days, 60 percent closed.

Workload is identical. Outcomes are wildly different. A dashboard showing only "500 requests each" would hide the entire story.

The operator's questions are always: How long did it take to resolve? What share got resolved at all? And, increasingly, who got served well and who did not?

The metrics operators actually watch

1. Time to resolution (cycle time)

The clock from when a request is created to when it is closed. Usually reported as a median (the middle value) rather than an average, because a few very old cases can drag an average up and hide typical performance.

Watch for the median AND the tail. A median of 3 days sounds great, but if 10 percent of cases sit open for 90 days, those are the residents who lose faith in government.

2. Backlog and aging

The count of open cases, grouped by how long they have been open. A growing backlog of cases older than 30 days is an early warning that demand is outrunning capacity, long before it shows up in average resolution time.

3. Closure and reopen rates

A case marked "closed" is not the same as a problem solved. A high reopen rate (cases closed then reported again) signals fake closures or shoddy fixes. Operators watch this to catch gaming, where staff close cases to hit targets without doing the work.

4. Service Level Agreement (SLA) compliance

An SLA is a target commitment, for example "pothole filled within 5 business days." SLA compliance is the share of cases meeting that target. It converts a fuzzy question ("are we fast enough?") into a measurable one.

Equity: the metric raw dashboards hide

Here is the analysis that separates a real operator from someone reading top-line numbers.

Split every metric by geography, and by demographics where the data allows. A citywide median repair time of 5 days can mask a 3-day response in wealthy neighborhoods and a 12-day response in lower-income ones.

This is not hypothetical. Research and city audits have repeatedly found response-time gaps across neighborhoods. Reporting rates also differ: residents who trust government and know the 311 system report more, which can make well-served neighborhoods look like they have "more problems" simply because they ask more.

The lesson: never treat request volume as a proxy for need. Low volume can mean low need, or it can mean low trust and low awareness.

For a well-known framework on measuring what matters in government, the Government Performance and Results Act overview from GAO and performance management resources are a solid grounding in outcome-focused measurement.

🎬 [VIDEO: "How data science is transforming city services" — youtube.com — an accessible overview of how cities use 311 and operational data to improve service delivery]

A simple analysis you can run

If you had a table of 311 records with a created_date, closed_date, request_type, and neighborhood, the operator's first move is to compute median resolution time by neighborhood. In SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.View full definition → that looks like:

sql
SELECT
  neighborhood,
  request_type,
  COUNT(*) AS total_requests,
  ROUND(
    PERCENTILE_CONT(0.5) WITHIN GROUP (
      ORDER BY DATE_DIFF(closed_date, created_date, DAY)
    ), 1
  ) AS median_days_to_close,
  ROUND(AVG(CASE WHEN closed_date IS NOT NULL THEN 1 ELSE 0 END) * 100, 1) AS pct_closed
FROM service_requests
WHERE request_type = 'Pothole'
GROUP BY neighborhood, request_type
ORDER BY median_days_to_close DESC;

You do not need to write this yourself. The point is the shape of the question: group by neighborhood, measure the median close time, and check the closure rate side by side. That single query surfaces equity gaps that the headline volume number buries.

Many cities publish this raw data openly. NYC's 311 Service Requests dataset on NYC Open Data is one of the most explored public datasets in the world, and you can slice it exactly this way.

Knowledge check

1. Why does a seasoned agency operator refuse to interpret a rise in total 311 request volume as evidence of declining service quality?

2. A new reporting app launches and 311 request volume spikes 30 percent in a month. What is the most defensible interpretation for an operator?

3. Which metric best qualifies as an outcome metric rather than a workload metric?

MULTIPLE CHOICE

4. Select ALL correct answers. Which of the following would cause 311 request volume to rise WITHOUT the underlying conditions actually getting worse?

Select all the correct answers.

MULTIPLE CHOICE

5. Select ALL correct answers. Which statements correctly describe the distinction between workload metrics and outcome metrics?

Select all the correct answers.

Reading a dashboard like an operator: a checklist

When someone shows you a service dashboard, run through these questions:

1. Is this workload or outcome? If the headline is a count of requests, ask for resolution time and closure rate before drawing any conclusion.

2. Median or average? Averages hide the tail. Ask for both, and ask about the oldest 10 percent of cases.

3. What is the denominator? "2,000 closed" means nothing without knowing how many were opened. Rates beat counts.

4. Is it broken out by neighborhood? A single citywide number is almost always hiding an equity story.

5. What is the reopen rate? High closure with high reopens means the system is gaming the metric, not solving problems.

6. Did the reporting channel change? A volume spike may reflect a new app or campaign, not a change in conditions.

The trap of targets

A final operator's warning. Once a metric becomes a target, staff optimize for the metric, not the mission. This is often called Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."

If you reward fast closure times, you may get cases closed early with no work done. Good operators pair a speed metric with a quality metric (like reopen rate) so the two hold each other in check. Never manage on a single number.

Key Takeaways

  • Raw request volume is a demand signal, not a performance signal. It rises with new apps, storms, and viral posts, none of which mean service improved.

Next

Building open data that citizens and journalists actually use

Separate workload from outcomes.
Counts of activity describe effort; resolution time, closure rate, and reopen rate describe whether residents' problems actually got solved.
  • Always disaggregate by neighborhood. Citywide medians routinely hide large equity gaps in response time and closure, and low volume can signal low trust rather than low need.
  • Pair every speed metric with a quality metric. Fast closures plus high reopens means the number is being gamed, not the problem being fixed.
  • Rates beat counts, and medians plus tails beat averages. Ask for the denominator and the oldest cases before you draw any conclusion.