Increasing the Value of Shared Vehicles: Insights from an Implementation of User-Based Relocation in Station-Based One-Way Carsharing

Abstract

New digital technologies are a driving force behind many pivotal changes in our modern world. For example, the carsharing business model has improved drastically through the adoption of technologies for online booking, instant access, vehicle monitoring, and automated billing. However, the challenge of vehicle supply and demand management hinders carsharing from reaching its full potential and mainstream application. The current norm of relocating vehicles via employees is expensive and unsustainable, counteracting the environmental benefits of carsharing. To engage this problem, a new concept called user-based relocation has emerged in recent years. For user-based relocation, customers are requested to return rented vehicles at undersupplied locations. However, research and practice lack knowledge on how to implement user-based relocation in a real-world carsharing system. This study employs an iterative research approach, including the implementation of user-based relocation in a real-world carsharing system. During the development and evaluation process, novel requirements and challenges for user-based relocation were discovered, providing valuable knowledge for its implementation and future research.

1. Introduction

Carsharing business models provide an excellent illustration of the benefits and increased capabilities that information technology (IT) and information systems (IS) can offer in improving and optimizing sharing processes [1,2]. In recent decades, carsharing systems have been (and some still are) operated manually through the physical transfer of keys and handwritten mileage reporting [2,3]. The digitalization of carsharing infrastructures has led to radical changes in carsharing operations. For example, instant rental and accessibility are made possible through the adoption of smartphone applications (app) or key cards, location and mileage tracking is enabled by GPS technology, and billing can be automatically managed via specialist IS [2]. In addition to automating processes, IT and IS also enabled new forms of carsharing, such as free-floating, station-based one-way, and peer-to-peer carsharing [2]. However, providing these modern forms of carsharing also comes with a new set of challenges [1,2].

Free-floating and station-based one-way carsharing offer customers the option to return a vehicle at any location, instead of returning it to the origin location. However, this increase in flexibility for the customers results in frequent vehicle supply–demand imbalances which prevent customers from accessing vehicles [4,5]. Carsharing providers currently handle supply–demand imbalances via manual redistribution, driving vehicles from low-demand to high-demand locations [5,6]. This procedure is expensive and time-consuming, reducing the sustainability and cost-efficiency of carsharing [4,7]. As an alternative approach, the concept of user-based relocation has been discussed in current literature [7,8,9].

User-based relocation aims to motivate customers (often via monetary incentives) to return currently rented vehicles to locations with high vehicle demand [4,6]. Although this approach is considered a more sustainable and cost-efficient solution [4,7], user-based relocation is yet to be implemented within a real-world commercial carsharing system. To the best of our knowledge, research on the design and implementation of user-based relocation remains a gap in the current literature. Hence, this paper aims to contribute to closing this research gap by answering the following question:

RQ:How should a user-based relocation system for carsharing applications be designed?

2. Research Background

Current carsharing research classifies carsharing models into three distinctly defined formats [8,10]:

• Station-based two-way carsharing: This carsharing format allows customers to rent a vehicle from a station but requires them to return it to the same station at the end of the rental period [5,11].
• Station-based one-way carsharing: This format of carsharing enhances station-based two-way carsharing by giving its customers the option of returning vehicles at any available station [11,12].
• Free-floating carsharing: Unlike the other two carsharing formats, free-floating carsharing has no stations, and customers may rent and return vehicles everywhere within the operation area of the carsharing provider [11,13].

Because demand varies by location and time of day, providers must relocate vehicles to counterbalance the under- and over-supply of vehicles at some locations [4,10,14]. Current research defines three types of vehicle supply and demand management approaches [15]:

• Operator-based relocation: In operator-based relocation, staff members move vehicles to their desired location via driving, towing, or ride-sharing [16].
• User-based relocation: The idea of user-based relocation is to motivate users to return currently rented vehicles at a different location from their initial destination before the end of the rental period [4,6,13].
• Prevention-based: Area pricing strategies and other monetary incentives aim to persuade the user to choose certain vehicles and park them at selected locations to maintain a balance between supply and demand [9,15,17].

