Case Article—Calyber: A Ridesharing Game

1. Introduction

A ridesharing platform is a transportation service provider that connects customers (riders) with drivers who can take them from their origins to their desired destinations, usually via a mobile app. Their products usually include both solo and shared rides; the former is similar to a taxi service, whereas the latter pools multiple riders with compatible origin-destinations in the same vehicle. The shared rides products, called UberX Share (formerly UberPool) and Lyft Shared (formerly Lyft Line), were launched around 2014 to improve vehicle utilization, lower costs, and mitigate congestion by matching riders with similar routes. These products initially gained significant popularity in urban areas and at their peak accounted for a substantial share of trips (20%–30%) on major platforms (Lunden 2016, Lyft 2018).

However, sustaining shared ride products has proven challenging. Platforms must navigate issues such as low match rates outside dense city centers, balancing affordable prices with operational costs and maintaining customer satisfaction with respect to detours and waiting times. The onset of the COVID-19 pandemic disrupted shared rides further, and even after relaunch efforts (Lyft 2021, Uber 2022), adoption has remained inconsistent. Companies experimented with various pricing models and incentives to encourage adoption and improve matching efficiency, but these efforts often fell short of achieving the desired outcomes (Desai 2022, Davalos 2023). These experiences highlight both the opportunities and the persistent challenges associated with shared ride services in practice.

This case is developed against this backdrop, drawing on the direct field experience of authors who worked at leading ridesharing companies during the formative years of shared ride product development and motivated by the policies developed in Yan et al. (2026). Calyber¹ is a fictitious Chicago-based ridesharing company striving to offer affordable and efficient carpool service, yet it faces significant operational hurdles. A central challenge is that low prices are required to attract enough demand for effective matching, but such prices may not recover dispatching costs. Conversely, higher prices can suppress demand density, leading to inefficient matches and longer detours. To address these issues, CEO Eliot George and Chief Scientist Thea Bruckner propose overhauling the company’s current pricing and matching engine (an unprofitable black box that had been developed by a former employee, Nick Bailey), aiming to develop a transparent, data-driven, and real-time engine that sets prices and matches riders based on cost structures, demand patterns, and rider behavior. Students are provided with training data generated from the current pricing and matching engine (“Nick’s engine”). Guided by the instructor and following Thea’s recommendations in the case, they use this data to develop the improved pricing and matching policies (“Thea’s engine”). Finally, they experiment with and develop their own pricing and matching policies.

This case invites students to explore the interplay between pricing, matching, and experimentation in the design of an effective shared rides product. It offers a hands-on and engaging experience in developing and deploying data-driven, real-time analytics solutions for a ridesharing marketplace. At its core, the case centers on stochastic dynamic decision making, where each real-time decision should account for both its immediate reward and its future implications—a methodological concept that is often challenging to convey through traditional instruction. By situating this concept within a modern and relevant context, the case provides an immersive, data-driven tool for teaching dynamic decision making in practice.

The operational context is as follows. Riders arrive randomly over time. For each arriving rider, the platform sets a price, which the rider may accept or reject. If accepted, the platform attempts to match the rider with another waiting rider, enabling them to share a ride to their destinations. The platform earns revenue from the prices paid by both riders while incurring driving costs for their pickup and drop-off. If no suitable match is immediately available, the platform can defer matching; however, riders have limited waiting patience, and if this threshold is exceeded, the platform must dispatch the rider solo, resulting in higher costs and lower efficiency.

In this simulation game, students play the role of the platform. Their objective is to maximize profit by setting prices for incoming riders and matching those who accept (referred to as “converted” riders or requests). Total profit is calculated as the revenue collected from all riders minus the total driving costs. The challenge lies in navigating key trade-offs: pricing decisions must account for both the cost of serving each rider and the rider’s willingness to pay—cost assessment is nontrivial, as it depends on future uncertain matching outcomes. For matching, students must decide whether to match riders immediately or wait for potentially better matches, all while managing the risk that riders’ patience will expire, forcing costly solo rides.

