Managing Transit Technology the Way Riders Experience It

We track On-Time Performance, CSAT scores, Net Promoter Score, and custom service quality metrics. We run surveys on cleanliness, comfort, and staff behavior, and we analyze social media sentiment.

These metrics describe symptoms. They don’t diagnose causes. They don’t tell us where to invest. And they don’t measure whether anything we’ve done has actually changed how riders experience our system.

They’ll tell us riders are unhappy during disruptions, but they won’t tell us that the reason is five different systems failing to coordinate. They’ll show us complaint spikes after schedule changes, but they won’t reveal that the alert system and the trip planner are pulling from different data sources with different update cycles. OTP tells us the bus was late. NPS tells us riders are frustrated. Neither tells us why the technology investment our agency just made didn’t fix it. The problem isn’t that these metrics are useless. It’s that rider experience in transit is shaped by technology systems, operational decisions, and cross-departmental coordination.

We need to stop treating rider experience as a reporting exercise. If experience is shaped by systems and coordination, then improving it requires system-level diagnosis and cross-functional action. We need a structured methodology that links rider outcomes to operational and technology decisions — and a clear way to prioritize and sponsor the initiatives that will actually move the needle.

This article introduces that methodology.

A Story You'll Recognize

An agency deploys a $3.5M real-time prediction system. Vehicle locations update every 30 seconds. Predictions are accurate to within 90 seconds. The vendor delivers exactly what was specified.

Six months later, rider complaints about "missed buses" are higher than before the system launched.

The problem wasn't the predictions. The problem was that when service got disrupted, a daily occurrence at any major agency, the prediction system kept running. It told riders their bus was 4 minutes away right up until operations canceled the trip. The alert system that should have warned them lived on a different platform, managed by a different team, pulling from a different data source, with a different update cycle. By the time the alert was published, riders were already standing at the stop.

Both systems worked exactly as specified. The rider's actual job, reaching their destination reliably when service changes unexpectedly, completely failed.

If you're a transit leader, whether you own rider experience, technology, operations, customer experience, or strategic planning, this story probably sounds familiar. Not the technical details, but the pattern. A major investment goes in. Everyone declares success based on system performance. And the rider data tells a different story. You know something is broken, but the tools you have don't help you explain what or point to where to invest next.

Why Our Investments Keep Hitting a Wall

The prediction system didn’t fail because anyone made a bad decision. It failed because every decision was made inside a boundary that didn’t match how riders actually experience transit.

Transit agencies structure technology work around platforms and channels: the website team, the app team, the digital signage team, the data team, the customer service systems team. This makes practical sense. Large organizations need clear accountability, budgets aligned to deliverables, and staff with specialized expertise. Someone needs to own the website, maintain the fare gates, and publish the schedule data.

But riders don’t experience channels. They experience jobs: getting to a destination reliably, recovering from a disruption, knowing what to expect when plans change. When five systems all technically work but the experience still fails, no one is accountable for the outcome.

There’s a deeper structural problem underneath: major technology investments are procured through processes that optimize for features and compliance, not rider outcomes. The RFP specifies what the system should do. The vendor delivers to spec. But no one evaluates whether the system will integrate with the operational reality of how service actually runs. Operations teams know the technology doesn’t reflect dispatch decisions, disruption patterns, or the way information actually flows during service changes. Technology teams don’t have a structured way to account for that operational complexity. The result is expensive systems that technically integrate but don’t deliver the experience they promised.

This is the wall we keep hitting, regardless of which department we lead. If we lead CX, our mandate is to improve rider experience, but the most impactful improvements require coordination we don’t directly control. If we lead operations, we know operational decisions shape experience more than any app or website, but we don’t have a framework for making that connection visible and measurable. If we lead technology, our systems deliver features but not outcomes, and we lack a structured way to organize roadmaps around what riders actually need. If we’re a GM, we’re accountable for ridership, but we lack a framework for connecting that strategic goal to specific, coordinated investments—not just a list of projects.

What we’ve been missing is a framework for identifying which cross-cutting outcomes matter most and how to structure accountability around them.

Jobs to Be Done: The Framework Transit Leaders Need

Instead of asking “who owns this channel?” or “what’s our satisfaction score?”, this approach asks: What does a rider need to do to successfully take transit, and which of those jobs are we failing at?

This is called jobs to be done. It’s a methodology that shifts the lens from the systems we manage to the outcomes riders need. And it gives us something we’ve never had: a structured way to see which systems need to work together, which teams need to be in the room, and where the next investment will create the most value.

