Estimate likely shuttle riders using PLZ clusters, shift windows, commute gaps and surveys to de-risk your launch.
If you launch a shuttle without a ridership forecast, you risk paying for empty seats, extra driver hours, and avoidable fuel costs. The article’s core point is simple: before you spend money, you should estimate likely riders using just a few inputs - home PLZ, shift times, current commute gaps, and employee survey responses.
Here’s the short version:
A few figures from the article help frame the model:
| Forecast step | What I check | Why it matters |
|---|---|---|
| Define use case | Parking, shift access, hiring, commute reporting | It sets the target group |
| Gather inputs | PLZ, site, shifts, headcount, commute mode | It gives the model its base |
| Map demand | PLZ clusters and stop catchments | It shows where riders may come from |
| Filter demand | Public transport access and shift fit | It removes weak demand |
| Estimate uptake | Survey-based boarding rate | It avoids overestimating use |
| Compare scenarios | Vehicle size, stop pattern, timing | It supports a go/no-go decision |
So in other words: a pre-launch shuttle forecast is not about guessing demand. It is about testing whether enough people are likely to board, at the times that matter, before you commit € budget. The rest of the article explains that process step by step.
Before you model demand, pin down the business problem the shuttle is meant to solve. A forecast only matters if it points to actual riders, not just people who could, in theory, use the service.
A common mistake is going straight into route planning. It feels productive, but it skips the hard part. First, define the operating constraint: is the site hard to reach by public transport? Is parking full? Are you trying to cover early or late shifts? Or do you need defensible data for Scope 3 Category 7 employee commuting emissions?
Each use case changes the target group, shift pattern, and success metric. A shuttle set up to ease parking pressure needs a strong load factor. A shuttle used for recruitment needs to reach PLZ clusters where demand is dense.
Once the use case is clear, collect only the inputs that shape demand and boarding.
You don’t need a huge data stack to build a defensible forecast. In most cases, a small shared dataset is enough. The table below shows what each input is for and where you can usually get it inside the business.
| Input | Role in the forecast | Internal source |
|---|---|---|
| Anonymised home PLZ | Clusters employees into catchment areas and origin corridors | HR / Payroll |
| Site location(s) | Defines destinations and access points | Facilities / Real Estate |
| Shift schedules | Identifies peak departure waves and expected load factor | Operations / Production Planning |
| Headcount by site or team | Sets the ceiling for potential demand | HR / Department Leads |
| Current commute modes | Establishes expected boarding rate and mode-shift potential | Employee surveys / Parking management |
Treat shift rosters as demand ceilings, not demand itself. If 200 people start on the same shift, that does not mean 200 shuttle riders. That’s where a stated preference survey helps. It gives you a better read on likely boarding and lets you tune the forecast with something closer to actual behaviour.
Triply models actual commutes from minimal data, then simulates shuttle measures before you invest. That gives mobility, finance, and sustainability teams one shared forecast base to work from.
With the input set in place, the next step is to map where demand clusters around your sites.
Start by mapping PLZ clusters to see where enough riders live close to one another to justify a stop. At this point, you're not planning the route yet. You're simply working out which origin zones have enough rider potential to make a dedicated stop worth it.
Plot employee home postal code (PLZ) data to spot density hotspots. As a starting point, use a walking catchment of about 400 m to 800 m around any proposed stop [6]. Instead of modelling individual addresses, group nearby PLZ clusters together. That helps protect privacy and cuts down noise from small address changes [2].
For hub access, test a 3,6 km to 4 km catchment area around a high-frequency transit hub with a 15-minute-drive isochrone [5].
Once you can see where demand clusters sit, the next step is to check which of those employees could actually ride on each shift.
Being close to a stop can make ridership look higher than it will be. The employees who reflect real demand are the ones dealing with a commute gap: weak or infrequent ÖPNV (public transport), or long walks or transfers to the nearest Regionalbahn (regional rail) station, especially on early or late shifts.
Overlay your PLZ clusters with current ÖPNV service frequency and access times. Then down-weight or exclude employees who already have strong direct ÖPNV access [5]. If the network is thin, the shuttle has a clear case. If service is already strong, those employees should come out of your demand estimate, or at least carry less weight.
Next, test these PLZ clusters against shift timing and stated preference to estimate likely boardings.
This is general information, not legal or tax advice.
Now it’s time to pressure-test those PLZ clusters against shift windows and stated preference, so you can turn catchment into likely riders.
Start by grouping your shift roster into departure waves. Then count how many employees from each PLZ cluster need to arrive within each window [2][1]. That gives you a demand curve by departure time, which you can map straight to seat demand per run.
From there, translate each departure window into seats needed and flag runs that are likely to be underfilled or overcrowded. The share of seats filled on each run is your load factor. Also track Leerfahrten (empty runs): scheduled departures with too few boardings to justify the vehicle [4].
Shift timing shows you when seats are needed. Survey responses show you how many of those seats are likely to be used.
A short stated preference survey helps you estimate who would ride under a specific offer. Keep the questions concrete and scenario-based. For example:
The answers help you apply a more realistic expected boarding rate instead of assuming everyone in the catchment will use the service.
As a rough illustrative reference, expected boarding rates vary by mode type [3]:
| Mode type | Illustrative default capture rate |
|---|---|
| Standard bus | 6% |
| Bus Rapid Transit (BRT) | 12% |
| Light Rail Transit (LRT) | 15% |
| Metro | 20% |
(Source: Arterials [3]. These are general benchmarks for corridor planning, not guaranteed outcomes for any specific shuttle.)
Uptake changes with the offer, not just the map. That’s why it makes sense to run the model with the expected boarding rate shifted by ±20% to 30%, so you get a ridership band instead of one hard number [3].
Use that uptake band as the input for your launch scenarios.
This is general information, not legal or tax advice.
Use the uptake band to compare today’s commute pattern with shuttle scenarios using the same metrics.
Start with the current commute setup. Pull in badge data, parking use, and observed car or ride-hail trips. Then test different stop patterns, departure times, vehicle sizes, and eligibility rules. Each scenario should connect back to your PLZ clusters, shift windows, and stated-preference uptake. That keeps the comparison tied to the data that answers the main question: will people actually use it?
The table below is an illustrative comparison.
| Metric | Shuttle Scenario A | Shuttle Scenario B |
|---|---|---|
| Average load factor | Too weak to launch | Healthy load-factor range |
| Cost per boarded rider | Higher | Lower as pooling improves |
| Estimated Scope 3 Category 7 impact | Reduced versus baseline | Reduced further versus baseline |
Use your sourced load-factor range and launch threshold to decide if a scenario makes sense. The thresholds of 60% to 80% for a healthy peak, a minimum of 10% vehicle-hour reduction, and an average of 2.0 riders per vehicle or more are illustrative starting points only [1][6].
If none of the scenarios clears your launch threshold, do not launch yet.
triply runs this pre-launch comparison from the same PLZ, shift, and uptake inputs, so finance, operations, and sustainability all work from one model.
A shuttle ridership forecast does not need to be perfect. It needs to be good enough to show whether a route is worth launching, what load factor you can expect, and how much downside you can live with.
You get there by defining your use case, gathering the minimum data, mapping demand, lining it up with shift windows, checking it against stated preferences, and comparing scenarios before you spend.
Book a triply demo to get a site-specific shuttle ridership forecast from your actual commute data.
This is general information, not legal or tax advice.
A shuttle ridership forecast before launch is a probabilistic estimate, not an exact prediction. You won’t know rider numbers with certainty. But you can cut risk with data-driven, range-based modelling instead of wishful assumptions.
HR shift rosters, badge-in baselines, and commute patterns can help you build demand estimates that are far more grounded. The key is to treat those inputs as demand ceilings, not guaranteed usage, and to leave room for swings in rider behaviour with capacity buffers.
This is general information, not legal or tax advice.
Low survey response rates are common in shuttle ridership forecasting. So if you want your shuttle ridership forecast to hold up, don’t lean on stated preferences alone.
Instead, pair survey feedback with objective signals like HR shift rosters, badge-in access data, parking use, and any relevant past boarding or corridor data.
That way, surveys support the forecast instead of driving the whole thing. More importantly, the forecast stays tied to actual attendance patterns, not just what people say they might do.
This is general information only, not legal or tax advice.
You should hold off on launching your shuttle if you still don’t have a reliable, data-led view of how people actually commute. That means knowing where employees are coming from, where they’re going, and when their shifts start and end. If you skip that step, it often leads to routes that don’t work well, low vehicle use, or a service that misses the mark - and fixing that later can get expensive.
It also makes sense to delay if your pilot design is too rigid. Early sign-up data can be misleading. Sometimes people join because the idea feels new, not because they’ll keep using it over time. So your first route plan should be treated as a testable hypothesis, not a fixed commitment.
This is general information, not legal or tax advice.
