When riders think about transit they think about buses, trains, operators, and schedules. When transit agencies think about service they often think about reliability, frequency, and on-time performance. But underneath every trip is another network that riders never see: dozens of applications, vendors, databases, dispatch systems, payment platforms, scheduling tools, customer information systems, accessibility tools, and vehicle technologies that all have to work together to deliver a single journey.
When they don't, the effects can ripple through every part of the service.
- Frontline staff create workarounds
- Operations slow down
- Riders lose confidence
- Service becomes harder (and more expensive) to deliver
This is one of the least discussed challenges facing transit agencies today.
Transit Has Become a Technology Ecosystem
Modern transit isn't powered by a single system. A rider planning a trip might interact with trip planning software, real-time arrival predictions, fare payment, customer accounts, service alerts, accessibility features, and customer support all before stepping onto a vehicle.
Behind the scenes dispatchers, operators, and supervisors depend on an equally complex ecosystem of scheduling software, dispatch tools, real-time feeds, vendor platforms, reporting systems, and operational dashboards.
Each application may perform its own job well but the challenge is that transit service depends on how well they work together.
When Systems Don't Talk, People Do
During a technology discovery effort for the MBTA's paratransit service, The RIDE, our team expected to identify usability issues and opportunities for modernization. Instead, we found that the technology ecosystem wasn't struggling because individual applications were broken, it was struggling because they weren't connected.
- Reservationists manually calculated fare balances because one system couldn't retrieve information from another
- Team members copied trip information between vendor platforms because dispatch workflows weren't integrated
- Scheduling staff downloaded CSV files, manipulated them by hand, and rebuilt operational plans every night because systems couldn't exchange information directly
- Quality assurance staff reconciled thousands of trips against paper manifests because no single source of truth existed
Riders Experience the Same Fragmentation
In the paratransit example the disconnection also reached riders in the following ways:
- Customers couldn't add a new destination while booking because address management lived outside the reservation workflow
- Real-time vehicle information existed but wasn't connected to customer-facing tools, leaving riders uncertain about when their vehicle would arrive
- A rider using a screen reader couldn't independently complete a booking because accessibility had been treated as a property of one application instead of an end-to-end service
For riders none of these felt like technology failures to riders, they felt like unreliable transit. This reinforced that every disconnected workflow eventually becomes part of the rider experience.
This Is More Than a Customer Experience Problem
It's tempting to frame these issues as UX or CX problems, but they're not. They are operational problems where every workaround increases labor costs, every manual reconciliation introduces opportunities for error, every disconnected workflow slows decision-making and every missing integration limits an agency's ability to improve service.
Over time, organizations become experts at working around technology instead of improving it and the cost isn't only inefficiency, it's organizational capacity. When transit agency staff spend their time compensating for disconnected systems, they have less time to improve reliability, respond to riders, optimize service, or innovate.
Designing Transit Means Designing the Technology Ecosystem
One lesson from this work continues to shape how I think about transit technology. We often evaluate applications individually but riders never do, they experience the entire ecosystem.
The goal for transit technology can't simply be "modern software". It needs to be technology that allows information to move as seamlessly as riders expect their journey to. For transit agencies, investing in technology isn't just about replacing legacy applications, it's about designing an operational ecosystem that supports frontline staff, strengthens service delivery, and builds rider trust.
Where Do You Start?
One question I often get is, "How do you know which systems to integrate first?" My answer is: don't start with the technology, start with the service.
Technology ecosystems become fragmented because organizations implement systems to solve individual business problems over time. Procurement happens project by project, vendors optimize for their own products, and departments optimize for their own workflows. Eventually, no one is designing the service across those systems.
This is where service design approaches become invaluable. Rather than beginning with an application inventory or integration roadmap, I start by understanding how the service is actually delivered by:
- Mapping the end-to-end customer journey
- Observing frontline staff doing their work
- Document where information is created, where it moves, where it stops
- Identifying where people have developed workarounds to bridge gaps between systems
Service blueprints, journey maps, and jobs-to-be-done become more than research artifacts, they become tools for understanding how information should flow through an organization.
The goal isn't to connect every system, it's to identify the moments where disconnected information creates unnecessary effort for employees or uncertainty for riders. Those moments become your highest-value integration opportunities.
Sometimes the answer is a new API, sometimes it's exposing existing data to another application, sometimes it's redesigning a workflow, and sometimes it's eliminating a system altogether. But, the technology solution is rarely the starting point, the service is.
When agencies understand the jobs that riders, dispatchers, operators, and supervisors are trying to accomplish, technology investments become much easier to prioritize. Instead of asking, "Which systems should we replace?" the question becomes, "Where does information need to flow so people can do their jobs and riders can trust the service?"
I believe that the future of transit technology is not building more systems, but designing better-connected services.
