Forecasting demand and staffing levels with your own agency data

Reference article · 6 min read

A department head asking for two more positions in a budget hearing is making a claim about the future. The strongest version of that claim is not a vendor projection or a comparison to a neighboring jurisdiction. It is the agency's own history: how many permit applications arrived each week for the past three years, how many calls the contact center answered by hour of day, how many inspection requests came in during the weeks after a storm. Most agencies already hold enough of this data to build a defensible forecast, and most have never assembled it in one place.

Forecasting demand does not require a data science team. It requires a clean count of past events, an honest test of whether your method would have predicted the past, and a translation from predicted volume into shifts and positions. The third step is where most projects fail, and the first step is where most of the value is.

Start with a clean count of events

Define the unit before you touch a tool. One permit application received. One call answered. One dispatched incident. One walk-in ticket issued. Then pull the timestamped history.

• Use the event time, not the record time. Systems often carry a created date, a modified date, and a migration date. A forecast built on the wrong column will show a spike on the day of a data conversion.
• Forecast arrivals, not completions. Applications processed reflects your staffing, not the public's demand. Arrivals are the thing you cannot control.
• Include the zeros. Weekends, holidays, and closure days belong in the series as zero or low counts, not as missing rows.
• Keep a change log next to the series. Portal launches, fee changes, consolidations, CAD or permitting system upgrades, and ordinance changes all create level shifts. An unexplained jump in the data usually has an administrative cause, and someone in the room remembers it.
• Get enough history. Roughly two to three full years lets you see annual seasonality at all. Less than that, and you are fitting noise.

The patterns that carry most of the signal

Nearly all predictable variation in agency demand comes from the calendar.

• Hour of day and day of week. This dominates contact centers, dispatch, and counter traffic, and it is remarkably stable.
• Annual seasonality. Permits and inspections follow the construction season. Utility calls follow heat and cold. Code enforcement follows weather and daylight.
• Holidays and closures. Model the day before and the day after as well. A holiday that lands on a different weekday than last year will move volume.
• Known one-time events. Fee deadlines, tax rolls, elections, rate changes, grant windows, and new mandates. Maintain this calendar by hand; no model will infer it.
• Weather. Real, but useful only inside the window where weather itself is predictable, which is a few days. Weather cannot support a twelve month hiring plan, because that would require forecasting the weather twelve months out.

Why simple baselines are usually the right answer

Start with the obvious methods: the same week last year adjusted for growth, a moving average of recent same weekdays, or exponential smoothing with a seasonal term. These are reproducible in a spreadsheet, explainable to a council member, and they fail gently when conditions change.

Elaborate models need many observations per parameter, and a weekly agency series is short. Make the rule explicit: any more complex approach must beat the simple baseline on data it has never seen, by a margin large enough to justify maintaining it. Often it does not.

Evaluate the forecast honestly

• Backtest with a rolling origin. Stand at a date in the past, forecast forward, compare to what happened, then roll forward and repeat. Never score a model on data it was fitted to.
• Report error in units people understand. Average absolute error in calls per hour or permits per week travels better in a hearing than a percentage, and percentage error behaves badly when counts are near zero.
• Score at the horizon you will actually use. Accuracy next Tuesday says nothing about accuracy next October.
• Publish a range, not a point. Staffing decisions are coverage decisions. You need the plausible high, not just the average.
• State the horizon you trust. Intra-week patterns hold up well. Quarterly volume is usually workable. Multi-year projections are planning assumptions, not forecasts, and should be labeled that way.

Turn volume into coverage and hiring decisions

Convert predicted demand into workload using measured handle time, touches per application, or travel plus inspection time. Then add shrinkage: leave, training, breaks, and administrative time. Scheduled bodies, not raw headcount, is what a shift plan needs.

For queued work such as phones and counters, remember that required staff rises faster than volume as a queue approaches saturation. Modest growth can force a disproportionate increase to hold the same wait time. Erlang style queueing calculations capture this and are worth using instead of a straight ratio.

Work backwards from the seasonal peak through recruiting, background checks, training, and onboarding time to find the date a hiring request must be approved. Then give the budget body a choice: expected wait time or permit turnaround at two or three staffing levels, with the forecast range shown. A tradeoff presented honestly survives questioning better than a single number. Confirm any schedule or overtime changes against your labor agreements and applicable wage and hour rules with HR and counsel, since those requirements vary and change.

What to require of a vendor

• A backtest on your data, before award or at pilot. Not a demo on sample data.
• A documented comparison to a simple baseline. If the product cannot beat seasonal naive on your history, you have learned something valuable.
• An explainable method. Proprietary is fine. Unexplainable is not, because you will have to defend the number publicly.
• Export rights for inputs, features, and outputs. Your demand history and the forecasts derived from it are agency records, and forecasts used in decisions may be subject to public records law. Confirm retention with your records officer.
• Aggregate data by default. Counts by hour and category are usually sufficient. Avoid moving identifiable case or caller data when you do not need it.
• A named owner and retraining cadence. Models drift. Price the ongoing maintenance, not just the build.

Pick one demand stream with real pain, pull three years of clean event timestamps, build the naive baseline yourself, and backtest it before anyone buys anything. HQT works with state and local agencies on data analytics and forecasting built on the agency's own operational systems.

Frequently asked questions