The case activities span several weeks, during which students are provided with a historical ridesharing data set² containing details on over 10,000 rider arrivals, prices, conversion rates, matching outcomes, and more. They also receive a code template³ specifying the required input and output formats, enabling them to design and implement their own pricing and matching policies. Student policies are evaluated and ranked through simulation on both validation and test data sets. The validation set is used for optional midterm evaluation and providing feedback to students, whereas the test set determines the final ranking. Performance is assessed primarily on the profitability of each policy, with the secondary objective being matching efficiency.

2. Related Work

Ridesharing and the broader transportation-sharing economy provide contemporary and relatable applications to engage students. Operations strategy cases ask students to discuss the evolution of the ridesharing business model (Moon 2015), as well as competition with the taxi industry (Teo et al. 2019) and rival platforms (Chen et al. 2016, Zhu and Acocella 2016, Gulati and Huizinga 2024)—issues familiar to students thanks to extensive coverage by the popular media (Anand 2017, Barron 2018, New York Times 2018).

Another relevant topic involves the design of UberPool and related carpooling products, where the aspiration of “[turning] every car into a shared car… reducing traffic and pollution” meets the challenge of providing a positive rider experience (Iansiti et al. 2016). To motivate the benefits of carpooling (among other applications), Barbarino and Boute (2023) use a 15-passenger exercise to illustrate how individual passengers reduce costs by collaborating and discuss allocation rules to distribute these benefits between passengers. But despite these potential gains, encouraging passengers to share rides can be challenging; Lo and Morseman (2018) describe Uber’s marketing research process and find that unpredictable detours are a major deterrent for UberPool. Farronato et al. (2018) discuss the subsequent launch of ExpressPool, a product that asks riders to walk short distances and wait briefly before being matched to coriders, allowing the platform to make more efficient matches with shorter detours. The case then asks students to analyze the results of an experiment to decide whether to ask riders to wait longer to be matched, which improves matching but also incurs the risk of riders canceling their rides, a trade-off that also arises in our case. However, instead of directly providing students with the results of a given matching policy, we ask students to design and evaluate their own pricing and matching policies on large-scale data. Our setup allows students to creatively explore different approaches and mimics the experience of deploying an experiment in a real-world technology company.

Beyond ridesharing, bike sharing has been used to teach process flow (Akturk and Candogan 2024), inventory management (Gomez-Ibanez and Johnston 2016, Martinez de Albeniz Margalef 2017), and demand analysis (Naoum-Sawaya and Xiong 2021); carsharing has been used to teach capital budgeting (Hall and Ko 2018); and car rental has been used to evaluate wage structure and outsourcing decisions (Rajan and Ravichandran 2017). These cases highlight the value of using shared mobility applications to teach classic operations problems in modern contexts.

Our case also relates to classroom simulation games. For example, previous games have placed students in the roles of actors in a supply chain (Sterman 1984, D’Amours et al. 2017, Zhao et al. 2023) or a healthcare system (Sauré and Puterman 2014, Kong 2019); students can order inventory, price goods, treat patients, and schedule jobs, among other decisions. The games simulate complex system dynamics that respond to students’ decisions for an engaging and immersive classroom experience. Our case most closely relates to games that involve pricing in a variety of industry contexts: tourism (Talluri 2009, GameLab Education 2025), rental cars (Gourville et al. 2011), hotels (Jaureguiberry and Tappata 2015), as well as ridesharing (MobLab 2018). These games expose students to concepts such as demand uncertainty, valuation-based pricing, dynamic pricing, customer segmentation, capacity management, and competition in an engaging and interactive setting. Our case touches on many of these concepts (chiefly demand uncertainty, valuation-based pricing, and dynamic pricing) in ridesharing. We also incorporate an additional component of matching riders to illustrate how pricing interacts and integrates with other decisions, thereby providing a holistic view of dynamic decision making for a ridesharing platform.

