top of page
Rental Reminder, an SMS conversation by SmartAction
Designed for: Penske Truck Rental
Note: some information is hidden for non-disclosure purposes
Penske Truck Rental is geared toward large, multi-location/multi-day moving trips. In the days leading up to such a big move, the last thing someone wants to worry about is their reservation falling through. A confusing or poorly made confirmation process can cause such a scenario. At SmartAction we implement AI to make such processes simpler.
When a Penske customer has a reservation coming up, they need to send a text message to confirm reservation details. This would enable Penske locations to set aside the necessary vehicles and applicable equipment. The existing bot was seeing low finish rates, hovering around 30%, and we had to analyze why.
Project success: increase containment rate and self service rate among rental confirmations.
The first question we had to answer; why was containment low?
As a conversation designer data is at the heart of everything I do. Numbers never lie, and if we can identify the correct numbers to analyze we can remove or limit mistakes, human bias, etc.
Finding patterns in data is a useful means of analysis. In reviewing the previous bot, we found users were dropping off at fairly random intervals. There was no single prompt or bug that ended interactions. In this case, the pattern we looked for did not exist. In short, the bot was too long.
Depth vs Simplicity
The existing bot was very thorough in its functionality. Users could customize just about every aspect of their rental. But thoroughness does not always provide a good user experience.
Stress should always be minimized by technology. Days before a cross-state or large move is a highly stressful time. The previous solution involved sending bits of the rental information at once, allowing a back-and-forth interaction for users to customize their pickup and dropoff details. Only when this process is cleared could users edit equipment and other aspects of their rentals. With so much going on in their lives, would users want to spend time texting a bot back and forth going over every detail?
According to stakeholders, we knew the majority of users were on smartphones. Most modern smartphones could condense multiple messages into one, allowing us to break the traditional 160 character limit.
A solution was born
Knowing the previous bot was far too long, and knowing we weren't concerned about the standard SMS character limit, the solution became rather simple. Let's send users a single message with all the important rental information. If they wanted to confirm, great! If they needed to make an edit, the Penske website was a quicker and snappier solution to edit multiple fields of data instead of SMS.
As always, there were hesitations.
For an outbound SMS, would such a long message come off as spam to a user? There's always the risk, but in this case users had opted in when they reserved a vehicle. They knew an SMS would come.
What about leaving off smaller details like equipment rental? For me, this was very much a case of trusting the most knowledgeable stakeholders. Penske knows their business far better than me, and understanding this was the most important information and all they needed to confirm made sense. Furniture pads and dolleys are not in short supply; trucks are. We needed to get the vehicle set for the customer, the rest should not interfere with that goal.
An unusual process
Bot and user personas are a beneficial part of every design. Going in, we knew our customer base: people moving long distances and stressed about it. Our focus was on the move itself. If families had separate arrangements for getting everyone to their new home, it was outside the scope of a rental confirmation.
Our bot persona, reflecting how we wanted our new bot to interact with renters, needed to be kept simple. When sending an outbound SMS, every character counts. Keeping our bot clear, concise, and professional helped get renters confirmed and on their way.
In researching the previous bot, we knew a bot persona could help improve writing in the new one. But when push came to shove and we decided just how condensed we wanted this bot to be, and under time constraints, we knew it wasn't feasible to plan an entire personality. We had already decided simplicity would overtake depth, and that philosophy remained consistent.
Note: visual personas are not included for non-disclosure purposes
Good design is collaborative. Good launches, too
"Everyone has a plan until they get punched in the mouth" - Mike Tyson
Go-lives can be challenging. New API's, new software, uncertainty in the final product. The planning was in place and the bot was ready to go live. But with so many new systems and technologies in place, we made many new discoveries along the way.
In designing this bot, I highly valued input from Penske and SmartAction stakeholders. In launching the bot, that same philosophy came to the forefront. From engineers to PMs, we knew challenges should be tackled together with clear communication. While I am no engineer, I can work alongside one to answer questions they have about the design, the plan, Penske, or anything else. If I can't answer a question, I can find someone who can. Assisting developers into go-live and beyond meant leveraging my knowledge of Penske's confirmation process to stop weeks-long Jira tickets before they begin.
Numbers never lie
Finally the bot had launched live. In the initial rollout, as is our standard practice, we handled hot fixes and minor improvements. Once we started collecting interactions after hotfixes, we could finally assess how the bot performed.
On an average day, the bot receives an average of 50% containment, an increase over the previous bot's 30%.
But this doesn't paint a full picture. Under the old system, if users were dissatisfied they were given a number to call into. But we now refer them to the website first, meaning the overall self service rate is much higher!
On to the next one
Penske has other mechanisms for rental confirmations. SmartAction works closely alongside Penske and has other bots that will be rebuilt and improved upon following the success of this one.
For this SMS bot, we will continue to analyze performance and find trends that lead to improvement. The timeout setting contained much internal debate. But there's always a second layer to peel back.
Instead of how many users reach timeout, we instead look at how many users are almost reaching timeout. For example, say 5 percent of users hit timeout. But of the other 96%, only 1% come within hours of timeout. This is far more valuable information than simply that 5%, as it gives us an indicator that those timeout users may simply ignore any communication, and widening the window won't necessarily pull them in.
Another example is not just if a user contains, but when. We'll analyze bot performance over weekends vs weekdays, holidays vs working days, etc. If numbers are heavily skewed based on times, alternative solutions will need to be proposed to address any shortcomings.
bottom of page