Alamo Roadside Assistance
How can we integrate a business partner's unique processes into our roadside assistance platform?
Omni is Allstate's call center web application for roadside assistance. It's used by rescue associates (RAs) who collect disablement information from stranded drivers. Over the course of a month, my design pair, Lucien, and I were tasked with on-boarding Alamo Rent a Car's rescue flow into Omni. We did this by interviewing stakeholders & users, contextual inquiry, and multiple rounds of usability testing.
Omni is a call center web app developed for Allstate Roadside Services. Various businesses partner with Allstate for a white labeled roadside experience. Through Allstate's line of business and partnerships, there are over 2 million rescues per year. Omni was created to replace the legacy software, MMA.
Omni continues to roll on new partners, which is where design comes in. Each partner has unique business processes. We have two main goals 1) continue to roll out core features needed across all partners and 2) build out the unique partner processes without over-customizing.
My design pair, Lucien, and I worked on integrating Alamo Rent a Car's rescues into Omni.
MMA - legacy software
Omni - new, shiny software
During kickoff for Alamo's move to Omni, I learned from our Product Manager that call time for Alamo is much higher than average. An Alamo call takes nearly 20 minutes where as a normal call takes 9 minutes. To understand why, we met with internal business stakeholders. We had them write down all of the pain points they could think of and then prioritize them through dot voting.
.png)
.png)
Stakeholders helped us understand why Alamo is a unique roadside partner.
We learned that many of the pain points were inherent to the partnership. Every rescue was very situational. There would be no one-size-fits-all solution to Alamo's roadside events. We also learned about an email process the RAs use that included filling out a template in excel and then emailing a rental counter. They did this every time a customer needed a new rental vehicle. This immediately seemed like something we could help automate to reduce call time.
Our next step was to go onsite to a call center and talk with RAs to learn more about their processes.
We (Lucien, two developers, Omni's technical product owner, and I) went to a call center in Largo, FL. Lucien and I prepared various concepts for non-tow services and set aside a time to observe RAs taking calls.
Observing Alamo RAs in Largo, FL
From our observations, we saw first-hand how many applications the RAs have to use during any Alamo rescue. They toggle between six applications for a simple call, potentially up to 8 or 9 if the call becomes more complex. To make matters worse, these apps live in two separate Citrix Receivers—and there's no way to copy and paste information between the two.
We also saw firsthand how they would toggle to Excel to fill out the exchange email we learned about from the business stakeholders.
.png)
Multiple applications split across sceens and Citrix Receivers.
We took the site visit as an opportunity to test the flow for non-tow services. There were a few minor changes we needed to make to our standard flow for Alamo that we wanted to gut-check. After the tests we interviewed RAs about how they set up tows in MMA.
On-site testing and interviews helped us understand the different types of tows for Alamo customers.
We learned that there were four types of tows: two-way tows, ride-along tows, exchange tows, and disablement tows. At the time Omni only handled one type of tow. So Lucien and I's main challenge was to figure out how to handle multiple tow types elegantly.
The four tow types and the drive-in exchange process sketched out.
We turned to our dev team to help us generate concepts. We wanted the experience of setting up tows to be seemless for the RAs but we didn't to create a nightmare for our dev team. We gathered in a conference and I presented the prompt to two devs, the technical product owner, and the product manager. We time boxed 10 minutes for sketching and then debriefed.
.png)
The product manager sketched out an idea for an exchange service type that would auto-email rental counters - rather than the RAs having to fill out a template.
.png)
A dev sketched out an idea to add location types depending on what type of tow was needed.
Our main takeaway from this exercise was that users would need to indicate on the tow type on the service card. This would populate the number of location fields on the next card, giving the users a more seamless experience. From this, Lucien and I defined two concepts: (1) users could determine the type of tow through a series of questions and (2) users could select the tow on a dropdown.
For concept (1) added new probing questions to the service card. Depending on how the RA answered the questions the number of location fields needed would populate on the location card.
For concept (2) we had the RA select the type of tow at the top of the service card in a dropdown. During testing, we needed to see if the RAs would know what type of tow was needed this early on in the call flow.
We tested the concepts remotely with eight users. Through testing we learned that RAs had a high level of confidence with both concepts. After each prompt we asked them how confident they were on a scale of 1 to 10 that they set up the tow correctly. Each concept was marked in the 8-10 range.
However, we paid attention to the language the RAs used when they described the experience. One RA said "The drop down would have been helpful as a newer RA because I would have learned the different tow types faster." Another RA told us that she liked the dropdown because "it tells me exactly what kind of tow you are setting up and give you exactly the right options of what you need to next."
Below are links to the videos of the prototypes we tested in Invision:
After deliberating with our PM, it becamse clear that we would go with the dropdown idea. It created more transparency and the RAs loved that the number of location fields auto-showed depending on their selection. It also had less conditional logic, simplifying the devs lives.
We made a few adjustments. We added a check box for "vehicle was in an accident" so we could auto-populate a list of auto-body shops in the Vehicle Disablement Dropoff field. We also changed the names for the tow types to match the RAs language.
Final Screens for Reverse and One-Way Tows
Final Screens for Two-way and One-Way Ride Along
After creating the design for Alamo tows, I questioned if our decision to keep two-way tows in one dispatch. During this process, we didn't consider how our existing technology would handle this more than two locations and pass it along to the tow truck providers.
Lucien and I discussed the possibility of breaking out each tow into two separate dispatches to avoid adding more than two location fields. However, that would have created terrible experience for the RAs.I think we created the best experience possible for the RAs and the benefit to them will offset any challenges the tow truck provider might face.