Take trip planning as an example. A rider taking their familiar daily commute has different needs than someone navigating an unfamiliar route, or someone whose trip has just been disrupted. They might share some needs—like knowing when their bus arrives—but their jobs are different. The commuter is trying to confirm their bus is running normally. The unfamiliar rider is trying to figure out which bus to take and where to get off. The disrupted rider is trying to find an alternative way to get where they’re going.

When we map these jobs, something powerful becomes visible: we can see exactly which touchpoints and systems need to coordinate to support each one, and where that coordination is breaking down.

What This Makes Visible

Consider three rider jobs at three stages of a trip: planning, monitoring, and recovering. Each requires different touchpoints, different systems, and different teams to coordinate. And, almost none of that coordination is visible until we map it.

Look at the columns. The systems that support monitoring and the systems that support recovering barely overlap. They are different platforms, different data sources, and different teams.

Now look at the $3.5M prediction system from our opening story. It was built entirely within the monitoring column. But when service got disrupted, the rider’s job shifted to recovering. In this scenario nothing was designed to support that transition. The prediction system didn’t know the trip was canceled. The alert system didn’t know the rider was watching predictions. Each system worked. The job failed.

This is exactly the kind of gap that satisfaction scores, NPS, and complaint volumes will never help us diagnose. A jobs-to-be-done map will.

How to Operationalize This Inside an Agency

A jobs-to-be-done map is not a research artifact, it’s a leadership tool. It doesn’t require a transformation program, it just requires reframing the work.

1. Define the Outcomes That Matter

Start with high-stakes rider jobs:

• Get to work reliably.
• Recover quickly from disruption.
• Navigate an unfamiliar trip with confidence.
• Decide whether transit is a viable option.

These are not channels or features. They are outcomes. By definition, they cut across systems and require coordination beyond any single platform or team.

2. Map What Actually Has to Work

For each job, map:

• Touchpoints
• Systems and data
• Team ownership

The gaps surface immediately:

• Systems that don’t share data.
• Teams without shared KPIs.
• Siloed budgets.
• No owner for the handoff between monitoring and recovery.

3. Identify the Breakpoints

Don’t ask where the system fails, ask where the rider’s job fails.

The breakpoint is often a handoff:

• Between AVL and alerts
• Between dispatch decisions and customer-facing channels
• Between schedule updates and trip planning logic

Those breakpoints represent the highest-leverage opportunities for coordinated investment.

4. Assign Outcome Ownership

Instead of owning channels, leaders sponsor outcomes:

• “Recovering from disruption.”
• “Confident trip planning.”
• “Reliable daily commuting.”

They do not manage every system directly. They are accountable for the coordination required to deliver the outcome.

What Changes

When we organize around rider jobs instead of channels, several practical shifts follow.

Investment decisions begin to prioritize cross-system reliability rather than isolated feature delivery. Roadmaps are evaluated based on their contribution to defined rider outcomes, not just channel performance metrics.

Procurement conversations expand beyond functional requirements to include operational integration and coordination across platforms. The question is no longer only whether a system meets specifications, but whether it supports a critical rider job under real operating conditions.

KPIs evolve as well. In addition to tracking system performance, we measure whether key rider outcomes, such as successfully recovering from a disruption, are improving over time.

Most importantly, accountability becomes clearer. Executive sponsors are responsible not just for individual systems, but for the coordination required to deliver specific outcomes.

This is not a wholesale reorganization. It is a reframing of how we define success and structure collaboration. That reframing has significant implications for how capital is allocated, how work is prioritized, and how experience is ultimately delivered.

The Leadership Shift

We do not lack technology. We lack a framework for aligning technology, operations, and customer experience around shared rider outcomes.

Without that alignment, even well-executed investments can fail to improve how transit actually feels to use. Our systems perform as designed. Vendors deliver to specification. Internal metrics show progress. And yet the rider experience remains fragmented because no one is accountable for the outcome across systems.

A jobs-to-be-done framework changes the unit of management. It shifts our focus from channels and platforms to the outcomes riders are trying to achieve. That shift makes coordination visible. It clarifies where accountability should sit. And it provides a structured way to prioritize investments based on their impact on real rider jobs—not just system performance.

For those of us in executive roles, this is not simply a customer experience initiative. It is an operating model decision. It determines how we structure roadmaps, how we allocate capital, how we evaluate procurement, and how we sponsor cross-functional work.

If we want technology investments to translate into ridership growth, trust, and ease of use, we need to manage transit the way riders experience it: as a series of jobs that must reliably work together.

This framework offers a structured way to do that. It does not eliminate complexity, but it makes it visible. It does not remove organizational boundaries, but it clarifies where coordination is required.

For agencies ready to move beyond reporting metrics toward actively managing experience, this is a practical place to begin.