Automating the billing of post-trip recharging
Background
Roughly 90% of the electric vehicles (EVs) listed on Turo are Teslas.
When a guest is rents a Tesla on Turo, they will are expected to return the car with roughly the same battery level as it started with, just as you might at any traditional rental car company. If a guest doesn't, the host can invoice the guest for post-trip recharging: a fee which covers the cost of the recharging and the time it took the host to do so.
By this point in 2023, our team had automated 2 of the 5 "incidentals" (invoiceable charges) to reduce the burden of collecting and filing evidence on hosts, as well as saving the company money in reduced support costs associated with reviewing manually created invoices.
The plan: leverage the same Tesla API that we built a connection with earlier in the year (read here, if you haven't!) to also automate how hosts invoice for post-trip recharging.
Project goals
Increase host efficiency when invoicing for post-trip recharging
Through the integration with Tesla's Fleet API, we could pull data on battery levels at relevant times to reduce the burden of providing evidence.
Since these transactions would be from a verified source of truth (Tesla), hosts could forego collecting/providing receipts and avoid potential math errors.
Reduce support costs associated with invoice review
Similar to the host benefit, any invoice line items which were automatically pulled from Tesla could be deemed as 'pre-verified' and thus would not need a full review, allowing agents to focus on reviewing other aspects of the invoice.
If an invoice were to contain ONLY pre-verified transactions, it could be automatically adjudicated by the system and not require manual agent review at all.
Key metrics
Primary
60% of all EV-related invoice items automatically generated across the business
Foundational discoveries
Existing page for handling post-trip recharging was needlessly long
In reviewing the existing screens for this process, we discovered a lot of redundant copy which needlessly extended the content of the view. We identified this as an opportunity to potentially simplify the presentation to save space and reduce cognitive load.
Legacy tech debt for entering battery levels created inaccurate data
Post-trip recharging required the host to account for both the starting and ending battery level, which could be entered during the 'check-in' flow: a set of steps available before a trip starts where the host documents the car's condition ahead of handoff.
Despite EVs being able to display a discrete battery percentage (i.e. 80%) which could be handled via a numeric input, 'check-in' asked hosts to enter battery level via a fractionally incremented selection (choosing between fixed fractional values, such as 1/2 full or 7/8 full).
This was likely a result of tech debt: the field had been quickly reused from how we handle the input of fuel level for ICE cars. This lead to huge inaccuracies in our data, causing misrepresentations in battery levels between input and reality.
Policy around post-trip recharging was inconsistent
We were initially tipped off to this through a message in Slack, where an employee host asked about some details of the post-trip recharging fee. Through commentary from operations staff and executives, it became clear that the policy was poorly written and was being interpreted differently by different parties.
Upon further investigation, we also found that the policy was being messaged differently to guest and host, resulting in mismatched expectations around how the car should be returned.
The arbitrary nature of the current policy also lead to inconsistent and unfair ruling when these charges were being reviewed by support staff: some hosts would get away with overcharging guests, while some hosts were denied charges for what they felt followed the policy.
What was wrong with the policy?
Guests were told they needed to return the car with around the same battery level as it started, but hosts were told that as long as the guest brought the car back with less than 80% battery, they could be charged (even if they didn't deliver the car at 80% battery).
This lead to situations where the guest could receive the car at a lower battery level (60%), do their best to return the car at that same level, but still be charged because it was below 80%. It was unfair to guests, but was flying under the radar.
In addition, there was an additional line in our Help Center which was totally unclear, but lead to some hosts getting away with charging their guests for even more.
Rewriting policy
Workshop and alignment with operations team
Given what we were finding about the shakiness of the existing policy, we held a series of workshops with our operations team (who owned this set of policy) where we presented the inconsistencies we found and worked together to come up with a rewritten policy which would:
- be fair to guests and hosts
- be clear to understand
- be automatable (in order to meet our project goals)
New policy
Instead of anchoring on 80% battery as the minimum to be returned at, the new policy would take into account the difference between starting and ending battery level, with fixed tiers of costs depending on how great the difference was.
Visible convenience fee
Past feedback around the policy was that there should be a $10 convenience fee, similar to what Turo provides when a host charges for standard refueling. According to operations, this convenience fee was baked into the previous fee tiers, so hosts weren't aware it existed.
In the new policy, we separated out the convenience fee so it would be explicitly called out for hosts instead of invisibly baked in.
Mid-stage
Fixing check-in and check-out inputs
Accurate battery level data was important to our new policy, so we planned to swap out the legacy selection inputs with numeric input fields.
Rebuilding the manual flow
Since this new policy would completely change the way we handle this invoice item, we started by rebuilding how the manual flow would be handled.
Instead of selecting from a set of fixed radio tiers, the host would instead enter a pre- and post-trip battery level (gathered during check-in and check-out) which would display the difference between them and what amount could be charged (plus the convenience fee!)
Hosts would be able to easily access a breakdown of the fee tiers by tapping on the row which showed their calculated battery difference.
Concept for automation
We explored a concept to provide hosts with as much flexibility as possible when filing for post-trip recharging. On top of the automated values that pulled in via the API, there would still be manually values entered by both the guest and the host during check-in and check-out.
By presenting the host with a suite of options based on all the different battery levels entered by various parties, we thought it would enable hosts to make the best decision. Through testing and review with our engineering team, we axed the concept due to cognitive overload with too many presented options and higher scope for technical implementation.
To simplify, we instead would pre-fill the battery levels we pulled through the Tesla API, indicating through subtext to the host at these were generated from Tesla.
As long as these values were used, the host would not need to supply photo evidence and could quickly continue to send the invoice to the guest.
If the host disagreed with these values, they could override them through the inputs, though they would be subsequently asked to provide evidence for that battery level so that our support team could review and provide a ruling.
Testing with prototypes
As previously mentioned, we vetted our concepts with hosts to get their thoughts and feedback, helping us to define our final direction.
Finalized design flows
Flow: inputting battery levels at check-in and check-out
Flow: manually filing for post-trip recharging
Flow: reviewing automatically generated post-trip recharging
Outcomes
Metrics
A few months post-launch, 61-62% off all EV line items are automated.
Annualized support cost savings of $160k - $240k.