To evaluate the current status quo of vehicle user-based relocation research, we conducted a literature review and followed a three-step process. First, we analyzed various literature reviews [8,10,18] to identify articles on the topic of user-based vehicle relocation in carsharing. Second, we performed a keyword search, which led to the identification of several additional publications. The search was performed with leading publication databases such as ScienceDirect, EbscoHost, JSTOR, and AIS Electronic Library using the following search query:

(“carsharing” OR “car sharing”) AND (“relocation” OR “rebalancing” OR “allocation”) AND (“user-based” OR “user based” OR “userbased”)

We refrained from adding additional terms that could describe approaches similar to user-based relocation (such as customer-based) because user-based is an established term and adding additional keywords would lead to a bloated literature sample. Furthermore, we did not include other vehicle sharing services in our literature search (such as bike- or e-scooter-sharing) because of the difference in the vehicle relocation problem. In essence, unlike carsharing, bikes and e-scooters can be relocated in multiples (for instance, via a transporter), changing the “rules” of vehicle relocation.

Third, we conducted a forward and backward search, resulting in one more publication.

In total, we gathered 30 publications concerning the concept of user-based relocation. Two of the authors conducted the literature review independently, classifying the articles using the carsharing system type (free-floating or station-based) and research approach (simulation, literature analysis, survey, or field test). Results were discussed to reach a consistent publication corpus. The literature review was conducted in January of 2017, updated in January 2018 and in October 2020. It is summarized in

Table 1. Literature overview—user-based relocation research.

Article	Research Approach				Carsharing System Type
	Simulation	Literature Analysis	Survey	Field Test	Free-Floating	Station-Based
Angelopoulos et al. [17]	X					X
Banerjee et al. [19]	X					X
Barth and Todd [16]	X					X
Barth et al. [20]	X			X		X
Bianchessi et al. [21]	X					X
Brendel et al. [4]	X					X
Brendel et al. [22]	X				X
Brendel et al. [23]	X					X
Cepolina and Farina [24]		X				X
Cepolina and Farina [25]	X				X	X
Chow and Yu [26]	X					X
Clemente et al. [27]	X				X
Clemente et al. [7]	X					X
Di Febbraro et al. [5]	X					X
Di Febbraro et al. [28]	X					X
Gambella et al. [29]	X					X
Gavalas et al. [30]		X			X	X
Herrmann et al. [31]	X		X		X
Huang et al. [32]	X					X
Huang et al. [33]	X					X
Huo et al. [34]	X					X
Jorge et al. [35]	X					X
Jorge and Correia [8]		X				X
Laarabi et al. [36]	X					X
Schulte and Voß [37]	X				X
Wagner et al. [6]	X				X
Wang et al. [38]	X				X
Waserhole et al. [39]	X					X
Weikl and Bogenberger [13]	X				X
Wu et al. [40]			X		X
∑ 30	26	3	2	1	10	22

.

In parallel with other literature reviews [8,10], the literature analysis revealed that the primary applied research approach is simulation-based. The developed algorithms are strongly focused on optimizing the relocation logic in the backend of a vehicle relocation IS. Some of these algorithms are “practice-ready” [18] but are not tested in a real-world carsharing system. Regarding user-based relocation, only Barth et al. (2004) tested it in a real-world environment, specifically on a university campus. Within the field test, participants were asked to split (driving several cars) or join (sharing a car) a ride with other users to balance vehicle supply. This means that fewer operator-based relocations are necessary, as the relocations are carried out indirectly by the users. Hence, Barth et al. (2004) provided a solution resulting in a 42% reduction in manual relocations. However, to the best of our knowledge, their field study seems to be the only real test of the user-based relocation concept. In addition, Barth et al. (2004) tested an unusual user-based relocation concept compared to the user-based relocation concept of all other studies. In conclusion, the field of user-based relocation literature remains lacking regarding implementation and application within a real-world environment.

3. Research Approach

