VMware Support
An AI-driven help center empowering customers with immediate technical issue solutions and quicker time to resolution.
User Interviews
Strategy
Design
Prototyping
Testing
Figma
Dovetail
Miro
Zoom
Split.io
6 months
Testing
VMware provides support and self-service resources through several separate microsites and tools:
In an initiative to simplify the self-service journey, VMware leadership folded these microsites into a single customer portal, Customer Connect. Theoretically, customers could now access all support resources from a single place. This unification was implemented by shoehorning the resource sites under a shared navigation and global search, leading to two key issues:
Lack of cohesion
Ineffective search tool
This unification effort, while well-intentioned, did not perform as desired. Overall, it did not have a positive impact on any of our support metrics:
Self-service engagement remained low, and support tickets did not decrease.
At the time, customers could freely file a ticket for any issue. These support tickets are routed to technical support engineers (TSEs) for resolution, making them more costly than self-service. Leadership wanted to reduce operational costs by decreasing support tickets, and asked for following:
Introduce friction into the support ticket form to deflect ticket submissions.
The business ask, while beneficial for company operations, was hostile to our customers. It changed up the support experience they were already accustomed to, and not to their benefit. It also ignored the root problem:
VMware support is a complex and disjointed experience, hindering customers' ability and will to resolve technical issues themselves.
The support experience was clearly not meeting our customers' needs. Support tickets continued to increase, leading to longer time to resolution, further frustration, and increased business costs. As a designer, I wanted to empower our customers to solve their issues – not obstruct and frustrate them.
How might we make self-service better, instead of making ticket filing worse?
With a less than desirable outcome already in the books from the initial unification attempts, the business was eager to get an accelerated turnaround for our work. We chose to go with a lean approach, planning a 4 week process from concepting to sharing an MVP with leadership.
Our team got together with business and support operations stakeholders, kicking off the project with a workshop. We discussed what we know about our customers' support-seeking behaviors, learned about technical support engineer pain-points, and dug into the business' wants, nice to haves, and non-negotiables.
At this point, I'd seen what customers did before filing a support request ticket. That was only half of the customer support story. I now wanted to understand the rest of journey, down to the final "Submit Ticket" button, and assess it for pro-active support and self-service opportunities.
I set up a working session with the product manager for Connect Support, where support requests are filed, and mapped out the main ticketing flows and known edge cases:
The landing page of the main support site, Connect Support, is one of the most visited pages within the VMware customer portal. However it was heavily underutilized, not meeting the needs of VMware customers or the business. In fact, it did not offer many self-service support options – it simply directed customers to either automated general support, or the technical support form. I felt the landing page had a lot of potential and chose to focus my efforts on revitalizing it.
I knew our internal AI team had built an ML-trained text box that analyzes issue descriptions and provides related self-service content. However, this text box was only available inside the support ticket form, deep into the customer's support journey.
We had data and customer feedback comments proving that deflection attempts at this stage had a very low success rate and tended to upset customers instead of helping them. In fact, I learned that the text box's self-service content feature had been disabled due to customer complaints. It's only purpose at the time was helping with ticket routing and product selection.
I consulted with the AI team and reviewed internal documentation to get a firm grasp on the tools capabilities and limitations, then started working towards a viable concept.
If self-service content is easily accessible, then customers will likely engage with it.
My hypothesis for this concept was that if self-service content is readily available, customers will be more likely to engage with it. This concept reimagined the Connect Support landing page as a one-stop-shop for all support content, powered by the ML text analysis box. It streamlines the self-service journey into a simple text-based prompt and brings relevant support directly to the customer, instead of forcing them to hunt for it.
Documentation, AI tools, and live support engineer options
Optimized results meeting a threshold of 85%+ relevancy
Ability to file severity 1 tickets for critical situations
This concept turns support content discovery into a step within the support ticket form itself.
After providing technical details and describing their issue, customers are offered immediate support resources. They can choose to engage with this content, or continue filling out the support request form after a short waiting period has elapsed.
Most customers are already comfortable with the support form
Customer issue details can be used for both finding resources and building a ticket
Customers are nudged to review support content but retain access to filing a ticket
While designing our prototypes, I reached out to VMware beta users to find research participants. We scheduled an intense week-long period to interview 15 users, synthesize research, and collect key findings.
Half of our participants tested Concept A followed by Concept B, with the other half testing Concept B followed by Concept A. We presented them with a broad task:
You are unable to access an ESXi host on vCenter. Using this prototype, how would you resolve this issue?
Users strongly preferred concept A as an overall support tool. They liked that it accommodated both high and low criticality situations, and appreciated its streamlined approach to support resources. They found the click-through interaction of concept A and loading button in concept B frustrating, preferring to see resources all at once with no deterrence towards opening a ticket.
