RideSync
Designing the bridge from high-touch service to self-service
Context
We were successfully moving passengers without really serving them.
RideCentric’s enterprise relationship was built around the travel arranger. They booked transportation, received confirmations, coordinated changes, and communicated with Operations.
The problem wasn’t a lack of structure. It was a lack of shared visibility around it.
When a passenger needed information, the question moved through the organization before the answer could reach them. At the same time, bookers were managing several passengers and rides through email threads, forwarded itineraries, and repeated status checks.
Research
The workaround showed us what the product was missing.
During research, we noticed something important: confirmations and itineraries sent to bookers were already being forwarded to passengers.
That behavior told us two things. Passengers clearly needed access to information RideCentric was only providing to the booker, and bookers were already acting as a manual distribution layer.
Customers had already designed the first version of the product themselves
“How do we give passengers more updates?”
“How do we turn the information customers are already passing around into a live shared experience?”
Strategy
We deliberately did not start with the full booker platform
We knew bookers would eventually need a deeper product. But building RideCentric+ first would have required customers to create accounts, learn a new system, and change their workflow before they had experienced enough value to justify the commitment.
Value first. Commitment later.
The product could open from the communication customers already used, expose live transportation information immediately, and be shared with the passenger without forcing either person through a traditional signup flow.
We made access portable because the relationship was temporary for some users and recurring for others.
One ride had to support two completely different questions
For the booker, the product needed to scale outward: passengers, multiple rides, dates, statuses, vehicle assignments, and event-level visibility.For the passenger, it needed to collapse inward: itinerary, chauffeur, vehicle, next stop, and current state.
System
We organized RideSync around how customers think about transportation, not how dispatch stores it.
Internally, RideCentric deals with operational entities, statuses, service types, and assignment logic.
We exposed complexity progressively instead of transferring backend complexity into the interface.
The product
A forwarded itinerary became a living itinerary.
The passenger view turned static information into an experience that changed with the trip.An incoming flight could affect pickup. A chauffeur could move from unassigned to assigned. A vehicle could move from approaching to in progress. The passenger could track the ride when information was enough and call the chauffeur when conversation was actually necessary.
The product answered questions before they became support requests.
For bookers, visibility scaled from one passenger to the whole event.
Once RideSync became useful at the individual itinerary level, the same information model could support bookers coordinating larger groups.The event view surfaced rides by date, passenger, and status, while the map turned multiple simultaneous rides into something understandable at a glance.
The booker no longer had to reconstruct the event from confirmations and email threads.
Self-service only worked if confirmation and payment could stay inside the same experience.
Card payment could be automated end-to-end, but enterprise customers still relied on bank transfers.Rather than removing that workflow to make the product cleaner, we kept the familiar payment method and digitized everything around it.
Roadmap
RideSync was the first product in a larger transition.
The goal was never to make one portal solve every role in RideCentric’s operation.RideSync created the first customer-facing visibility layer and gave the business a low-friction way to introduce software into an established service relationship.From there, the product ecosystem could deepen by role.
Beta testing showed us where humans had been filling the UX gaps.
Small ambiguities became much more important once an Operations agent wasn’t there to explain them.
Outcome
We removed the middleman from the information, not from the service.
RideSync gave passengers direct visibility and gave bookers a way to coordinate transportation without constantly reconstructing the latest state through calls and emails.It also established a product relationship before asking customers to adopt a full platform.
RideSync gave customers more direct control over routine interactions while reducing the need for Operations to coordinate every step between bookers and passengers.
Reflection
The biggest product decision wasn’t what to build. It was what not to ask users to change yet.
RideSync reinforced that removing friction does not always mean introducing a bigger platform. Bookers were already coordinating rides through email, phone calls and forwarded confirmations. Passengers were often even further removed from the system, depending on someone else for updates, payment information and ride visibility.
My Role
Product Strategy, Experience & Systems
My role spanned product strategy, service thinking and end-to-end experience design.
I helped define how RideSync could sit between RideCentric’s internal operations, bookers and passengers without introducing unnecessary complexity. This included structuring the event and ride experience, payment and confirmation flows, passenger sharing, ride visibility and the broader relationship between RideSync and the products that would follow it.
The work required thinking beyond individual screens and designing the system around how information moved between people.
Contributions
Product strategyService designBooker & passenger experienceInformation architectureUser flowsPayment & confirmation flowsEvent & ride structureInteraction designResponsive experienceDesign systemProduct sequencing
