We analysed 603,544 public service requests across January and February 2025. Correcting for month length, reconciling totals and separating request categories produced a more useful demand picture than the headline decline.
348,180 in January and 255,364 in February. These are requests, not unique customers. [1][2]
11,231.61 requests/day in January versus 9,120.14 in February. [1]
1,391.58 → 1,509.54 per day, even though the monthly count fell. [1]
The grouped counts match the separately fetched total in each month. [1]
A monthly dashboard can point a team toward the wrong operational conclusion even when every number on it is accurate.
NYC Open Data’s agency-directed 311 service requests, created from 1 January through 28 February 2025. We fetched all 1,864 grouped rows for month, borough, agency, complaint type and current status, then fetched independent monthly counts. This study uses the complete aggregates, not the truncated dataset used in the separate performance experiment.
Count agency-directed service requests by creation date. Use half-open date boundaries: January 1 inclusive to March 1 exclusive. Divide each month by its calendar-day count—31 and 28—rather than treating a monthly total as a daily workload rate.
Fetch grouped counts and independent month-only counts from the same source. Confirm that all grouped rows fit below the 50,000-row response limit and that their sums match both month totals. Preserve the original responses and retrieval timestamps.
Aggregate by complaint category and borough. Compare absolute daily changes as well as percentage changes; this prevents small categories with large percentages from dominating the operational discussion.
Report the direction and composition of demand. Do not infer satisfaction, staffing efficiency or the cause of a spike from request counts. Treat statuses as extraction-time values, not a reconstruction of the month-end queue.
The raw total declines by 26.66%. After dividing by 31 and 28 calendar days, the decline is 18.80%—a difference of 7.86 percentage points. Both statements are mathematically correct, but they answer different questions. [1]
Why it matters. A monthly volume report helps reconcile throughput. A daily rate is more useful for an initial demand comparison. Neither alone is a staffing forecast.
Illegal-parking requests fall from 43,139 to 42,267 in total, yet rise from 1,391.58 to 1,509.54 per day. Residential-noise and heat/hot-water requests account for much of the overall daily decrease: 1,322.74 and 715.14 fewer requests per day respectively. [1]
Why it matters. An across-the-board capacity cut would overlook a category with higher daily demand. Investigate routing and workload by category before changing coverage.
The borough value is Unspecified for 177 January requests and 175 February requests. We keep these rows in overall totals and in a visible unknown bucket. Dropping them would make borough totals disagree with the report’s headline. [1]
Why it matters. A data-quality exception is part of the report, not a reason to silently lose records.
The source counts requests directed to agencies. A person may submit multiple requests. Current status is not a historical month-end snapshot, and the selected fields do not measure successful resolution, effort or satisfaction. [1][2]
Why it matters. Do not turn a falling request count into a claim that self-service improved, problems were solved or customers became happier.
January 2025: counts divided by 31 calendar days.
| Measure | January 2025 | February 2025 | Change |
|---|---|---|---|
| All requests | 348,180 | 255,364 | −26.66% total |
| Requests per calendar day | 11,231.61 | 9,120.14 | −18.80% per day |
| Illegal parking: total | 43,139 | 42,267 | −2.02% total |
| Illegal parking: per day | 1,391.58 | 1,509.54 | +8.48% per day |
| Residential noise: per day | 2,285.06 | 962.32 | −1,322.74 per day |
| Heat / hot water: per day | 2,168.68 | 1,453.54 | −715.14 per day |
Rate = monthly count ÷ calendar days. Percentage change = (February rate ÷ January rate − 1) × 100. Values are rounded only for display. This is not an adjustment for weekdays, seasonality or weather. [1]
The evidence download contains both raw aggregate responses, all category breakdowns and the calculation script. Run python scripts/analyze-public-studies.py. The script asserts that grouped sums equal independent counts and saves the unrounded rates. Unspecified boroughs remain in the denominator.
SELECT date_trunc_ym(created_date) AS month,
borough, agency, complaint_type, status,
count(*) AS requests
WHERE created_date >= '2025-01-01T00:00:00'
AND created_date < '2025-03-01T00:00:00'
GROUP BY month, borough, agency, complaint_type, status
ORDER BY month, borough, agency, complaint_type, status
Daily rate = requests / calendar days
Rate change (%) = (February rate / January rate - 1) * 100These are SystemVale’s recommendations for a comparable product or service. They are not claims that the organisations studied implemented them.
Proposed dashboard definition: created requests, reporting interval, calendar-day denominator, extraction timestamp and included categories. Place the total and daily rate beside each other so a reader can see why they differ.
Before refreshing a report, compare the grouped sum with the independently fetched source total. Mark a mismatch or truncated response as incomplete and retain the previous verified snapshot. A successful HTTP response is not enough.
Use the category breakdown to select questions for operations staff. Then obtain longer history, weekday patterns, handling time and capacity. The next analysis should test seasonality and workload effort before proposing schedules or automation.
For a service business, connect a request identifier to first response, resolution, reopen events and customer feedback. Publish the join rate and unmatched records. Avoid merging different people solely because their issue text looks similar.
Make the denominator and the missing data visible before asking a dashboard to guide operational decisions.
Our interpretation of this study. Not a client quote or endorsement.
A request-level dataset needs request-level language. Unique customers require a separate, appropriate identity measure.
The overall direction can conceal a growing workload category. Operational decisions need the composition as well as the total.
A report is more trustworthy when it can show how every subtotal returns to the original count.
Download the five-study evidence bundle: captured public data, source hashes, scripts, licenses and original result files. The README explains the commands and the boundaries of each experiment.
Calculated 12 October 2026 from the saved public responses.
Dataset definition and update behaviour. Exact API selections are in the evidence manifest.
Source context for the evolving dataset; reviewed 12 October 2026.