Seven Features to Help Transportation Teams Meet IEP Demands

Student transportation — and how transportation departments are expected to meet students’ needs — is constantly changing. One of those changes is a higher demand for, and the increasingly complex nature of, Individual Educational Plans (IEPs) for any given student. Not everything in an IEP plan affects transportation, but when it does, it can drastically affect your routing plan. Capturing the level of nuance required to carry out those IEPs in a district’s routing software can be a challenge. Because of this, it’s important to make sure your student transportation software includes these seven key features.

1. Equipment – It’s not just wheelchairs and safety vests anymore. An IEP could call for anything from air conditioning or a one-on-one aide to a booster seat or tinted windows. You should be able to store these requirements in the vehicle files and student files, and use them for routing. The fields should be customizable and, most importantly, they should automate and warn you of conflicts.
2. Reducing human error – Software should be able to reflect your knowledge, experience, and guidelines, serving as a partner in everything you do for your students. Color-coding and map icons are helpful tools, but they shouldn’t be the only thing standing between a student and an unsafe assignment. Student safety should be accounted for on the map (e.g., walk/cross restrictions) or through global rules (e.g., right-side pickup at the curb). Students’ needs shouldn’t have to be micromanaged through individual bus stop rules and a router’s attention to detail. You route students, after all, not bus stops.
3. Specialized stop times – One student needs a later pickup because she takes medication in the morning, and another has to stay after school for a special program. These IEP needs are non-negotiable, so your software should be flexible enough to account for them. Can you add extra sit time for your driver, ad hoc, at a school? Can you add extra load time for a particular student, a set of students, or for a piece of equipment like a wheelchair? Does that load time follow the student wherever you stop for them, or do you need to add it manually for each of their stops? Can you have students with certain needs leave earlier or later than the regular bell time? The software should think the way you do, and always with the ability to override those rules when needed.
4. Flexibility – Students can have different needs from one day to the next. For example, many students need to ride to different schools or addresses on different days or weeks. If you have to create duplicate student records to “trick” the software into complying with these nuances, that’s less than ideal. Think of how that affects reporting — especially state reporting. Routing software should reflect reality, including day/week variance for your students.
5. What-if scenarios – Testing out potential situations — from changing students’ bus stops to adjusting bell times — should be possible without creating another database or impacting your day-to-day routing plans. Likewise, it shouldn’t be necessary to separate students with special needs in their own database to route them appropriately. All students should exist in the same system, and the software should be flexible enough to run what-if scenarios for any subset that doesn’t affect the current operation.
6. Routing out of boundary – Students with special needs are often more likely to attend a school outside of their default enrollment boundary. When changing a student’s school from the norm, your software should maintain that entry — even if the student’s file is reimported. 
7. Shuttles and transfers – As part of some IEPs, students may need a mid-day shuttle to another school building for a special learning program. Then they may need a shuttle back or a ride home from that secondary school. Or they may need to transfer back onto their default run. In any situation, the software should not only track these complex scenarios — it should automate them.