Transit Ridership Recovery Planning

A transit agency was rebuilding its service plan after a period of disrupted demand. Headline ridership had partially recovered, but the average hid very different stories by station, day type and time period. Planning on the systemwide number would have restored service where it was no longer needed and left crowded stations short.

The planning decision

The agency had to allocate service hours and station staffing for the coming schedule. The useful question was not "is ridership back?" It was "which stations and day types have recovered, which have changed permanently, and how much uncertainty should the plan carry?" The answer had to be expressed in the same units the planners already use — entries by station and day type — and had to survive scrutiny from operations and finance.

What we worked with

• Station entries: daily totals for each rail station, published from 2001 onward.
• Day type: weekday, Saturday, and Sunday or holiday — each with a different demand pattern.
• Station identifiers and names: used to track openings, closures and renamings over two decades.
• Calendar context: holidays, major events, weather and known service disruptions, assembled separately to explain unusual days.

Entries count people entering a station, not journeys. Transfers, exits and fare evasion are not represented, so every measure was labelled as an entry measure rather than a ridership total.

The traps we designed around

• Zeros are not always low demand. Station closures, renovations and incomplete reporting produce zero or near-zero days. Treated as demand, they look like a collapse that never happened.
• The structural break. Demand patterns before and after the disruption are not comparable. Models mixing the two periods learn an average of two different systems.
• Aggregation hides the story. Systemwide recovery can coexist with stations at 60% and others above their previous peak. Planning at the total level misallocates service.
• Day type and calendar effects. A holiday weekday is not a weekday. Comparing raw daily totals across weeks without aligning the calendar produces false recoveries and false declines.
• A point forecast is not a plan. Planners need a range and a stated assumption set, not a single number that will be wrong by Tuesday.

How the planning view was built

1. Audit the history. Zero runs, station openings, closures, renamings and duplicates were identified and flagged before any comparison. Known disruption days were marked rather than deleted.
2. Build station profiles. Each station was described by its weekday, Saturday and Sunday patterns, its share of system entries and its volatility. This separated commuter stations from event and leisure stations.
3. Normalise for comparison. A recovery index compared matched weeks and day types against the pre-disruption baseline, excluding closure periods and flagged anomalies.
4. Segment before forecasting. Stations with stable seasonal patterns, stations with event-driven spikes and stations with unresolved data gaps were forecast separately. A single model across all stations would have averaged away the differences that matter.
5. Quantify uncertainty. Forecasts were delivered as intervals with explicit assumptions about service levels, remote work and events, so planners could choose a scenario rather than accept a point estimate.
6. Connect to the service plan. The output was translated into service-hour and staffing scenarios by station and day type, reviewed with operations before publication.
7. Set a review cadence. Recovery indices and forecast errors were reviewed monthly, with a documented rule for when a station's plan should be revised.

What this changes

• Planning moves from systemwide to station-day. Service hours follow where demand actually is, not where it was before the disruption.
• Closures stop masquerading as demand loss. Data quality flags are visible in the same view as the trend, so a maintenance period does not trigger a service cut.
• Scenarios replace single numbers. Finance and operations can see the range and the assumptions behind each plan.
• Recovery becomes measurable. The index gives a consistent way to report progress by station group and day type.

What we delivered

• A station-by-day-type profile and a recovery index normalised to matched baseline periods.
• Forecasts with intervals for each station group, plus a scenario table for planning.
• Service-hour and staffing scenarios linked to the forecast assumptions.
• A data-quality register covering closures, missing periods, openings and renamings.
• A monthly review pack with forecast error, recovery movement and revision triggers.

Where this applies

This fits transit agencies, municipal service teams and utilities that plan capacity from location-level history. The minimum inputs are a stable location identifier, daily or weekly demand, a calendar of known disruptions and a planning unit that operations already use. The first deliverable is usually the data-quality register — because in public-sector operational data, closures and reporting gaps are more likely to distort a plan than the choice of forecasting method.

This is an illustrative case study built on an anonymized dataset; it does not report results from a specific client engagement. It reflects our standard method for location-level demand planning under a structural break.