Transport Management for Colleges Built Around Shuttle Loops, Not Parent Pickup

K-12 transport is a one-pickup-per-student model centered on a parent: a child is collected from a home stop at a fixed minute, a parent receives the arrival notification, and the roster is checked by the driver against a paper sheet. College transport is the opposite. Riders are adults with their own student ID, they board a frequency-based shuttle loop or an inter-campus route rather than a personal pickup, the institution has no contract with a parent, and the app is built for the rider's own phone. Trying to model college shuttle in a K-12 routing tool ends in a parent portal nobody opens and a roster check nobody runs.

Yes, and the loop is the default mode rather than a workaround. A loop is defined as an ordered list of stops, a headway (the minutes between consecutive buses on the same loop), a service span (the first and last departure of the day), and the vehicle and driver count needed to maintain the headway across peaks and tails. The student app shows the published headway, the next-bus estimate from live GPS, and a service-span warning before the last loop of the night. Operators tune the headway down during class-change windows and up during low-demand hours without rebuilding the route from scratch.

Yes. Inter-campus transit is modelled as a scheduled route with named departure times and timed transfers, not a loop, because the use case is finishing a class at one site and reaching a class at another site by a specific minute. The system reads the class timetable on both ends, sets departures aligned to class-change windows, and applies a missed-connection rule that either holds the receiving bus for a short grace window or alerts dispatch. Community colleges with a main campus plus one or two satellite sites use this layer routinely; the same logic also covers a residential undergraduate college that runs a downtown clinical-rotation shuttle.

The transport roster is derived from the student information system rather than maintained as a separate list. Enrolled students inherit a base transport eligibility (the loops included in tuition or covered by a transport fee), residential students automatically gain the dorm-feeder loops their hall is assigned to, and any opt-in fee-paid routes are added per student. Boarding scans authenticate against this roster in real time. When a student changes hall mid-semester or drops a course, the transport eligibility updates overnight, so the boarding scan reflects the new state without manual driver-roster intervention.

The system supports ADA Title II compliance for public colleges and ADA Title III for private colleges, with the substantive standard set by 49 CFR Part 37 (US DOT). Every fixed shuttle loop is mapped against an accessible-vehicle commitment: either every vehicle on the loop is wheelchair accessible, or an equivalent paratransit service is offered with comparable hours, response time, and fare. Wheelchair-securement positions are tracked per vehicle, driver securement training is recorded, and the request-a-ride function in the student app routes accessible-shuttle pickup requests to dispatch with the response-time clock running. The audit report exports the data the institution's ADA coordinator or a US Department of Education OCR reviewer typically asks for.

Both models are supported. If transport is bundled into tuition or a mandatory student services fee, the transport eligibility is asserted on every enrolled student and no separate billing event fires. If transport is an opt-in fee or a per-route subscription (common at community colleges with a separate transportation district contract), the student elects the route in self-service, the fee posts to the student account through the existing finance module, and the boarding scan denies access until payment clears. Mixed models work too: a base on-campus loop included in tuition, with an opt-in inter-campus subscription on top.