Use site-level commute data, not group targets: model baselines, test shuttles, PT, carpooling and schedule changes to cut emissions.
If you want lower commute emissions at a plant, don’t start with a group target. Start with site data. In this article, we boil the job down to four steps: set a baseline, test measures before spending, compare cost and uptake, and check forecast vs actual results. That matters because one plant may support a shuttle for a 06:00 shift, while another may get more from bus subsidies or carpooling.
Here’s the core idea in plain terms:
A few facts stand out. The baseline can start with just four fields: home postal code, shift pattern, site assignment, and on-site days. The article also splits sites into 4 plant types and focuses on 4 measure types, which gives me a simple filter before I spend any money.
| Area | What to check first | Why it matters |
|---|---|---|
| Baseline | Postal codes, shifts, site, on-site days | Shows the current commute pattern |
| Site fit | Urban, suburban, rural, or cluster | Cuts out weak options early |
| Measures | Shuttle, PT incentive, carpooling, schedule change | Shows likely uptake and cost |
| Impact | Baseline vs modelled vs observed | Checks if the plan worked |
Once you’ve set the baseline, the next step is to adjust it to match how each plant works in practice. That’s where manufacturing commute planning starts to split from standard office-style planning.
Plants run on shifts. Employees often live across a broad area. And many sites sit outside dense public transport networks. Put all that together, and the inputs, the model, and the business case all start to look different.
Build the commute model around the shift pattern. That matters because early, late, night, and rotating shifts can change which transport options are even usable.
A bus link that works fine for a day shift may be useless for a 06:00 start. The same goes for night shifts, when public transport service is often thin or unavailable.
Plant mobility also needs site-specific inputs. Shift timing and the spread of the commuter catchment directly affect which options people can use. If the workforce is spread across a large area, a one-size-fits-all plan usually falls flat.
The right mobility mix depends on three things:
| Site type | Public transport access | Typical shift structure | Priority measures |
|---|---|---|---|
| Urban plant | Good | Standard or two-shift | Public transport support, cycling infrastructure, parking management |
| Suburban plant | Moderate | Two or more shifts | Shuttle feeders, carpooling coordination |
| Rural plant | Limited | Multiple shifts or continuous operation | Dedicated shuttle routes, carpooling schemes, parking management |
| Multi-site cluster | Mixed | Varies by plant | Shared shuttle corridors, site-level modelling across the cluster |
This filter helps you see which measures are worth modelling before budget approval. Rolling out the same measure across every site without checking local conditions is a good way to burn through budget with little return.
Use the site type to narrow the set of measures first. Then test only the options that match the geography and shift pattern. Those site differences should guide which measures you simulate next.
Once you’ve narrowed down the likely measures by site type, the next step is building a model that can stand up in a business case. That starts with the right inputs, not the longest list of inputs. A solid baseline gives you something you can test against before any budget gets locked in.
Start with four fields: home postal code, shift pattern, site assignment, and on-site days. That’s enough to map actual commute distances and begin testing measures straight away.
For multi-site manufacturers, one rolled-up model often hides the differences that matter most. You need the same fields, the same definitions, and the same distance method across sites. But local factors still need to stay visible, such as shift start times, contractor populations, and changing labour catchments.
This gives finance and sustainability one consistent dataset, while operations still get plant-level visibility.
Use one standard data structure to model actual commutes across all sites without losing local detail. That baseline then supports the measure tests in the next section.
This matters when the numbers feed investment approval or Scope 3 Category 7 reporting. Put simply, the data source shapes what the model can safely support.
| Data approach | Coverage | Consistency | Decision support | Best used for |
|---|---|---|---|---|
| Survey-based data | Full workforce coverage | Variable | High detail, limited coverage | Validating model assumptions, capturing edge cases |
| Proxy-based data | Full workforce coverage | High, when inputs are standardised | Good for baseline modelling and site-level visibility | Multi-site baselines when survey data is unavailable |
| Modelled commute data | Full workforce coverage | High, consistent across sites | Strong for simulation and reporting | Pre-investment measure testing, Scope 3 Category 7 reporting |
A practical setup is simple:
Once you have a solid baseline, you can stop guessing and start testing. That’s the point. Before you put money behind a mobility measure, run it through your commute model first. That gives you a clearer view of likely cost, uptake, load factor, and emissions impact before spend.
Shuttle services are often a practical starting point for rural or peri-urban plants where public transport is limited. Whether a shuttle works usually comes down to route alignment and load factor. If you model the route against your actual workforce postal codes before launch, you can see if demand is strong enough.
Public transport incentives tend to work best where rail or bus access already exists, but price is the main barrier. Your model should test who can use scheduled public transport based on shift pattern and stop access. That difference matters, especially for rotating shifts.
Carpooling schemes can work well in manufacturing. They fit sites where employees come from shared catchments and start at similar times. A modelled carpooling scenario can show the likely emissions reduction and the drop in parking demand before you pay for extra tooling or incentives.
Flexible scheduling adjustments, such as moving a shift start time, can open up public transport access for some employees without any new transport spend. The best way to judge that is to model it against real commute data.
The table below shows what each measure changes in the model and the decision it helps you make.
| Measure | What changes in the model | Inputs required | Decision it supports |
|---|---|---|---|
| Shuttle service | Route coverage, load factor, cost per boarded rider, Scope 3 Category 7 reduction | Workforce postal codes, shift start times, proposed route and frequency | Go or no-go on route; best departure times; cost per rider versus car use |
| Public transport incentive | Modal shift rate, Scope 3 Category 7 reduction, net subsidy cost | Postal code-to-stop proximity, shift patterns, current modal split | Subsidy level; which sites benefit most; expected uptake by shift group |
| Carpooling scheme | Vehicle kilometres reduced, Scope 3 Category 7 reduction, parking demand | Workforce postal codes, shift patterns, current solo-driver share | Emissions reduction potential; parking pressure relief; incentive design |
| Flexible scheduling | Public transport accessibility rate, modal shift potential | Shift start times, public transport timetables, workforce postal codes | Which shift adjustments unlock the most modal shift at the lowest operational cost |
Use scenarios to rule out weak measures and build a stronger business case for the ones that hold up. The next step is to compare simulated results with actual uptake, cost, and emissions data.
After you test a measure on paper, the next step is simple: compare the forecast with what happened in practice, broken down by site and shift group.
Once a measure is live, the same plant-level model should show whether it delivered the expected uptake, cost change, and emissions change by site and shift group. For operations and finance, that means projected uptake by site and shift group, along with the expected cost effect. For sustainability teams, the same baseline supports Scope 3 Category 7 reporting under CSRD and ESRS E1, with a clear link back to each site. One dataset keeps forecast and actual results aligned.
Label every figure as observed or proxy-based. That line matters when finance or an auditor asks how a number was produced.
Once a measure goes live, track three points. Keep the same setup for every site so you can compare forecast, rollout, and outcome without changing the method.
| Stage | What it captures | Primary use |
|---|---|---|
| Baseline | Current commuting pattern and Scope 3 Category 7 baseline | Reference point for comparison |
| Simulated impact | Projected uptake, cost impact, and Scope 3 Category 7 change | Predicted outcome |
| Observed results | Actual uptake, cost impact, and Scope 3 Category 7 change | Actual outcome and model check |
This comparison only works if the baseline, the scenario, and the live result stay in the same frame. When you compare simulated and observed results, you can see which assumptions need work. If uptake comes in lower than projected, that gap usually points to an assumption that should be adjusted.
Track baseline, forecast, and actuals in one model, then use the results to decide what should scale next. Model the baseline, simulate the measure, compare the outcome, and use the gap to guide the next investment.
triply is built for this sequence: model real commutes from postal codes and shift data, simulate measures before investment, and produce audit-ready Scope 3 Category 7 outputs from the same underlying model. Book a demo to test it against your own sites and shift patterns with actual data.