Our research approach is based on the Design Science Research (DSR) frameworks of Hevner et al. [41] and Hevner [42]. The research setting and its interrelated cycles are depicted in Figure 1. The relevance cycle connects the design activities of the design cycle with the artifact’s intended environment. In this manner, the relevance cycle enables researchers to gather real-world requirements to describe and later solve real-world problems. Furthermore, artifacts are introduced to the environment as part of this cycle. The rigor cycle relates the design activities to the existing body of knowledge. Thus, existing knowledge can be integrated into design activities, and results can extend the knowledge base. The central focus of a DSR process is the design cycle, representing the design and development activities of researchers. An artifact is iteratively constructed and evaluated to solve the focal problem [42,43]. In the following sub-sections, we describe the research process in further detail.

3.1. Iteration 1: Problem Identification and Solution Conceptualization

The first iteration (see

Table 2. Summary of first iteration.

-	Iteration 1
	Relevance Cycle	Rigor Cycle	Design Cycle
Inputs	Carsharing literature Carsharing provider	Publication database Initial requirements	Initial requirements User-based relocation literature
Methods	Literature review Expert interviews	Literature review Content analysis	Process and concept development
Results	Publication database Identification of research gap regarding implementation of user-based relocation systems Initial requirements	User-based relocation literature as input for design process	Concept of the user-based relocation process

for a summary) began with the relevance cycle. We reviewed the current status quo of user-based relocation carsharing literature to develop a publication database and identify relevant research gaps. In this review, we first analyzed three literature reviews and then performed a tailored keyword search. Finally, we conducted a forward and backward search (see Research Background section). As a result, we were able to identify a research gap in user-based relocation evaluation in practice, e.g., field tests, from which we derived our core research question on how to design and implement a user-based relocation system in practice. To further verify the research gap, we conducted interviews with two German carsharing providers who are experts in the topic at hand. Both providers have a fleet of around 30 to 50 vehicles and are located in a city with roughly 100,000 inhabitants. One offers station-based carsharing, while the other offers free-floating carsharing. We presented and discussed the research gap during both interviews and were thus able to capture the providers’ knowledge about the current challenges within the carsharing market. In both cases, we systematically proceeded as follows: first, we collected current challenges in vehicle supply and demand management in carsharing through a brainstorming session. In the second step, the findings (i.e., research gaps) from the literature review were presented and added to the selection of challenges when applicable. Finally, the results of the challenges and the literature review were superimposed. Both sessions confirmed that the identified research gap is valid and requires further research. Based on these interviews, we defined six initial requirements (see Section 4.1) in collaboration with the carsharing providers.

In the following rigor cycle, the previously collected literature was analyzed not only in the context of the research gap but also in the solution design. In this step, the framework of User-Based Relocation Information Systems (URIS) [4] and related algorithms were identified as input for the design process.

We performed a process and concept development within the first design cycle based on the initial gathered requirements and user-based relocation literature. The developed concept structures show user-based relocation process functions regarding the interaction of IS components and the physical task of relocation (see Figure 2). Our concept of the user-based relocation process was then used as an input factor for the second iteration.

3.2. Iteration 2: User-Based Relocation Application Development

In the second iteration (see

Table 3. Summary of second iteration.

-	Iteration 2
	Relevance Cycle	Rigor Cycle	Design Cycle
Inputs	Concept of user-based relocation process Carsharing provider	Usability literature Programming literature Machine learning literature	Requirements Regression tree implementation Mobile app development concepts
Methods	Workshop—Brainstorming	Literature review Content analysis	Prototyping Expert interviews Customer interviews
Results	Implementation requirements Need technical knowledge for implementation	Regression tree implementation Mobile app development concepts	Mobile user-based relocation app

for a summary), a relevance cycle was performed to evaluate and refine the developed user-based relocation process concept. For the evaluation, we partnered with the station-based one-way carsharing provider from the previous iteration because of the stated interest to implement user-based relocation. A brainstorming workshop was conducted on how to implement user-based relocation. By conducting a brainstorming workshop with two managing directors of the carsharing provider, we were able to refine and tailor existing requirements to the needs of the specific provider and to discover new requirements. The workshop was based on a general brainstorming method comprising two phases [15,44]. (1) Generation phase: In this phase, ideas about requirements are collected. Each participant can formulate ideas which are then gathered without judgment. (2) Evaluation phase: The ideas gathered in the generation phase are discussed, categorized, and merged when appropriate. The brainstorming process was guided by two questions: (1) Are there any additional requirements or refinements needed to improve the developed process concept? (2) What is required for the successful implementation of the developed concept? As a result, specific implementation requirements were defined, and the need for technical knowledge was determined. In total, four new requirements were added to the initial six requirements, forming a set of ten total requirements (see Section 4.2).

