When Mandated Transit Software Doesn't Fit the Operation

Talked to a paratransit provider last month running scheduling software they didn't pick.

Their funder mandated it. Makes sense from the funder's side. You can't have five contracted providers all running different back-end systems and expect a consistent customer experience + reporting across the network. Standardization is the right call at that level.

Problem is, the software was built for a slightly but measurably different kind of operation than the one actually running it. So after the official training was complete, the team had to build their own version of "how we actually use the software IRL."

A spreadsheet that catches what the system doesn't. A procedure to handle an automated no-show when the passenger is present, just having a bad mobility day and needing an extra few seconds. A second phone that handles what the intake screen can't. A person who just knows how the real schedule works, separate from what's on screen. Basically an operational layer that lives somewhere between the scheduling software manual, local operating policy, and common sense.

Nobody's wrong here. The funder needs one system to see across the whole network. The software vendor is judged on the service as a whole, and accounting for edge cases without degrading the algorithms gets complicated fast. But the provider needs the day-to-day to actually work.

These gaps show up as finger pointing, frustration, and passenger complaints.

That's what we go looking for. And what we fix.

Sound familiar? Let's talk. Link in comments.