Unlocking payment flexibility for long trips
Background
At the end of 2023, Turo's leadership communicated a vision for unlocking a new vertical of the business: leasing.
Turo's bread and butter up until that point was shorter trips, typically 3-5 days, and there were many barriers that would need to be solved across the company to start building towards this vision.
I worked on a pioneering team to start testing the viability of this new direction by trying to increase Turo's share of long-duration trips (30+ day trips), growth which would indicate that there is desire for more than just shorter multi-day trips.
Problems
When booking a long trip, guests would owe an enormous lump sum
When booking a trip which was 30+ days, the final total could end up in the thousands to tens-of-thousands of dollars.
Guests at this point essentially had two options:
- pay that entire amount now (their trip might still be weeks or months out)
- defer payment until a week before the trip, but still have to pay the entire amount at once.
In either case, it was clear that this financial burden was a substantial blocker for guests who had intent to book a longer trip.
Project goals
Boost the shares of long-duration trips on Turo by offering payment flexibility
Instead of one large multi-thousand dollar payment, offering guests the ability to pay over the course of their trip could make the idea of a longer trip more palatable.
Key metrics
10% growth in paid days from multi-month trips
Project definition
Outlining viable surface areas
Our team worked to define which surface areas of the product would need to be involved in order to ship an MVP of this experience. Laying out the funnel, we decided these areas would be sufficient to create a viable but time-efficient release:
Buckets of work and assignment
The surface areas highlighted above broke pretty neatly into two categories:
- pre-trip experience of introducing and highlighting the feature
- on-trip experience of being notified about charges, as well as cost-altering actions which would affect the payment plan.
On this project, I collaborated closely with another designer, Phil. We decided to split the work cleanly in half along these categories to make the best use of time.
Notification strategy
Leaning on existing frameworks
A core piece of the on-trip experience would be the notifications sent out around payments, giving guests a heads up as well as an opportunity to pre-emptively correct any potential payment failures (adding funds to their account, etc.)
Guests would be billed monthly, and the charges would occur 1 week before the next month of the trip began. This created a 1-week buffer where we could work with the guest to remediate any potential payment failures while the trip was still fully paid for by the previous installment.
We mapped out our notification strategy to match this model.
Handling extreme edge cases: no remediation
In the case that a guest was notified of a failed payment but took no action to remediate, we needed to know what next steps would be based on the stage of the trip. We outlined and reviewed the following, getting executive buy-in, for if payment failure was not fixed for the first payment, or for any subsequent payment.
Refining through multiple rounds of review with content team
There were a lot of notifications to handle, and we wanted to ensure our tone and voice were consistent throughout. Partnering closely with our UX writer, Yvonne, we made sure that our suite of communications were clear and contained the right information that would be pertinent to our guests at that point in time.
Testing
In the case of more extreme edge cases, such as trip shortening, we wanted to test our messaging with guests and hosts to ensure it was coherent and that we were answering any questions they might have at that point.
Handling cost changes
Importance of visibility
After the booking was complete, the initial payment plan would be created based on the initial total. However, a guest could make changes to their trip which would alter that value and subsequently affect their payment plan.
In these situations, our primary goal was to make sure that the guest was fully aware of how the change in price would affect their payment plan to reduce confusion and ultimately reduce potential support calls.
Mapping cases where costs might change
We mapped out the flows and cases where a guest might trigger a change in the cost of their trip.
Each of these flows ended with a similar 'instance' of the checkout experience, so whatever solution we created would need to play nicely with that screen.
Concept #1: dedicated section
We tested multiple concepts using interactive prototypes.
The first concept attempted to create a new section within the checkout instance which provided guests with a high level overview of key information (the next payment, the date of that payment) with a button which guests could use to access more detailed information about how the payment plan was changing.
This did not perform well in testing, with many not clicking the button to view the updated payment schedule and thus misunderstanding how their future payments would be impacted.
Concept #2: merging into the 'total' box
A second concept sought to better connect the updates to the payment plan with the 'total' box which contained the amount due at that point in time. This stemmed from comments from the previous test, where it seemed guests were confused whether the amount owed and the changes to the payment plan were separate things, or if the concepts were connected.
While performing better than the first concept, the results were still poor when it came to participants clicking in to view the full payment schedule, and subsequently lead to them providing inaccurate descriptions of how their subsequent payments would be affected.
Concept #3: separate full-screen takeover/modal
Since both previous tests were unsuccessful largely because participants failed to tap in to view the update payment schedule, we decided to 'force' guests to see the schedule by showing it as an interstitial screen before the trip change is fully submitted.
This performed very well, with participants taking the time to review the details of the payment plan and what had changed. This lead to great post-task recall and gave us confidence that this experience achieved our goals.
Review with engineering team
We presented the results of our testing with the engineering team and shared our proposal for moving forward with concept #3.
The team was enthusiastic, as any change to the checkout page to handle one-off cases was difficult and hard to maintain. By keeping the changes isolated to a separate view presented after checkout, we would save time in implementation and regression testing, as well as make the overall system easier to maintain in the future.
Breakdown of final designs
Notifications
Flow: remediating a failed payment
Flow: modifying a trip
Outcomes
Metrics
Resulted in an ~8% lift in paid days within the multi-month segment (underperformed against goal)
Analysis and next steps
In analyzing the data, it seemed that the 30-60 day trips were drastically underperforming and under converting with the new experience.
Initial hypotheses were that the experience presented in checkout was optimized for 2+ month trips, displaying the monthly price as the key incentive. However in some cases, this may have looked to guests like they would end up paying more than if they just paid upfront.
Explorations are underway to see how altering the presentation to this segment of guests might help move results closer or above our initial goal of 10% lift.
Whew, that was a lot! You know, we could go much more in-depth on a call 👀
Guest checkout experience
Context: offering installment payments
Phil was focused on this aspect of the project, so I can't take credit, but I wanted to share an overview of the finalized experience for context on how the guest initially opts into a payment plan and what information they were made aware of.