In the following rigor cycle, to find ways to fulfill the collected requirements and enable implementation of the user-based relocation process, we reviewed existing implementation approaches. We conducted an explorative literature review, focusing on usability, programming, and machine learning. During the analysis of the publications, we found that machine learning is a valuable starting point as input knowledge for the design cycle. Within the context of machine learning algorithms, the regression tree model was selected, as it enables the calculation of incentives depending on numerous factors, thereby addressing the gathered requirements. Furthermore, implementing user-based relocation as a mobile app [6] was most appropriate.

In the following design cycle, we developed a prototype of the mobile user-based relocation app. To ensure that the needs of both the future users and the carsharing provider were met, we consistently carried out brief consultations with the two groups during the prototyping process. We developed a machine-learning algorithm to compute the incentives for user-based relocation and documented the development process of the incentive computation method in a separate article [45] following a commonly used suggestion to separate DSR projects into closely linked articles [46]. Thereby, we will only briefly describe the incentive computation algorithm when appropriate. After integrating the incentive algorithm into our app, we successfully carried out app functionality testing [41], and a final review was conducted with the carsharing provider and some potential users. Carsharing customers were asked to test the app and give feedback at the service desk of the carsharing provider’s office.

3.3. Iteration 3: Field Test

In DSR, it is vital to evaluate artifacts in a real-world environment and to directly evaluate them within their intended field of application [42,47]. Therefore, within our third iteration (see

Table 4. Summary of third iteration.

-	Iteration 3
	Relevance Cycle	Rigor Cycle
Inputs	Mobile user-based relocation app	Development process User-based relocation app
Methods	Field test	Heuristic theorizing Writing for publication
Steps	Implement and evaluate the mobile user-based relocation app within a real carsharing system	Document development process and resulting artifact Submit for publication
Results	Evaluated concept Evaluated user-based relocation app Refined requirements Potential principles of form and function	This article

for a summary) the designed artifact (user-based relocation app) was applied for five months within a carsharing system and evaluated based on its performance. Overall, 74 customers installed the app, thereby participating in the field test [41].

The collected knowledge was then summarized in the last cycle to add to the existing knowledge base (rigor cycle) in the form of this article.

4. Results

In this section, we describe the artifact and its evaluation results.

4.1. User-Based Relocation Process

We developed our literature database during the first relevance cycle and identified a research gap of missing knowledge on how to implement user-based relocation (see Section 3). Furthermore, we conducted two expert interviews to validate the research gap and determine our research question. In both interviews, the carsharing providers expressed that current carsharing IS supports the core process of carsharing (e.g., rental and accounting) but lacks functionalities for vehicle relocation. Both providers apply operator-based relocation and identify vehicles for relocation based on implicit knowledge (e.g., making educated guesses). Furthermore, both see no alternatives to operator-based relocation. The concept of user-based relocation was known to both providers but seen as too complicated to implement, e.g., no “out of the box solution” was available. Nonetheless, both carsharing providers agreed that user-based relocation could be a promising solution when the challenge of implementation is addressed. Based on the gathered insights, we compiled the following list of initial requirements.

• R1 Balanced Supply System: User-based relocation should increase the balance between vehicle supply and demand within the system.
• R2 Substitution: User-based relocation should substitute operator-based relocations.
• R3 Cost-efficient: User-based relocations must be less expensive than operator-based relocations.
• R4 Adaptive and Easy to Implement: The user-based relocation process must be easy to implement.
• R5 Understandable: User-based relocation must be easy to understand for users.
• R6 Rewarding/Motivating: Users should be rewarded for relocations in order to motivate participation.