3. Learning Objectives

The learning objectives are as follows:

1. Understand the online and dynamic nature of an on-demand ridesharing platform, and identify key sources of uncertainty and associated trade-offs involved in dynamic pricing and matching.

2. Apply data analytics techniques to Calyber’s historical operational data and provide insights into demand patterns and rider behavior.

3. Design and implement data-driven policies for dynamic pricing and matching.

4. Experiment with and evaluate the developed dynamic pricing and matching policies using validation and test data. Interpret key performance indicators, critique and refine the policies, and discuss implications for Calyber’s shared rides offering.

4. Audience, Prerequisites, and Position in Course

The case is best suited for senior undergraduate or graduate students with an analytics-related background or for research-oriented PhD students seeking hands-on experience in developing data-driven dynamic policies. For junior undergraduate students, the teaching plan can be modified to incorporate more instructor guidance. The case has been successfully implemented with a range of students, from sophomores to PhDs.

Students are expected to have basic proficiency in Python programming and data analytics, as they will work with a data set of over 10,000 riders and implement their policies using a provided skeleton file. For students with less programming experience, a set of tutorial-style Jupyter notebooks is provided, starting with descriptive analytics on Calyber’s historical data and progressing to step-by-step instructions for building Thea’s policy.

Although familiarity with (dynamic) optimization and simulation is helpful for designing and evaluating effective policies, it is not required. The case is self-contained and can be successfully completed without prior knowledge in these areas.

The case can complement a wide range of courses, including topical offerings in supply chain and logistics (e.g., inventory control and online order fulfillment), marketplace design (e.g., dynamic matching), as well as methodological courses in dynamic optimization and analytics.

5. Teaching Plan

We provide detailed week-by-week suggestions and a case analysis in the teaching note. Here, we give some general guidelines for using the case.

5.1. Logistics

This case is intended to be implemented as a five- to six-week group project during the second half of a semester- or quarter-long course. We recommend structuring the case around three class sessions and two rounds of submissions. It begins with an introduction session, followed by several weeks of data exploration and policy development. Midway, teams submit their policies for a validation-round evaluation and receive feedback, and the instructor can hold a discussion session. The final weeks are dedicated to improvements based on validation feedback and preparing a final submission for the test round. The last class session is used to announce final rankings based on test data, present strategies and outcomes, and reflect on key insights.

The case can also be run as a two- to three-week intensive module, with the first week for instructor-led tutorials, the second for policy development, and the final week for validation, testing, and presentations. This format has been used successfully in a three-week summer camp for sophomore and junior engineering students, supported by tutorial-style Jupyter notebooks in the supplemental materials.

5.2. Implementation

For classroom implementation, we recommend using GitHub Classroom, which enables students to form teams and work in team-specific repositories automatically forked from a master template. This setup facilitates collaborative development, version control, and seamless submission of deliverables through each team’s assigned repository.

5.3. Case Analysis

If the instructor implements the case as a five- to six-week group project within a semester- or quarter-long course, we recommend walking students through a case analysis during the validation session (the second class session). The case analysis covers the ridesharing platform’s dynamics, the development of Thea’s policies, and possible improvements (please refer to the teaching note for details of the case analysis). Going over the analysis at a later stage encourages exploration and prevents students from being constrained by a limited set of prescribed methods. It is also more effective at a later stage, as students will already be familiar with the data set and will have developed and evaluated preliminary pricing and matching policies, enabling them to better engage with and appreciate the analysis. Alternatively, if the instructor delivers the case as a three-week intensive module, this analysis can be conducted during the first week to jump-start the teams’ development process.

6. Teaching Experience

