Building A Robust Customer Support Platform For Agents

Facebook • 2021

While at Facebook, I built an internal customer care platform that is fully dedicated to the goal of providing automated & agent support in a high-quality, interactive way.

Role

Solo designer and the reason I joined Facebook was to lead and own this project end to end. A new team was formed around this project and the PRD had been just started so I got to influence the direction quite a bit.

Impact

First contact resolution went from 46% to 72%. Total resolution time decreased by 3 min, the cost per customer reduced by $10. Overall, we were able to reduce operations cost at Facebook by $38MM.

People Problems

Before the large investment, the team spend a considerable time evaluating the need for a separate tool. Too many teams are using their own resolution tooling for customer support. Some Facebook teams used Zendesk and although it is a strong solution for basic support experiences, servicing the complex and varied support use cases would necessitate custom FB engineering efforts. In addition, there were security and privacy issues that other teams faced with. All signs pointed to a new unified tool.

Research

Over the course of a few weeks, we spoke to all enterprise teams within Facebook and compiled a working sheet that outlined the needs, the tools they current use and how well those needs are being met from a score of 1 to 5. This gave use a clear picture of existing functionality, the importance of the feature and assess key product gaps.

To better understand the vast lines of businesses using support tooling within Facebook, I put together a sizing graph that demonstrates the number of agents per line of business. If it looks like a clusterf**k, that’s exactly the point I was trying to convey.

Strategy

I organized and facilitated a several-day design sprint that helped the team align on addressing the critical needs. This was a unique sprint session as we included a few agent and ops interviews during the first day “Understanding.” These are some core problems that were identified;

  • People can’t easily self service. The content is scattered across many places.

  • It’s hard to reach support. Forms are cumbersome and customer cannot find a phone number.

  • People/tickets go to the wrong team.

  • Agents cannot share cases with the correct team. This delays customer resolution.

  • Agents don’t have a full view of the issue. This makes it harder to investigate and resolve cases.

The team came up with many solid solutions by brainstorming using different methods like defining jobs to be done, empathy and journey maps, how might we’s, solution statements, and sketches.

Design Needs

  • Phone Channel

  • Bulk Actions

  • App Submission

  • Guided Review

  • User Groups

  • Comments (seen state)

  • Image Attachments Inline Previews

  • Loading States for Case Detail Components

Ideas From The Sprint

  • Shared Views: All agents on the same Tier have the same permission access to the case.

  • Related Tasks/Cases View

  • Linked Tasks View

  • Warm Handoffs: Agents get a full report of the chat history between the prior agent and customer

  • Customer 360°: The agent gets a full view of the ticket from initiation.

  • New User Experience

  • Common Responses: Templated responses to common questions powered by automation.

Design

During the design phase, I explored many potential interaction designs as well as UI treatments. My main goal was not simply to add a feature, but to think of ways we can reduce the agents workflow time. Here are some of the solutions.

Wireframe

Most Facebook tooling products follow a similar architecture in how they are presented. We were not trying to re-invent the wheel here, but some I certainly did some testing with the features we need to make sure the existing structure was able to handle them.

Column Edit

One of the asks by agents was control over their own table view. This meant being able to customize the columns however they see fit. Tapping on the column icon brings up the panel to edit the column.

Bulk Editing

This was an unique interaction I contrived. When the agent selects more than one field, the Editing Panel automatically opens up. This saves the agent a millisecond in task time.

States In Bulk Mode

The complexity in bulk mode comes in when cases all have their own parameters such as permission types, labels, tags etc. How do you show 2 cases that have a similar tags vs uncommon tags? What if you have access to one 1 of those cases? The following are some was I have solved those design challenges.

Common Responses

Agents need to respond to tickets quickly so they can move on to the next case. A lot of cases are regarding the same matter so instead of typing the same responses over and over, they now have pre-canned messages they are;

  1. Able to write themselves or

  2. It gets generated from similar cases used in the past by other agents.

Duplicate Case Detection Duplicate Case Detection

There are hundreds of duplicate cases being created daily as customers re-submit the ticket, agents classify or a host of other reasons. We need a way to flag these cases in an intuitive way. For a single duplicate case, I’m using a checkmark similar to a comparison pattern you’d find elsewhere. It calls out what the automation model detected as duplicate so the agents can make an informed choice.

For multiple duplicate cases, that same UI wouldn’t work, so I have integrated the fields that are similar into the table. This would allow easier comparisons between cases. The con with this approach here is you lose more detailed context that the single case is able to give you.

Speedy Preview

One of the issues that agents brought up is constantly having to go into the Case Details view in order to see the details about the case. So we designed a nifty hover mode that provides those details.

Notifications

In a similar vein, having notifications as part of the table view was also critical to the workflow. I tried to initially have a single preview module, but this added unneeded visual and interaction complexity as the agents needed to mark the notifications as read or unread.

Navigation

It wasn’t until after the first launch that I noticed the importance of notifications. I shouldn’t have been placed alongside the other nav items as it would get lost in the UI. The new designs have it flushed at the bottom of the nav panel. The notifications would be a pop-out view so as to preserve the ever-important table view.