R1 and R2 capture the carsharing provider’s goal of optimizing vehicle management through balanced supply and demand. By using the artifact, carsharing providers should be able to reduce the number of manual relocations performed and reap the benefits of a self-contained, self-regulating relocation system, allowing the service system to dynamically meet the demands by supplying the needed vehicles via user-based relocation. In its optimal setting, the artifact results in reduced or eliminated manual operator relocations and shifts this value-creation responsibility to users.

Accordingly, R3 states that the system should not cause any additional workload or costs to the carsharing provider. The app is intended to decrease costs by reducing manual relocations, thus minimizing the high labor costs required for manual relocations.

R4 indicates that the app should be easy to implement, e.g., developed based on established programming frameworks and libraries. Due to the physical service-focused core competencies of carsharing providers, requiring advanced technical knowledge for the implementation of such a system is unfeasible.

R5 and R6 address the users’ collective perspective on user-based relocation. Customers should easily understand the concept of user-based relocation (R5) and the related structure of the incentives (R6), which is necessary to ensure participation. Customers should have a sense of the incentive in comparison to the perceived extra effort. For example, a situation with poor weather conditions, long travel distances, and inconvenient travel timing, such as overnight travel, should be rewarded more than a situation on a sunny day, with mild temperatures and a short distance. Customers should not feel that they are being rewarded by the system purely by chance but should be made aware of incentives as direct rewards for relocation behavior which provide valuable user benefits.

In the following rigor cycle, the previously gathered literature was analyzed to find a starting point for artifact development. Following the user-based relocation IS frameworks of Brendel et al. [4], based on the framework of Wagner et al. [6], a user-based relocation IS was developed comprising three main parts: vehicle demand prediction, relocation computation, and task communication. For the vehicle demand prediction, historical data, and sometimes real-time data, are analyzed to identify locations with higher demand for vehicles [4,37]. Based on demand predictions, the relocation module computes the necessary relocations to balance vehicle supply and demand. In this study, we apply the common threshold approach [4,48] due to its intuitive nature, ease of implementation, and ability to provide satisfactory results (R2, R3, R4). Each location is assigned a vehicle supply threshold based on historical data. When the vehicle supply is below the threshold, a relocation is needed. In the context of user-based relocation, customers driving towards an over-supplied destination are identified to relocate to the under-supplied location [4]. These customers then receive a request from the communication module to perform the needed relocation. The communication module can be realized with on-board monitors or mobile apps [6]. On-board systems can also strain drivers and negatively influence their attitude towards the system [49]. In contrast, mobile apps are already successfully used to rent and access shared vehicles [2] and are easier to implement and distribute (R4). Considering this, we decided to implement the communication module as a mobile app [6].

Based on the previously described user-based relocation knowledge, we developed a user-centered concept to guide our app development (see Figure 2) because current frameworks [4,6] primarily cover the system architecture rather than the interaction between the system and users.

A user-based relocation process begins when the necessary rental data (vehicle ID, destination, arrival time) are provided manually by the user or via a carsharing rental system interface (R4). Demand analysis is carried out in the backend. If a station close to the user’s destination is found to be in demand of vehicles (R1, R2), an incentive is calculated and presented to the user via the app, including all relevant information (new destination, incentive, relocation distance) (R5). If the user does not accept, the system searches for another suitable user and requests the relocation task and incentive. If all potential users decline the request, the incentive increases, and the relocation is requested again (R3). This process continues until either a willing user is found (R3, R6) or the operator-based cost is exceeded (R3). Once a user has agreed to relocate, the relocation is executed, and the related incentive is given afterward. Before granting the incentive, the system confirms that the user has completed the relocation task.

4.2. User-Based Relocation Mobile Application

Within the second relevance cycle, we identified additional requirements in cooperation with our carsharing partner. Via a brainstorming workshop (see Section 3.2 for details), the following four requirements were identified:

