Or shall we say -- the opportunity.
SpotHero has successfully parked over 20+ million cars, many through parking garage operators selling their inventory (spots) that would have otherwise gone vacant. As SpotHero grows, more and more customers rely on the app and website, and at the same time comes an increase in painful and roundabout parking experiences.
One of the most frustrating parking situations is when a customer shows up to their spot -- only to be turned away by the garage or lot due to lack of available spots. (How can this be, the customer asks). A common root cause of a "lot full" comes from garage operators either overbooking their spots (much like an airline may oversell flights beyond capacity), or due to unintentional mishandling of their inventory by not updating their SpotHero Control Panel.
My team (the Efficiency Squad)'s mission was to save SpotHero time and money, to which we assigned two KPI's respectively:
1) Average Handling Time (AHT)
By improving and streamlining our admin and internal tools, customer service representatives will solve customer cases in less time.
2) Calls Per Park (CPP)
By preventing customer contacts to SpotHero in the first place through upstream intervention on the consumer app + website, we save the company customer service resources that can then be dedicated to the backlog of cases.
Together, my Product Manager and I conducted focus groups with the customer service team in order to learn about the range of pain-points across their different types of cases (not just Rebooking). I then aggregated these pain points.
The next step was to prioritize which pain points our squad should tackle first in order to create the largest impact on reducing AHT or CPP. The prioritization framework we used was the RICE model, which we each did individually. Unfortunately, I can't disclose our RICE numbers.
After comparing our two RICE models, my PM and I agreed that focusing on AHT enabled us to be most impactful and better infer which pain-points are costing more time and money to the company.
The goal of Discovery for the Rebook project was to complement the existing "Initiation doc" written by my PM (product manager), which includes goals, constraints, and potential use cases to address. For me, the most important aspect of Discovery is to go in with the assumption that my existing knowledge and use cases can be completely overturned and disproven, and that there is always something unexpected to learn.
With this mindset, I decided to lead an affinity wall with my PM and design team.
I prepared post-it notes that included various quotes and ideas from our focus groups and customer service slack channels, such as:
"Customers know where they want to go but want to know all of the options"
(Left half) Affinity Wall v1, and
(Right half) Affinity Wall v2 with input from team members
After further analysis and synthesis from the affinity wall, I began noticing that certain pain-points affect certain workflows (i.e. types of customer cases).
Our hypothesis became:
If our customer service team adopted more intuitive Admin tools that matched their most time-consuming workflows, they will become more efficient, less stressed, and have more time to attend to our backlog of cases (and thus saving the company money).
Qualitative data from our focus groups and customer service slack channels asserted that Rebooking a customer (e.g. due to a "lot full") was consistently one of the most "stressful" and "time-consuming" cases. Quantitative data (in seconds) also complemented this finding.
Our customer service slack channels gave us a balance of quantitative and qualitative information. I was able to count the frequency with which our customer service heroes posed questions or escalations related to rebooking. Certain emojis and positive or negative adjectives were key indicators of how well their rebooking experience went.
I knew I had just enough research that I could confidently map out the current rebook flow to present to project stakeholders, and be able to identify potential pain-points to be solved by design or process changes.
One challenging aspect of mapping the flow was to represent the hero as the primary user, while also not neglecting the needs and pain-points of the SpotHero customer.
A fortunate aspect of being a product designer on SpotHero's efficiency squad is having direct access to stakeholders and users on the same floor of the building. I was able to maximize this opportunity and sit down at the desks of four customer service representatives to shadow and observe their workflows.
Going into these sessions, I had prepared a template list of questions regarding the Rebook flow.
What is working well and what do you wish was present in the workflow to help you be more efficient with rebooking?
Based on my 4 sessions of observation + interviews (as well as Slack), there were overlapping requirements that heroes employed while rebooking for a new spot. I distilled these requirements down to 4 criteria.
Aside from the criteria for a new spot, here are a few additional findings I found important since they reveal user behavior:
1. Some customer service representatives started searching for a new spot with the map, and some started with the list view results. The split between these two were close to 50/50.
2. On average, heroes will consider 2 to 3 new spots before choosing one as a rebook candidate. This was less spots than I had hypothesized.
3. Customers feel the most strongly about the following 3 parking spot amenities: Covered vs uncovered parking, valet vs self-park, and in/out privileges allowed or not.
With each iteration of my designs, my focus is to tackle each of the findings and spot criteria in a prioritized order. Again, this order was based on estimated impact to reducing average handle time of the case).
In terms of the customer, there were a few design goals I tried to keep in mind throughout my iterations:
Ease any doubts from the customer by being proactive about what the system (admin page is doing).
For example, proactively communicate that SpotHero covers the difference in cost if a more expensive spot is chosen. If a cheaper spot is chosen, the customer service rep should tell the customer exactly how much is being refunded and to what payment source.
Empower the hero to guide the customer to the newly rebooked spot with ease.
Minimize chances of a customer call-back due to further confusion, such as the new garage not yet having the new reservation in their system.
1. Added in details of original reservation in the flyout panel so that it's visible in this view. Heroes were having difficulty recalling these original reservation details, which are important to compare to the newly rebooked spot.
2. Added yellow highlighted notification to recognize if the customer is driving an oversized vehicle. SpotHero will be working on implementing the oversized filter soon.
3. Re-introduced image thumbnails of the garage/spot itself, as a recognition anchor for visually-oriented heroes.
4. (Not shown here): Re-order amenities icons to prioritize the top 3 amenities that customers care about the most (covered vs uncovered, valet vs self park, and whether in/out privileges are allowed).
Throughout my research and design process, I take developer collaboration very seriously. Here are a few salient points where I made sure to involve my front-end and back-end developers:
1. Usability testing.
All devs and our QA analyst assisted with note-taking and asking follow-up questions.
2. Filtering out spots that require an allowance of 5 or 15 minutes for a newly rebooked reservation to appear at the new garage.
This involved a collaboration with my back-end developer, who was able to perform a database search for all spots that require a 5 or 15 minute allowance between the time of rebook and the time the customer can physically enter the new garage.
3. UI pattern library.
My front-end developer and I consistently compromised on what UI patterns I had proposed by balancing them with what was already available in the shared front-end library. Decisions for introducing new patterns were made collectively with the front-end developer and members of my design team.
1. Adding in automation of gray-out's
Grayouts is a feature where Spothero temporarily does not allow customers to book garages and lots that are reported full by other customers.
2. Continue measuring success.
A/B test to gather more data significance and really assess time and cost savings from my new designs.