Support Ecosystem
AI chat bot, ticketing, messaging and contextual help
Project Overview
My Role
I worked as the lead UX designer creating the designs and strategy.
The Problem
Support is scattered through multiple systems, emails, and numbers leading to suppliers unable receive help causing delays in critical business needs
The Mission Statement
Be suppliers preferred growth retail partner by delivering shared value through ease of doing business. This will require fast, simple, and consistent processes and support to improve supplier experience and lower the cost to serve.
The Project
How might we provide a single place for suppliers to find answers to their questions and issues. How might we help suppliers so that they don’t need to submit tickets? If they do need to submit a ticket, how might we make this quick and simple with faster resolution times?
The Goals
Reduce Multitouch
Work on reducing the number of tickets worked on multiple times due to being submitted to the wrong place or being submitted multiple times
Current: 21% | Desired: 15%
Ticket Deflection
Work on reducing the number of tickets submitted by providing easy access to frequently asked questions & information
Current : 24k / month | Desired : 19k / month
Added benefit: 52k/month (620k/year) in contact costs
Reduce Resolution Time
Work on reducing the time taken to resolve tickets by submitting them in the correct location & providing information via chat
Current: 9 days | Desired: 5 days
The Process
The existing experience
Ticketing discovery
User feedback
Scope and focus
Goal creation
Phased approach
The designs
Chat bot animations
Ticketing designs
Contextual help designs
Expanding scope
Version two designs
Chat bot drawer
Separated ticketing center
New messaging center
The final designs
How did we measure up to our goals?
Going the extra mile
What’s next?
The existing experience
There are 36 different options to submit a support ticket today.
Suppliers have to search for which ticketing system they need to visit. Or they give up and contact their Walmart merchant which costs money and valuable time for the merchant.
User feedback findings
There are inconsistencies in troubleshooting. There are specific people suppliers contact and if they leave would have to rework the solution pipeline.
Many suppliers were relying upon facebook groups to find answers within the community.
Timing to resolve can be extended if having to resubmit tickets or the singular person/email box not present.
Needs for both email/webform for responses. A phone for emergencies would be helpful.
Issues that come up not already discussed hard to resolve especially when help teams are no longer supporting.
Better documentation and additional training for programs/issues prior to needing centralized support could limit need for contact.
Issues with data matching across platforms as well as issues between .com data and store data.
Settings on systems that can be initiated to help suppliers, but relies on specific departments to initiate i.e., NOVA settings for auto approval. Usually, RMs will set for supplier for their department but does not translate to other departments without coordination or further supplier contact.
Also, Walmart personnel may not have training on how to do certain tasks in respective systems
After gathering user feedback and learning about the existing ecosystem, we determined the main goals would be:
Create a central place for all ticketing systems
Reduce tickets
Help suppliers find help content
To do this, we implemented a phased approach
The main design deliverables included a chat bot, a ticket management center, and a contextual help strategy.
Competitive analysis
We did a quick competitive analysis to gain an understanding of where we stack up and what areas we could tackle.
The chat bot
I based the design of the chat bot on the walmart.com chat bot for consistency with our patterns. I animated it in figma to illustrate the desired interactions that couldn’t be captured by mock ups alone.
Enhanced supplier support and engagement
The chat bot offers real time assistance to help navigate the platform, learn essential features, and get started quickly and easily, which would be instrumental with onboarding suppliers to this brand new platform.
It uses AI/machine learning to optimize decision making, reducing tickets and manual intervention.
One place to file help tickets
With one consolidated spot to submit help tickets, suppliers will no longer have to search for the correct place to file a specific ticket.
Ticketing designs
To deliver the designs, I mapped out all the possible interactions.
Expanding scope
However as we started to build the chat bot, more requirements started to crop up such as the need for a messaging system.
Sometimes a Walmart support associate needed more context (better description or screenshot) in order to trouble shoot for the supplier, so we added in a limited messaging feature in conjunction with ticketing.
But I was starting to see similar requests from other projects (such as onboarding) where a supplier would need to message walmart about editing their business info, or the walmart associate found an error on the supplier’s tax info.
I asked my product managers if there were any other upcoming projects that required messaging and sure enough, order management and insurance renewals would require that feature.
So having delivered the MVP for chat bot and ticketing, I pivoted to thinking about the next iteration.
Where does the chat bot and ticketing fit into this expanding ecosystem?
I wanted to illustrate to the PMs the difference between the chat bot, tickets, messaging, notifications and the “top tasks” we show on the homepage to help delineate what messaging or tasks went where and set ground rules.
Version two of the support ecosystem
The new structure would separate messages, tickets, and the chat bot, giving each the space for the complexity of each feature.
Additionally, I had to include new features such as “chat history” and “start a new chat” which I located in the “more actions” icon since they will be less frequently used.
Why we needed to move towards a panel solution:
The minimized chat bubble interfered with sticky footers and had to be manually changed per page creating extra work for developers and designers alike to VQA it.
More vertical space was freed up for reading messages, and showing suggested help based on the page the user is on. This new feature wouldn’t have fit within the fold of the original design.
The chat drawer works with the responsive pages to allow the user to easily interact with the main content of the page while referencing the chat’s responses.
The drawer pattern is being used for help/guidance patterns that are also found across the enterprise space at Walmart.
Prototyping for usertesting
Next I did several rounds of prototyping and testing to make sure we got the interactions right. In particular, I wanted to see if users knew where to go to find chat, ticketing, and messaging since they were overlapping concepts, and I wanted to make sure the “expand” functionality was something they’d actually find useful and understood how to minimize and exit it.
The findings
Expand functionality
Users appreciated the expand feature to easily read the responses from the chatbot that were often quite long.
Masthead icons
Users were not able to identify what everything in the masthead represented when it was only icons.
The question mark icon
When asked about where they would find the chatbot or ticketing, they were most attracted to the question mark icon initially.
Messaging and ticketing should be separate
And although messaging and ticketing have a back and forth discussion between a Walmart associate and the supplier, they did not think they should be grouped together.
Confusion around the messaging center
They were confused why they would need a messaging system on Supplier One, they assumed the envelope meant “email” and expressed that they wouldn’t use the messaging center as long as they had email. So we need to find a bigger value add or a more realistic scenario for when the messaging center project is kicked off.
Chat history
They were also apprehensive about the new “chat history” feature, saying they didn’t know that it existed and why they would need it.
The final designs
After taking in the users’ feedback I created the final designs that became the template for other chat bots across the company like the Gen AI bot and Seller help.
How did we measure up to our goals?
As shown here in this table, we have different record types which are different back end systems tracking the tickets (Even though the user sees just one interface). They are measured by the three main areas we were looking to improve: Reducing multitouch tickets, deflecting tickets overall (measured by unique tickets, meaning tickets that did not get transferred from team to team), and resolution time.
Since introducing our centralized chatbot and ticketing system, we saw a reduction of multitouch tickets by -16% resulting in a new rate of 18.9% which is in the right direction of our goal of 15%.
The average resolution time saw a reduction of -29% going down to an average of 6.5 days, which is close to our goal of 5 days.
However we are seeing that unique tickets are rising by 6%. When we looked into it, the main contributor to the rise was around financial and payments tickets, which kicked off my work for the Payments ecosystem.
Going the extra mile
In addition to the chat bot and ticketing system, I proposed few more solutions to help users find what they needed.
One thing we saw from user feedback was that users kept asking the chat bot where things were located. Since Supplier One was still pretty new, there was a learning curve to finding the new locations to previous features.
We proposed a new homepage feature powered by AI that could serve as a spring board into the chat bot or into a desired task or workflow.
How might we better integrate help content into Supplier One?
While the initial scope of the project was to consolidate all our help docs into one site, we implemented a strategy to insert help information in context within the page.
We have long and complex data tables full of acronyms. So how might we convey large amounts of information in a digestible way? We know we need to spell out acronyms to meet accessibility guidelines but spelling them out in these tables get unnecessarily long and makes it hard to compare the data, even when wrapping to two lines of text.
We had been using info icons to spell out acronyms and define specific words, but the sheer amount needed for complex subject matter that Suppliers deal with made the pages harder to scan and created visual clutter.
And we also would like to convey more information to the user about the status of a line item so that they don’t need to click into it, which could be annoying to do for each line item if they are looking for certain info. So we want to convey more information in the small amount of space we have for the status column.
The solution
Introduce a scalable pattern for increasing levels of support for educational information.
How does this look in practice?
The concept was, we show help text where possible on page but when space is tight, we underline the text with a dotted underline indicating that there is help content available to the user. This is a common pattern we found on sites like Fidelity or TurboTax that have complex concepts they need to explain to their user base. When they click the dotted underline link they can get more info or access to a panel of information. We reused a lot of help content from our discovery work and presentations for these help panels. If they still need more answers they can click on the “visit help docs” button to read a full article. In short, we were strategically providing the right amount of help content to keep them in their work flow, without needing to search through an entire document.
A common need
I noticed that across my enterprise org we were all doing something similar to this pattern, so it was clear that this component was needed. I spearheaded the effort to getting this pattern adopted by the design library, outlining the details of the pattern and the use cases. It’s currently being adopted into the enterprise library system.
What’s next?
Our next steps is to provide a forum for the supplier community to help each other. They are currently using facebook groups as a resource for sharing knowledge, so how might we keep that in house and allow them to easily find answers and share their knowledge?
We’ve heard through feedback that some users don’t want to talk to a bot and prefer talking to real people to more quickly and accurately get information, especially when it’s a unique problem. So how might we provide expert help with a personal touch?
Since we found that a lot of questions are around new features, how might we better inform users of what’s coming next and how to optimally use it to help their business.