• R7 Integrative: A user-based relocation system needs to function smoothly when integrated with existing digital infrastructure.
• R8 Customers’ Retention: User-based relocation must retain the number of customers and rentals and not drive customers away.
• R9 Accessible: The relocation system must be easily accessible to the user.
• R10 Usability: The app must be user-friendly to ensure user engagement.

R7 addresses the challenge posed by the already existing carsharing infrastructure. During the workshop, the carsharing providers explained that they already operate a complex network of systems for renting, monitoring, and billing. Altering existing systems and APIs requires considerable effort and often incurs high costs. Hence, a user-based relocation system should be easy to integrate and should not demand specialized and currently non-existing APIs.

R8 also requires the artifact to decrease the number of customers and rentals or reduce customer satisfaction with the service. The service should not be hindered or limited by the app—for example, by making user-based relocation mandatory. In contrast, customers should be convinced of the app’s value through its provision of beneficial use for the user (e.g., monetary incentives and better vehicle distribution) and should thus strengthen customer satisfaction and loyalty.

It is necessary to provide an understandable context (R5) for the user and create an easily accessible app to achieve R8 and develop a successful user-based relocation app. Therefore, R9 calls for easy accessibility to the app in order to keep entry barriers as low as possible. In alignment with these requirements, R10 further requires that the interface is easy to understand and provides a straightforward dialogue between the user and the system.

After the requirements were successfully gathered in the workshop, the logical, sequential step was to gather technical knowledge in the following rigor cycle, addressing the challenges of implementing user-based relocation. To ensure a device-independent development, we used the Ionic web framework. For machine learning functionalities, we used the state-of-the-art library scikit-learn [50]. We ensured ease of backend implementation by utilizing the web-application framework Ruby on Rails. To guarantee the highest possible usability for users, we followed the DIN standard “Ergonomics of human-system interaction” [51].

The developed app itself is illustrated in Figure 3. The process within the app follows the previously developed concept (Figure 2):

• The user gets into the vehicle and starts the app on the smartphone.
• The destination station and the time of arrival are transmitted via a form. Furthermore, the vehicle’s QR code is scanned so that the app knows which vehicle is rented.
• The app can send a request to the carsharing user during the trip. The request includes the new destination station (which is near the original station, including the distance (in kilometers) to the original destination) and the monetary incentive (e.g., EUR 3). The app also analyzes if the app user is currently driving the vehicle in order to avoid the danger of traffic accidents. If the user is driving, the app will request that the customer stop the vehicle and then consider the relocation request.
• The user can decide whether to accept the request, demand a higher incentive, or decline the request entirely.
• Once the user has accepted, the app awaits its arrival at the new destination.
• The user confirms the arrival at the destination station. The app verifies the information by comparing the GPS coordinates, scanning the QR code again by the user, and registering the returned vehicle at the station.
• The monetary incentive is then credited to the user-based relocation user and counted towards a new booking at a later date.

For the incentive, a regression tree was implemented and initially trained with survey data [45]. Its automated learning capability bypasses the need for manual adjustments of the computation algorithm and avoids offering incentives that are too low or unnecessarily high. It also covers context-sensitivity, thus considering external factors (such as weather, relocation distance) that influence the decision-making process of the users [45] (R3).

For evaluation, we first executed a functional testing [41] of the app and related backend, discovering and fixing any bugs in the process. With the provider and selected customers’ help, some opportunities for process improvement were identified and implemented. For example, the previous process required the scanning of the vehicle for identification by barcode and license plate number selection. This step was replaced with a single QR code scanning that transmits the indicator directly. The second iteration concluded with the fully developed user-based relocation app, which was fully aligned with the provider’s requirements and feedback from the first potential users. Prototypical interfaces of the app are shown in Figure 3.

4.3. Evaluation

Artifact evaluations should be performed as close as possible to their intended field of application [42,47]. Accordingly, the mobile user-based relocation app was tested in a field test, which began in March of 2017 and ran until the end of August. The app was offered via the Google Play Store to customers (R9). The provider sent out information about the field test via newsletters and positioned advertisements in invoices and the vehicles themselves to engage as many people and customers as possible through the app without losing existing customers. The local university also promoted projects, as many employees were carsharing customers. The advertisement text focused on benefits for customers and illustrated the purpose of the concept. The download was indicated via a specific link, a QR code, and a Google Play Store logo (R8). During the three-month running time, a total of 74 installations by carsharing customers were recorded. The mobile app collected rental and user demographic data from customers who chose to share their information.