This case has been taught at UC Berkeley three times: twice in a graduate course on supply chain and logistics, INDENG C253/CIVENG C258 Supply Chain and Logistics Management (spring 2024, 2025), and once in an undergraduate engineering course in the Transfer Pre-Engineering Program (T-PREP) (summer 2024). Table 1 summarizes the class sizes across these offerings. In the graduate course, the case was implemented as a six-week group project during the second half of the semester. Each student, on average, spent roughly one to two hours per week on the case, with more time devoted toward the end of the six-week period. In the undergraduate course, the case was delivered as a three-week (13-hour) intensive module in a summer session, during which students worked exclusively during scheduled class time and did not spend time offline.

Table 1. Summary of Previous Class Implementations

In the following subsections, we review the student performance in the previous implementations and analyze the key trade-offs reflected in their policies.

6.1. Performance

Here, we look at students’ overall performance and their comparison with the two benchmark policies (Nick’s and Thea’s policies). This is intended to give the instructor a high-level idea of what to expect, but these results may not be representative of students in other courses and at other universities.

As shown in Figure 1, most of the student teams were able to design profitable policies but did not necessarily improve over the benchmark of Thea’s engine (red). To show how they achieved this performance, we display the median key performance indicators across the student teams, as compared with those for Nick’s and Thea’s engines, in Table 2. The student teams typically charged lower prices than Thea’s engine ($0.73/mile instead of $0.83/mile) and thereby achieved higher throughput (8.15 riders/minute instead of 4.02 riders/minute). However, they were not able to capitalize on this higher throughput to match more effectively, as the average cost per rider was similar ($0.62/mile versus $0.63/mile) despite a higher match rate (0.71 versus 0.59). Meanwhile, Figure 1 presents high variance in student performance, highlighting the varying effectiveness of their policies in balancing revenue making and cost control.

Table 2. Median KPIs Across Student Teams, Compared with Those for Nick’s and Thea’s Engines

6.2. Trade-Offs

The performance metrics of the teams reveal important trade-offs in both pricing and matching decisions. Note that the plots in this section have their x-axis values hidden to avoid revealing sensitive details about the performance and specifications of student policies. Unredacted plots are available in the teaching note.

6.2.1. Pricing Trade-Off.

Figure 2 shows how profit varies with the average quoted price: profit tends to increase with price up to a point and then decreases as prices continue to rise. Meanwhile, there is a clear boundary between teams that are profitable (blue) and unprofitable (orange)—teams quoting very low prices consistently ended up with negative profits, as they fail to recover the costs. On the other hand, very high prices may suppress demand and matching efficiency, reducing overall profitability. This results in a concave trend in Figure 2, highlighting the importance of striking a balance in pricing.

6.2.2. Matching Trade-Off.

We focus on the subset of teams that achieved positive profit, as the negative-profit teams generally failed because of underpricing, making their matching decisions less informative. Figure 3 presents a clear downward trend between profit and cost per rider; it indicates that reducing the cost per rider, potentially through an appropriate amount of high-quality matching, generally improves profitability. Meanwhile, teams with a higher profit typically have an intermediate match rate (yellow), whereas those with excessively high (green) or low (red) match rates tend to be less profitable, probably as a result of inefficient or failed matching. Thus, achieving cost-effective matching requires not only maintaining a reasonably high match rate but also a high match quality.

6.3. Improvements Since the Validation Round

The students also benefited from the optional validation round, using it to test and refine their policies. Of the 31 student teams, 20 participated in the validation round (16/26 graduate, 4/5 undergraduate). Of these 20 teams, 17 improved their profits (13/16 graduate, 4/4 undergraduate), typically by raising prices and/or improving matching quality. Please refer to the teaching note for more details.

6.4. Student Groups

As the undergraduate class size was relatively small, with only five teams, it is hard to draw strong conclusions on the performance comparison between the undergraduate and graduate students. However, as shown in Figure 1, there is no notable performance gap between undergraduate and graduate teams. This suggests that the case is suitable for students across a wide range of academic levels and technical backgrounds. It also highlights that with appropriate additional guidance (such as the tutorial-style notebooks), undergraduate students can develop reasonable policies that achieve performance comparable to many graduate teams, even if their approaches are more intuitive and methodologically simpler.

