Machine Learning for Local Government: A Guide to Forecasting Municipal Service Demand
Every Monday morning, someone in a city office opens a spreadsheet and guesses. How many calls will the sanitation desk get this week? Do we need two extra people on permit intake, or will one do? The guesses are usually decent, because experienced staff know their city. But decent guesses still leave crews idle on slow days and overwhelmed on busy ones.
Municipalities sit on a quiet asset: years of their own service records, published as open data. With a modest amount of regression modeling, a small agency can turn that archive into a weekly or daily forecast of 311 call volume. You do not need a data science team. You need a spreadsheet, a public dataset, and a willingness to check your work.
Start with the data you already publish
Most mid-sized cities post 311 service requests to an open data portal, often updated daily or monthly. Typical fields include the request type, the date and time it was created, the reporting channel, the neighborhood or ward, and sometimes a closing date. That is enough to begin.
Download two or three years of records as CSV. More history is nice, but two years gives you seasonal patterns and roughly a hundred weeks to test against. Clean the file before modeling:
- Drop duplicate request IDs and test entries.
- Standardize the date column to a single format. Mixed formats break almost every tool.
- Decide what "volume" means. Calls created per day is the simplest target; requests closed per day is often the number your staffing actually depends on.
- Group request types sensibly. Thirty narrow categories produce noisy forecasts; six to ten related groups (streets, sanitation, water, permits, parks, animal services) forecast better.
- Mark obvious anomalies — a system outage, a major storm, a data migration — so you can inspect them later instead of letting them distort the model.
If your city does not publish 311 data, the same approach works with internal work-order logs, permit applications, or library visits. The method does not care where the timestamps come from.
Build a baseline before building a model
The most common mistake is jumping straight to something complicated. Start with the simplest possible forecast and see how far it gets you. For each request group, a reasonable baseline is the average of the same weekday over the last four weeks. It costs nothing, it is easy to explain to a department head, and it often performs respectably.
Keep that baseline. It becomes your benchmark. Any model you build has to beat it on data the model has never seen, or it is not worth the added complexity.
Choosing the target and the horizon
Be specific about what you are predicting and how far ahead. "Call volume" is too vague. "Sanitation requests created per day, forecast seven days ahead," is a question you can answer and act on. A seven-day horizon suits shift scheduling. A thirty-day horizon suits seasonal hiring, but it will be less accurate, and you should say so when presenting it.
A regression model you can build this week
Linear regression is the right starting point, not a compromise. It is fast, transparent, and every coefficient has a plain-language meaning you can defend in a budget meeting. Set up one row per day per request group, with these features:
- Day of week. Use six indicator columns rather than a single 1–7 number, so the model can learn that Monday behaves differently from Friday.
- Month or week of year. This captures seasonal swings like leaf collection or summer park complaints.
- Holiday flags. Public holidays shift demand in ways the day-of-week features miss.
- Recent history. Include the count from the same day last week and a seven-day moving average of the prior week. These two features usually do most of the work.
- Weather, if you have it. Free historical weather data is widely available. Temperature and precipitation help for storm drains and snow routes; skip weather for permit intake, where it adds noise.
Fit the model on the older portion of your data and hold back the most recent months. Compare its average error against the baseline. Report error in units staff understand: "off by about nine calls a day on average," not "root mean squared error of 3.1."
If a model cannot beat last month's simple average on data it has never seen, it does not belong in a staffing decision — no matter how elegant it looks.
Turn forecasts into staffing decisions
A forecast is only useful once it changes a schedule. Map predicted volume to workload using a figure your team already trusts, such as calls handled per person per shift, then add a buffer for the days the model runs low. Forecasts are wrong in both directions, and understaffing tends to cost more politically than overstaffing.
Two practical habits help. First, publish forecasts as ranges — "between 140 and 175 sanitation calls on Tuesday" — rather than a single number. Ranges communicate uncertainty honestly and reduce arguments when the actual figure lands at the edge. Second, review the forecast against actuals every week. When the model misses badly, ask whether the cause was a genuine surprise, like a burst water main, or something the model should have known. Only the second kind is worth fixing.
A short note on scope: this approach supports operational planning. Anything involving employment terms, overtime rules, or union agreements in a specific jurisdiction needs review by whoever handles that for your city — a forecast does not settle those questions.
Keep the model simple enough to maintain
The forecast is a tool, not a project. Store your cleaning steps in a script so the process can be rerun when new data arrives. Refresh monthly, not daily. Document which features you used and why, in a page, so the work survives staff turnover. Retrain each year with the newest data, and retire features that stopped helping.
Guard against the quiet failure mode: a model that drifts out of sync with reality because the city changed. A new online portal, a reorganized department, or a new request category can shift patterns overnight. Watch the weekly errors, and when they widen for no obvious reason, go back to the baseline and rebuild.
Where to begin on Monday
Pick one request group with clear seasonal swings and real staffing pressure — missed trash pickup is a good candidate. Export two years of that group's records, build the day-of-week baseline, and compare it to a regression with the features above on the last three months of data. If the model wins, show both error figures side by side to the manager who owns that schedule and ask what staffing change the forecast would inform.
That one small proof is worth more than an ambitious citywide platform. It builds trust, teaches your team the workflow, and gives you something concrete to point at when the next budget cycle asks why the city should invest in forecasting. Start narrow, test honestly, and let the results argue for expanding.
Photo: Dele_o / Pixabay