From 74 downloads, 62 people used the app at least one time. In general, the overall participating ratio (starting the user-based relocation app) was four times per user, ranging from one to 12 times. Overall, the user-based relocation app requested a total of 19 relocations, of which 11 were accepted and performed by users (R6).

The average incentive for a 0.85 km relocation distance was EUR 2.70, and the average amount for a 1.5 km distance was EUR 4.30, which are below the costs for operator-based relocation [4] (R3). The average rental within the carsharing system costs around EUR 15. Hence, the offered incentives constitute a 20% discount for a regular customer. Based on our consultations with the carsharing provider, this level of discount is appropriate. However, this assessment is highly context-dependent. In the end, the profit margin and costs for operator-based relocation of the carsharing company are decisive.

The small number of relocations found to be required could probably be explained by the fact that the carsharing provider chose to remain risk-averse by continuing operator-based relocations every morning to balance the system. Thus, unfortunately, R1 and R2 could not be fulfilled entirely. Furthermore, cost reductions through user-based relocation are highly dependent on the performance of relocation algorithms, incentives, user participation, and individual costs of operator-based relocation [4]. Hence, we were unable to evaluate cost reductions in our field test, prompting this evaluation for a larger scale field test.

Some users submitted critical feedback via a survey and the contact form. For instance, one frequently stated disadvantage was that the vehicles could not be booked via the app. However, this was caused by the system’s design, which was developed to be independent of the highly standardized IS of the carsharing provider (R4 and R7). This indicates that future user-based relocation functionalities should be a fully integrated part of the carsharing system and not added as an independent component, making technical implementation more challenging. The necessary level of ease-of-use was achieved because several users could use the app within its scope without any issues, and all content was understandable (R6). Relocation requests were only triggered when the number of vehicles at a station was below the defined threshold (R2, R3). Users could accept or decline relocation requests offered in the mobile app (R5, R8), which served as an IS interface (R4, R7, R9, R10). Relocations were only requested for distances between 0.85 and 2.2 km (R3), and the system used real-time information from the carsharing provider. All triggered relocation requests promised discounts (R5). However, the user base decreased drastically during the field test (from 43 active users in the first two weeks down to ~30 in week three and down to below 10 for the remaining field test). Based on the provided feedback, the users stopped using the app after not receiving a relocation request in multiple instances. This leads us to two conclusions: (1) The number of user-based relocations must be higher. This could be achieved by orchestrating user- and operator-based relocation to decrease the frequency of operator-based relocation down to only the most necessary ones (e.g., relocations unlikely to be performed by users). (2) There is a need for some form of user engagement when no relocations are needed, e.g., requesting unnecessary relocations or incentives for starting and running the app (e.g., being ready to perform a relocation).

5. Discussion

The presented DSR process employed various methods, including literature reviews and expert interviews, prototyping, functional testing, and real-world field test. Despite preparing the field test carefully with guidance from extensive consultation, the knowledge base, and carsharing providers, we were unable to implement a sustainable user-based relocation app. After only three weeks, most of the users removed the app from their smartphones, ending their participation, leading to an overall low volume of performed relocations before the field test ended. The field test implementation and evaluation environment (e.g., the specific carsharing system) is now “scorched earth.” Users will not use and trust a user-based relocation app again because of the perceived low usefulness and ease of use. Nonetheless, the field test provided fertile ground for discoveries, fueling future research, as this study is the first one that attempted to implement a user-based relocation app in a real-world scenario, taking the first step from a theoretical concept to applicable design. Overall, the context of user-based relocation provided some unexpected and unique challenges, indicating the need for further refinement and improvement.