6.5. Feedback

We report student feedback in Table 3 across three in-person offerings: the graduate course INDENG 253/CIVENG C258: Supply Chain and Logistics Management at UC Berkeley in spring 2024 and spring 2025, as well as the T-PREP summer 2024 bridge program for incoming undergraduate transfer students to Berkeley Engineering. Across all cohorts, students consistently rated the case as moderately to highly challenging. The graduate sections reported average difficulty scores of 5.50/7 (2024) and 4.89/7 (2025), whereas the T-PREP students—many of whom had limited prior exposure to Python, analytics, or operations research (OR)—reported a difficulty of 3.71/5. Despite the challenge, written comments emphasized that the effort was rewarding: one group remarked that the project was “very time-consuming, but we really learned new things through discussion and collaboration,” and multiple students across programs described the experience as “the highlight of the course.”

Table 3. Summary of Student Feedback Across Cohorts

Student endorsement of the pedagogical value was similarly strong. Overall, students recommended that the case be taught again, with scores of 6.44/7 in both graduate offerings and 4.36/5 in the T-PREP cohort. In spring 2025, graduate students agreed that the case increased their awareness of real-world transportation issues, with a score of 6.25/7; one student described the case as “a very valuable experience [that] piqued my interest in ridesharing and inspired me to explore this topic further.” These students also reported strengthened understanding of analytics and operations research tools and how they are applied in practice (6.13/7). The T-PREP cohort also showed learning gains, although their more limited background could be a barrier: the case increased awareness of transportation issues (4.14/5) and improved understanding of analytics/OR tools (3.86/5).

Across cohorts, the written feedback reveals differences often rooted in students’ backgrounds. Graduate students emphasized the excitement of seeing “heuristic and simple strategies perform super well” and then being able to “refine [the models] in a data-driven manner under [the instructor’s] suggestions.” In contrast, T-PREP students requested more instruction and guided preparation early on and more opportunities for testing and feedback later. Nevertheless, students cited the relevance of the ridesharing context, the engaging format, and the sense that the case deepened their understanding of data-driven modeling and operations analytics. Together, the results demonstrate that the case not only meets its intended learning objectives but also scales effectively across diverse student populations.

7. Conclusion

This case introduces Calyber, a simulation-based game that challenges students to design data-driven pricing and matching policies to maximize the profitability of the shared rides platform. By placing students in the role of platform operators making real-time decisions, the case provides hands-on experience with key trade-offs in a dynamic, uncertain environment. Students engage with large-scale data, develop and test policies, and are evaluated through multiple rounds.

The case is suitable for a broad range of learners, from undergraduates with basic data analytics skills to graduate and doctoral students with stronger technical backgrounds. It has been implemented successfully in both student groups—students have created meaningful policies, shown improvement through multiple rounds, and expressed high levels of engagement and interest in the topic.

This case offers instructors an interactive, data-rich tool for teaching stochastic dynamic decision making. It contributes a novel perspective to the growing set of simulation games, particularly by integrating both pricing and matching decisions—a realistic operational challenge in ridesharing platforms.

The model in the case simplifies ridesharing operations for classroom use. First, we only consider a shared rides product, whereas companies such as Uber and Lyft simultaneously offer a separate solo rides product. The price and associated travel time under this solo rides product then influence riders’ conversion behavior to the shared rides product. We made this simplification to focus on the key pricing and matching trade-offs and because operating a shared rides service in isolation is already challenging (as evidenced by the wide range of performance achieved by the different student groups). Second, riders are dispatched in a solo ride after their waiting patience is exceeded, whereas in practice, riders might also cancel their requests. Future cases can highlight considerations such as the interaction between shared rides and solo rides products or more complex models of rider patience. For interested readers, these extensions are also discussed in Yan et al. (2026) in detail.