Run a pre-budget shuttle feasibility study: map employee origins, test routes, model ridership, and calculate cost per boarded rider.
Don’t approve €100,000+ for a shuttle until you know who would use it, which routes could work, and what each boarded rider would cost.
Treat a shuttle feasibility study as a pre-budget test. In simple terms, it checks four things first: employee demand, route fit, ridership scenarios, and cost per boarded rider. If those numbers don’t work, the shuttle may not be the right move.
Here’s the short version:
A simple rule helps here: cheap per employee is not the same as cheap per rider. A public transport subsidy can look low-cost on paper, but if few people can use it, the cost per actual user may climb fast.
In many firms, a small set of commute data is enough to test the case before any budget is signed off. That means you can move from guesswork to a clear go / no-go view without a long survey or a long planning cycle.
| What to test | What to look at | Why it matters |
|---|---|---|
| Demand | Employee postal code clusters, shift windows | Shows whether enough people could use the service |
| Route fit | Site catchments, stop layout, trip distance in km | Shows whether a route makes sense on the map |
| Ridership | Low, base, high uptake cases | Shows seat use and route pressure |
| Cost | Total spend and cost per boarded rider | Shows whether the shuttle fits the budget case |
| Other options | ÖPNV support, carpooling, parking, shift changes | Shows whether a shuttle beats the alternatives |
| Reporting use | Scope 3 Category 7 data structure | Keeps finance, site teams, and reporting on one data base |
If preparing a budget case, you’d want one clean dataset and one shared model before asking for annual spend. That is the point of the study: test first, commit later.
In corporate mobility analytics, a shuttle feasibility study is a pre-investment model that checks whether an employee shuttle is worth funding. It looks at employee commuting patterns and site access needs, and it can also support Scope 3 Category 7 reporting by giving commute data a clear structure.
This study sits between spotting a commuting problem and committing operating budget to a fix. Run it before you get into detailed operating decisions, because its job is simple: tell you whether the next step is worth taking.
That’s why the next move isn’t to collect every data point under the sun. It’s to gather only the minimum commute data needed to test the case.
A completed shuttle feasibility study helps you answer four practical questions:
What it does not do is give you final operating cost or actual post-launch uptake. That comes later.
Its role is narrower, but still very important. It tells you whether the shuttle deserves deeper analysis, based on minimum data, route modelling, ridership scenarios, and cost per boarded rider. If the case looks solid, you can then move into route modelling and ridership estimates.
Once the decision frame is clear, gather only the minimum data needed to test demand and route fit.
With the decision frame in place, the next step is simple: gather only the commute data you need to test demand and route fit.
You don't need a full employee survey for this. In most cases, the HR and site data you already have is enough to get started.
Four inputs do most of the heavy lifting in the model:
Once you have PLZ data, group it into origin clusters. These are areas where enough employees live close to one another to make a shared route worth testing.
The main idea is pretty practical: if enough people live within a realistic catchment, that cluster is worth modelling. If they don't, the route may fall apart before it even starts.
Catchment size depends on the site and the shift setup. There's no magic number. What matters is setting a boundary that reflects how far people can realistically travel to reach the shuttle.
Shift patterns matter here too. Treat each start and end window as its own demand case. One time window can look strong, while another may need a different route or service pattern.
The same dataset you use for route modelling can also support budget checks and employee commuting emissions analysis. Build this on purpose. Otherwise, finance, operations, and sustainability teams often end up working from different data extracts and produce numbers that don't match.
A single, clean commute dataset built from PLZ data and shift records gives all three teams the same starting point. Finance can use it to estimate cost per boarded rider. Operations can use it to test service patterns. And because it includes commute distances and estimated modes, it also gives you the structure needed for Scope 3 Category 7 emissions modelling.
Use this base dataset to model candidate routes and service patterns next.
Once your shared commute dataset is ready, the next step is route testing. This is where demand mapping turns into something you can actually compare.
Start with your origin clusters and site catchments. Then sketch the simplest route that reaches the biggest concentration of employees. At this point, the goal is to test whether a route can work, not to lock in the final shuttle design.
For each route option, define:
That gives you one clean framework for comparing options side by side. If one route has more stops, a longer path, or serves different shifts, you can see those trade-offs without mixing methods.
Next, estimate how many employees in each catchment are likely to board the shuttle. Build that model around three inputs: origin clusters, shift timing, and current commute mode.
Then create low, base, and high scenarios by changing the capture rate. Think of it as a simple stress test:
From there, estimate boarded riders per trip and check the load factor. Load factor is the share of seats filled on a trip. Define it early, and use that same definition across every scenario. If you change the rule halfway through, the comparison falls apart.
Why does this matter? Because load factor shows whether a route is filling enough seats to justify deeper modelling.
When you calculate operating cost, stick to the same method for every route option. That way, cost per boarded rider stays comparable across routes and scenarios.
Cost per boarded rider gives finance and operations one simple number to work with. It helps you test route shape, load factor, and cost assumptions before any budget is committed.
Use those outputs to compare the shuttle with other commute measures in one decision framework.
A shuttle is one option in a pre-budget commute test. It shouldn't be treated as a standalone choice.
In most cases, the shuttle is up against other commute measures. So the smart move is simple: compare every option with one shared framework. That framework is the next step.
Use the same core metrics for every option:
One thing trips teams up all the time: cheap per employee is not the same as cheap per boarded rider.
Public transport (ÖPNV, publicly operated bus and rail services) incentives can look low-cost at first glance. But if local network access is weak, cost per boarded rider can climb fast. That's where the model needs to do the heavy lifting. It should show whether the shuttle beats the other options on cost per boarded rider and coverage.
Use the table below to compare options side by side. Treat it as a working template, then swap the labels for your own model outputs.
| Measure | Cost per boarded rider | Load factor relevance | Employee coverage | Scope 3 Category 7 impact | Complexity to implement |
|---|---|---|---|---|---|
| Dedicated shuttle route | Depends on ridership and route length | High | Limited to catchment area | High reduction potential if uptake is strong | Medium to high |
| Public transport (ÖPNV) incentive | Lower unit cost where network exists | Not applicable | Broad, but only where ÖPNV is accessible | Moderate, depends on modal shift | Low to medium |
| Carpooling programme | Low unit cost | Not applicable | Broad, shift-dependent | Moderate reduction potential | Low |
| Parking policy change | Low direct transport cost | Not applicable | Site-wide | Indirect effect via modal shift | Low to medium |
| Shift-timing adjustment | No direct transport cost | Not applicable | Site-wide | Indirect effect via mode and distance | Medium |
Once the comparison is done, turn the model into a recommendation that each team can use from the same dataset.
Give Finance the cost view and annual outlay. Give Operations the coverage picture and service needs. Give HR the employee reach. Give Sustainability the Scope 3 Category 7 impact.
Then be direct. Say where the shuttle looks viable, where another measure does better on your key metrics, and what should happen next, whether that's a pilot, a deeper data collection phase, or a decision to back a different measure entirely.
triply's employee shuttle optimisation analytics models the shuttle alongside other measures on one commute dataset before you approve budget.
A shuttle feasibility study helps you avoid paying for a shuttle before demand, routes, and cost per boarded rider are clear. Put simply, it gives you a go/no-go answer before you spend money.
If you want the shortest path to a decision you can defend, follow these four steps. First, map employee origins and site catchments. Next, model candidate routes and service patterns. Then build low, base, and high ridership scenarios. Finally, calculate cost per boarded rider.
From there, compare the shuttle with other commute measures in one shared framework so finance, operations, sustainability, and site leadership are all looking at the same results.
When you want to test the approach on your own data, triply can show the workflow end to end. triply's employee shuttle optimisation analytics models commute demand, simulates routes, and costs measures side by side before you commit budget. Book a demo to see triply model routes and compare measures before budget approval.
This article is general information only, not legal or tax advice.
Last updated: 22 July 2026
Written by the triply team, corporate mobility analytics specialists serving large employers across the globe.
You only need a small set of commute data to begin a shuttle feasibility study. The aim is simple: collect enough detail to model possible routes, estimate ridership, and work out cost per boarded rider.
This is the low-cost first step that helps you avoid committing budget before you know whether a shuttle is likely to work.
Run a shuttle feasibility study before you commit budget. It’s the low-cost step that helps you avoid an expensive mistake.
You use it to gather the minimum commute data you need, model possible routes, estimate ridership and cost per boarded rider, and compare the outcome with other options before you move forward.
A shuttle route makes sense when likely ridership, route design, and operating cost line up well enough to justify the service.
In a shuttle feasibility study, you look at expected demand, test possible routes, estimate cost per boarded rider, and compare that figure with other options before committing budget.
