Plan shuttles from employee postcodes and shifts—compare network scenarios, cost per rider, and auditable Scope 3 Category 7 emissions.
One rule sorts most of this: pick planning software if you still need to design the shuttle network, and pick dispatch software only if the network already exists.
For employer shuttles, four things matter first:
This guide compares four groups of software:
The split behind them is simple. Planning tools help you decide whether a route should exist. Dispatch tools help you run trips after launch. Route solvers help you improve routes once the stops are fixed.
A live tracking tool will not tell you if a network is wrong at the start. A planning tool will not run driver comms or handle a breakdown on the day. So the first question is which job you are buying for.
| Software group | Best use | Main input | Best output | Weak point |
|---|---|---|---|---|
| triply | Pre-launch and existing shuttle planning and optimisation | Postcodes, shifts, mode data | Cost, coverage, load factor, Scope 3 Cat. 7 | No live dispatch |
| Commute-modelling platforms | Broad commute and modal-shift strategy | HRIS and shift data | Demand maps, modal shift, cost and emissions estimates | Less shuttle-route depth |
| Dispatch-first shuttle tools | Running service day to day | Rosters, templates, exceptions | Live trip control, rider data, day-of changes | Weak for pre-launch design |
| Generic route optimisation | Improving fixed-stop routes | Stops, time windows, fleet rules | Stop order, vehicle assignment, distance and time cuts | Does not map demand from employee homes |
Before you compare features, five questions separate real planning software from everything else:
That is the core of this guide. Now to each group.
triply is a planning platform for employee transport, built for shuttle networks and employee mobility. You model real commute patterns, test network options, and estimate cost and emissions before you commit to a route or spend money. It turns workforce data into route decisions you can defend.
How it models demand. You start with company sites and anonymised employee postal codes, then add shift times and preferred travel modes. That models demand without surveying every employee. Geo-clustering groups that demand into stop locations, route alignments, and service frequencies based on where people live. You can hold it to real-world limits: a maximum 500m walk to a stop, and shuttle travel time no more than 25% above the equivalent car journey.
Scenario comparison. With the base model built, you can test what-if scenarios immediately. If a route has weak occupancy, merge it with another or cut the near-empty trips. Each change updates coverage, load factor, and cost, so you compare service level, cost, and coverage side by side before anything changes in the field.
Cost and emissions. Every scenario projects cost and emissions, including Scope 3 Category 7. One modelling run supports both the investment decision and CSRD and ESRS E1 reporting, and flags the hotspots where CO2 is highest.
Where it fits. triply sits before daily operations. It gives finance, HR, and sustainability teams the evidence to approve a network or reshape an existing one. Rerun the model as headcount or shift patterns change, and use it to keep independent oversight of subcontracted shuttle providers. Use triply when you need planning evidence, not live trip control.
| Use stage | What triply does |
|---|---|
| Pre-investment | Models demand, compares route scenarios, projects cost and Scope 3 Category 7 |
| Network redesign | Identifies over- and under-served areas, merges or cuts routes by load factor |
| Ongoing optimisation | Remodels as workforce or shift patterns change, reviews KPIs over time |
| Third-party oversight | Provides an independent audit of subcontracted shuttle provider performance |
For a full overview, see triply's employee shuttle optimisation solution.
These platforms work the same planning layer as triply, but at a wider, strategic level. They map commute demand across every transport mode and estimate modal shift for a whole workforce or city. The trade-off is depth: they rarely go as far as shuttle-specific route simulation.
How they model demand. Start with employee home postcodes from your HRIS and shift rosters. Surveys drift over time; HRIS data stays current. Include badge-in cut-off times, security checks, and the last-mile walk to the workstation, or you will understate travel time.
Scenario comparison. Once demand is mapped, you can test network setups before spending. A good platform lets you change maximum walking distance, capacity, or the effect of hybrid schedules on occupancy, and shows how each change moves route count, load factor, and total cost. Keep pickup times stable, or adoption drops.
Cost and emissions. Each scenario should give you a business case: cost per boarded rider, vehicle count, and Scope 3 Category 7 emissions via the distance-based method. Finance and sustainability then review the same numbers from one run.
Where it fits. This is the decision layer for mobility strategy. Strong for modal-shift questions across the whole workforce, weaker when you need to design and simulate a specific shuttle network.
| Capability | What to expect |
|---|---|
| Data source | HRIS postcodes and shift rosters, not surveys |
| Scenario output | Load factor, cost per boarded rider, vehicle count |
| Emissions output | Scope 3 Category 7 via the distance-based method |
| Primary users | HR, finance, sustainability |
| Role in the process | Mobility strategy and modal-shift planning |
Dispatch-first tools take over after launch, when vehicles are already on the road. They connect to your HRIS, including Workday or SAP SuccessFactors, so rosters and eligibility update automatically. Most run on three inputs: service templates, roster overlays, and exceptions.
They work off badge-in deadlines, not just shift start times. If workers need extra time for security or the walk from drop-off to the workstation, the shift start alone will not tell you whether they make it. The badge-in deadline will. That is the input that keeps a live service honest.
Scenario comparison. These platforms are built for day-of what-if checks: a vehicle breaks down, or an overtime wave adds riders to a late shift. They are not built for pre-launch network design.
Cost and emissions. Because they record live rider-mile data, they report cost per boarded rider and Scope 3 Category 7 from actual operations. That is useful once service runs, but it will not build a pre-launch business case, because the network already has to exist.
Where it fits. Use dispatch-first tools for execution: day-of exceptions and vehicle positioning. Do not use them to decide whether to build or redesign a network.
| Capability | What to expect |
|---|---|
| Data source | HRIS rosters and home postcodes |
| Scenario output | Day-of what-if scenarios |
| Emissions output | Scope 3 Category 7 from live operations |
| Primary users | Operations teams |
| Role in the process | Execution and exception handling |
Once you know the stops, the job is putting them in the best order. Generic route optimisation software is a solver: feed it a set of fixed stops and time windows, and it works out the most efficient vehicle assignment and route sequence. It improves a plan that already exists. It does not design the network.
How it models demand. It does not, really. These solvers need fixed stops and set time windows. They sequence routes, respect shift end times, and stay within driver and vehicle limits, but they do not build demand from home postcodes. That is the gap if you are still deciding where service should run.
Scenario comparison. With stops fixed, you can test operational rules: capacity, load-factor caps, dwell times, fleet mix. Useful for fine-tuning, not for shaping the network.
Cost and emissions. Most solvers cut distance or time, which links to fuel spend and Scope 3 Category 7 in live operations. The weak spot is forecasting: they are not built to estimate cost or emissions before a vehicle moves, so they only take a pre-investment business case so far.
Where it fits. Strong for tightening an existing network, weak for deciding where routes should go or whether the numbers stack up. For that, you need a demand-first planning approach.
| Capability | What to expect |
|---|---|
| Data source | Pre-defined stops and time windows |
| Scenario output | Route variations on fixed stops |
| Emissions output | Distance-based Scope 3 Category 7 from operations |
| Primary users | Operations and logistics teams |
| Role in the process | Network refinement, not network design |
With the categories clear, a short set of buyer criteria separates real planning software from tools that only handle fixed routes or day-to-day operations.
| Buyer criterion | Why it matters | What weak software lacks |
|---|---|---|
| Turns HRIS postcodes and shift times into route options | Routes built from real employee origins serve actual demand, not guesswork | Starts from fixed stops with no link to where employees live |
| Compares route options before you commit budget | You can test load factor, cost per boarded rider, travel time, and emissions across designs | Produces one static schedule with no what-if capability |
| Produces shared business-case outputs for finance, sustainability, and HR | One data set covers cost, vehicle size, frequency, and rider-level metrics | Reports vehicle data, not rider-level metrics like cost per boarded rider |
| Outputs auditable Scope 3 Category 7 emissions | Under CSRD, many large employers must report Scope 3 Category 7 | Tracks fuel or basic mileage, not rider-level commuting emissions |
| Built for planning, not just dispatch | Pre-investment modelling lets you test before any vehicle moves | Focuses on live tracking and manifests with no forecasting |
One criterion deserves extra weight: auditable Scope 3 Category 7 data. If a tool cannot produce defensible numbers here, your sustainability reporting falls back to manual work, which means more spreadsheets, more reconciliation, and more room for error.
Planning comes first. Route choices should come from real employee home locations and shift schedules, not live operations data alone. For large employers, start with software that compares scenarios, cost, load factor, and Scope 3 Category 7 before any budget is locked in. Live tracking will not fix a weak network design. Once the network is set, dispatch and live tracking earn their place.
If you need to model employee commute data before committing to operations, use triply's employee shuttle optimisation solution.
How much employee data do I need?
Mainly basic details on where employees live and your current transport schedule, if you already have one. For more precise capacity and route planning, add preferred transport modes, work start and end times, and typical office attendance patterns. You do not need to track individuals; the modelling can use anonymised or statistical workforce data.
Can I use this before launching any shuttle?
Yes, and in most cases you should. In the pre-investment phase it lets you model commute patterns, compare scenarios, and estimate cost and CO2 before you commit money or resources. That gives you a clearer view of demand, helps you pick the right routes, and lines up your mobility strategy with both operational and sustainability goals.
How does Scope 3 Category 7 reporting fit in?
Scope 3 Category 7 covers emissions from employee commuting, a required disclosure line under rules such as the EU CSRD and California SB 253. Bus route planning software calculates these emissions from shuttle data using Greenhouse Gas Protocol methodology, so teams can move from manual collection to precise occupancy and trip data. That makes sustainability dashboards and compliance reports easier to support with numbers drawn from actual transport activity.
This is general information, not legal or tax advice.
