Transport Management for Multi-Campus Groups

It's a federated topology, not a centralised one. Each campus transport coordinator owns their routes, stops, drivers, and exception handling day-to-day — exactly as they would in a standalone deployment. The group transport director sets policy guardrails (max ride time, vehicle-pool sharing thresholds, vendor approval rules, compliance SLAs) and gets read-everywhere visibility plus escalation alerts. Campuses can't drift out of group policy, but they aren't waiting on the group office to approve a route change either. This is the same federated pattern most group CIOs already run for SIS, identity, and finance — transport just joins it.

The platform models shuttle legs separately from vehicles. The same physical bus running a Campus A to Campus B loop can have a 'staff-only' leg with no minor-safeguarding rules and a 'student-eligible' leg with full safeguarding, background-checked drivers, and parent notifications. Insurance class, supervisor requirements, and ride manifests adjust per leg. Most group operators run staff shuttles during the academic day (faculty rotations, shared-services trips between campuses) and student-eligible shuttles around class change times, athletics events, and dual-enrolment transfers.

The group transport director sets the pool policy: which vehicles are pool-eligible (typically standard buses and vans, not bespoke accessibility vehicles permanently assigned to a specific student), maximum deadhead distance for re-allocation, driver-hours-of-service limits, and priority order when two campuses request the same vehicle. The platform then re-allocates automatically based on telematics state, route schedules, and policy. Campuses can mark vehicles as 'protected' for specific windows (a Campus A inspection day, a Campus B field-trip block) to override pooling temporarily. NAPT's large-district operational guidance is the reference model for these sharing rules.

Cost-per-rider only means something when the cost inputs are normalised across campuses. The platform pulls fuel from telematics, driver wages from payroll, maintenance from work orders, vehicle depreciation from the asset register, and overhead allocation from the chart of accounts — at the campus level — then divides by boarding events sourced from rider scans. Output is cost-per-rider, cost-per-route-mile, and cost-per-vehicle-hour, sliceable by campus, by route type (fixed-route, on-demand, inter-campus, accessibility), and by time band. Finance gets a defensible number; the group transport director gets benchmarking that surfaces the well-run campuses and the struggling ones.

Group transport directors typically track five things across the network: cost-per-rider variance between campuses (a flag for operational efficiency drift), inter-campus shuttle utilisation (is the leg earning its operating cost), accessibility-vehicle deployment rates (a compliance and equity signal), driver-hours utilisation by campus (over-staffed sites vs over-stretched ones), and on-time performance by route. The platform exposes all five as group-level dashboards with per-campus drill-down. APTA's shared-fleet operational metrics are the closest external benchmark; campus chains can compare themselves against small municipal transit agency norms.

Separately, you get six things that don't work: vehicle pooling, inter-campus shuttles, federated admin, group-level cost reporting, a single parent app, and consolidated compliance auditing. Each campus runs in isolation, finance has to manually reconcile six (or sixty) cost reports, and a family with kids at three campuses logs into three apps. The group deployment is built around the assumption that transport is a network problem, not a site problem — the operational topology, data model, and identity layer all reflect that. Groups that try to bolt group-level reporting on top of per-campus deployments typically rebuild it inside two years.