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.
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.
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.
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.
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.
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.
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.
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.
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.