The newly discovered challenges represent important findings for future research. Other researchers interested in implementing and evaluating user-based relocation via field tests can learn from the results of this study and prevent similar “mistakes”. This DSR project failed to successfully develop and evaluate a user-based relocation IS in its application environment, e.g., a carsharing system, because of several assumptions made. To summarize, the main misassumptions are as follows:

(1) The parallel execution of operator-based relocations does not jeopardize the user-based relocation process. The user-based relocation system had not enough relocations to request because operator-based relocations reduced the overall need for relocations. Hence, the implementation of user-based relocation needs to be coordinated with operator-based relocations, prompting the risk of a carsharing provider having suboptimal vehicle distribution.

(2) Customers are willing to use a separate app for user-based relocation. The goal of this research project was to develop a user-based relocation IS that can be implemented in conjunction with the existing digital infrastructure of a carsharing provider. However, customers are reluctant to add an additional app to their smartphones, and integration into an existing carsharing app would increase adoption and the complexity of implementation.

(3) Users are sufficiently motivated by offering monetary incentives. The app was not engaging enough to motivate users to participate in user-based relocation. Besides the rare case of a requested relocation, the app did not provide any reason to use it. This makes users perceive the app as not useful because it did not provide any form of engagement and motivation to use it and wait for a relocation request.

Thus, due to the relevance for the current growth in vehicle relocation research, despite publication bias toward significant and positive findings, we find it particularly important to publish these “negative” results, adding to the knowledge base [52]. In sum, the contribution of this research includes the discovery of previously unknown challenges for user-based relocation, the provision of a deeper understanding of value co-creation and co-capturing in carsharing service systems, and the provision of solution approaches for some of the stated challenges, e.g., to engage logged-in users during low relocation demand times, which can lead to additional, previously unknown costs.

Furthermore, the findings of this study have implications for the field of sharing economy research. Carsharing is recognized as a prime example of the sharing economy [2]. However, areas of opportunity to support carsharing service processes are still in need of more research [1,2]. In this regard, the presented development process and artifact unravel how IT and IS facilitate the provision of sustainable sharing services and value co-creation in collaboration with customers. The position-dependent value of carsharing vehicles provides a rich environment for customer participation, e.g., sharing time and effort to increase the overall value of carsharing by improving the vehicle distribution cooperatively. An implemented user-based relocation system can increase the sustainability of the mobility service by reducing unnecessary relocation trips. Thus, this research also contributes to the area of sustainable mobility services.

In the following section, we will discuss the limitations of our study. First, the user-based relocation app was evaluated within the carsharing system of one German station-based one-way carsharing provider because of their stated interest to test it. However, the user-based relocation app and the lessons learned from the field test provide a basis for future research in other carsharing contexts. For example, implementing user-based relocation as an on-board-system, within a holistic carsharing app, or in a free-floating carsharing system provides valuable grounds for learning more about the design. Specifically, free-floating carsharing can be seen as a system with a nearly unlimited number of stations (or locations/areas).Hence, approaches are transferable when adapted accordingly. Second, the study was conducted in one European country, inherently limiting its cross-cultural and geographic generalizability. In order to confirm the proposed user-based relocation app, the influence of cultural differences, diversity of software standards, and market conditions should be addressed by future studies. Third, the knowledge base represents a restriction since it consisted of literature considered sufficient for artifact development. However, other fields of research could also contain valuable knowledge for future developments.

6. Conclusions

This study addresses the novel approach of user-based relocation in carsharing systems. User-based relocation enables value co-creation and co-capture within a carsharing service system. However, current research and practice have not addressed how to implement a user-based relocation mobile app. Motivated by this research gap, we engaged in a DSR process and developed a user-based relocation app in multiple iterations, escalating from expert and user interviews and literature reviews to a real-world field test [46]. This study contributes to bridging the research gap by providing design knowledge for user-based relocation app development and an initial exploration of a user-based relocation app in a real-world context. The results of this study provide a valuable reference point [52] for future research as they revealed novel challenges, requirements, and principles of form and function [53]. Hence, in the spirit of DSR, this study constitutes the beginning of an iterative search [41,42] for the design of user-based vehicle relocation IS.