UPDATED LEGACY UI | B2B2C
Improved usability of ticket management process in order to reduce ticket completion times by 20%
Contribution
Sole designer on team
1 Designer ⚫ 1 Product Manager ⚫ 1 Engineering Manger ⚫ 7 Engineers
As the sole designer I led, planned, and executed all of the
discovery research
design system management
iterative prototyping
user testing
engineering handoff
BUSINESS PROBLEM
A slow system for ticket routing was causing guests to check into vacation rentals that were dirty and unsafe
As the leading rental management company in North America, Vacasa was trying to do what no one had been able to successfully do: scale. The difficulty in scaling property management is that you lose a “local touch” which is integral to handling the chaos that happens every day between the 10am checkout and the 4pm checkin. At some point during scale, there began to be more and more missed issues, resulting guests checking into homes that weren’t quite ready for them.
DISCOVERY
Executed generative research that uncovered why these issues were slipping through the cracks
Looking into some of our Tableau data, it was easy to see the higher the ticket completion time in a zone, the more likely that zone would miss big issues prior to checkin. We also saw these correlations between higher ticket completion times and missed cleans, lower NPS, and more churn.
In a 120 person survey, I learned that if tickets were not urgent, their staleness was warranted. But if they were urgent they were likely sitting in the queue of someone not working.
Anytime we saw the ticket completion times go up, we also saw missed issues go up. We weren’t concerned if the increase in tickets were a result of waiting on supplies, and there wasn’t much we could do if there were other higher priority tasks to take care of. What we saw though, was that nearly a quarter of overdue tickets are the result of tickets sitting in the queue of someone who is not working.
During 12 user interviews, I learned that tickets ended up in the inboxes of people who were off because of inefficient routing logic.
Of these tickets that ended up in the queue of people who were off, almost every person I spoke to referenced the “auto-assign” giving them tickets when they weren’t working. This was because the current assignment operated as a “bounce back” where anytime coverage failed, it would simply bounce back to the original person. Unfortunately, this happened the day of and didn’t give any advanced notice.
These interviews also uncovered a deep sense of mistrust that the users had for the tool they were using every single day
Most shocking was our users telling us that they felt like they hadn’t a day off in a year because they were constantly worried about the “wrong tickets” getting into their inbox while they weren’t working. The routing was basically like a black box and they didn’t know until a ticket was assigned, where it would actually go.
Users were quick to point at their colleagues and call the problem “user error” but a quick look at the tool revealed a complete lack of basic usability that was nobody’s fault.
Many of the users believed that customer service was “overriding” the assignment that our users put into place. They believed this because they would mark a person as their coverage and then still receive a ticket. When they checked the system, they would see that they had successfully marked someone so it must be customer service who is overriding this, right? Unfortunately what they saw as a “successful coverage” was in fact a failed coverage.
I was able to summarize my discovery into 3 primary categories that we could address in order to reduce ticket completion time, thus reducing guests checking into homes that weren’t ready.
This categorization focused on what we had the most control over in product and could deliver on with a quick time-to-value.
01
The existing automation for routing was useless
The existing routing would “bounce back” to the creator if the person they requested was busy. This is despite other people being available and capable of helping. This could result in a ticket sitting overnight.
02
It was difficult to recognize that a routing mistake had occurred
There was nothing in the tool showing or alerting someone if their coverage was set up in a certain way or if they were set to receive someone else’s tickets. People typically wouldn’t realize they were covering someone else until it was an emergency and they had 3 sudden tickets and 4 missed calls.
03
It was difficult to fix routing mistakes once they were spotted
Even if someone was able to recognize that coverage was set up incorrectly or that the routing wasn’t as expected, it was still an extremely arduous process to fix what was apparently broken.
PRODUCT SOLUTION
I addressed the 3 biggest friction points that prevented lower ticket completion times
01
Made automation useful.
Now, even if tickets get assigned to someone who is not working, the system would try to assign it to other people in the zone who are working, before ending at the manager. In this way, people were no longer getting tickets while they were off.
02
Made it quick and easy to recognize routing errors
Should a mistake be made, it was easy to recognize the mistake and know what needed to be done. Where there were previously zero indicators of incorrect coverage, there were now 4 key areas that were showing what the coverage result was.
03
Made it quick and easy to correct events or set up new events that are correct
The new coverage creation tool was moved into their most common app and loaded instantly. Additionally, we removed unnecessary inputs.
EXPLORATIONS
The idea graveyard incubator
For every idea that was delivered, there were multiple ideas that, for many reasons, never made it out the door.
I believe that a large role that design plays is in mitigating risk for the business. We want to explore ideas before they are impacting all of our users and before they cost us a lot of money. In this way, many of my ideas were discarded or “backlogged” without ever making it to production. With a little bit of a “yes/and” mentality, these early ideas helped lead me to the final solution.
🧠 Idea: Allow for quick scrolling through dates to get to future date
Based on earlier research, we knew that users were often checking their calendars 6 months in advance. The initial solution was a quick scroll.
❌ Rejected: Engineering brought up API constraints
Unfortunately this idea ran up against an API constraint. For now, we are using chevrons but we have also backlogged a date picker that can jump to any calendar day.
🧠 Idea: When deciding criteria for “inspection assignments”, we assumed 8 hours would be okay
When we originally decided criteria for inspection, we were thinking in terms of how long it would take to do 3 daily inspections. With each inspection taking less than an hour, even with a long drive, we figured 8 hours would be enough time to get the inspection done.
❌ Rejected: The pilot group informed us that they were getting 1 AM inspections!
People were being assigned visits anytime they had an 8 hour shift, even if that shift was an on-call night shift! We adjusted inspection criteria to only be assigned during day shifts.
🧠 Idea: Represent all daily events on the date picker
Since failed requests were important issue that needed to be resolved by our users, I wanted to give them as much heads up as possible when it occurred.
❌ Rejected: Dots were not accessible or fitting correctly
I explored representing every event on a date card but found that the “dots” were too small and hard to read. Additionally, there could only be a max of 3 but our most common “issue” occurred when there were 4 or more events.
WRAP UP
Conclusion
Impact
Improved ticket completion time (leading indicator of missed issues)
Improved CSAT for vendors (lagging indicator of NPS)
What I Learned
Understanding business is key. When the business first came to us about this problem, they wanted us to create an “escalation” feature because of how often tickets went into the queue of someone not working. We agreed to this but also proposed that we fix the problem at the source which they didn’t realize product had power over. It was through building trust and partnership that this project was able to succeed.