When you make it about your customers you win.

In the era of high competition, you need to stand out and make your brand memorable, likeable and, what’s more important, maintaining a personal approach. Who can do this if not your frontline workers — your customer support teams. People who’s daily routine is to talk to users, solve their problems and make their experience flawless.

Whether your support teams work with regular tickets or social media mentions or mobile reviews — they all represent your brand and help you retain your customers. Even if each company has a different approach to customer support, their final goal is to make your customer happy. But how do they do that? What tickets do they prioritize, how do they collaborate with other teams, what metrics do they track?

To answer these and other questions we start a series of blog posts where we will talk to Customer Support teams of your favorite services and tools.

And to open this series we spoke to Jason Pearson who is the Head of Product Support at Figma, a UX/UI design software company based in San Francisco. He joined as the first official support member in 2016 and now oversees a global team of 20. He enjoys working with his team to solve operational challenges at scale and has found it particularly fascinating to learn about people and team management over the years. When he's not reading books on leadership and organizational psychology he's probably hiking, biking, drinking coffee somewhere, or just relaxing with his wife and small dog, Sam.

Jason, how is your customer support team structured?

Our customer support team, we call it our Product Support Team, has grown considerably over the 3.5 years that I’ve been with Figma. I joined in December of 2016 as our first official support hire and now our team is 21 people in total. The bulk of our support work is helping designers and developers who are working in the Figma editor. In addition to our Core Support team, we also have Admin Support, Product Education, and our nascent SupportOps team under the umbrella of Support.

• Core Support

The entry point into our support organization is through our general support team. I prefer to call them our Core or Editor Support team since their collective body of knowledge about the product is far from “general”. If you’re using Figma and have questions, they have you covered! This team represents the largest portion of our overall support team. They are supporting all the designers, developers and PMs who are using Figma at their companies on a daily basis and answering a myriad of questions each day.

• Product Education

By the time I was hiring our fourth team member in mid-2018, it was apparent that in order to support Figma’s growing user base at scale we needed a much more robust and comprehensive help center for our users. Help centers generally fall in the domain of a company’s support team. 

A great help center can go a long way when it comes to proactively supporting users and deflecting unnecessary conversations in the queue. It has also been my experience that in order to build a best-in-class help center you need at least a couple people dedicated solely to researching, writing, editing, designing, strategizing about the information architecture, image and video creation, and maintaining all the content for your customers. Expecting that level of thinking, time management and execution from your support team who are already busy supporting users, liaising with product and engineering teams, troubleshooting issues, writing and maintaining internal documentation, training new team members and working on other projects, is not realistic. This is especially true if your product, like Figma, is rapidly developing with new features, and enhancements to existing features, shipping almost weekly! It becomes near impossible to keep up.

Watch here how Revolut and Yousician organise their customer support teams

It was around this time that we formalized a Product Education Team. This is now a team of four people managed by one of Figma’s early support hires who is a natural born project manager with an exceptional amount of design skills. He manages two technical writers and a video editor. Product Education is a team within a team and over the last 2 years their focused work has taken our help center to the next level. The improvements, both in quality and quantity, have been astounding!

• SupportOps

As our team continues to grow we will need to double-down on operational improvements to our tools and processes so we recently hired our first Support Engineer who will spend a considerable portion of their time on things like iterating on our Zendesk instance, integrations, Slackbots, helping to improve some of our internal tools, liaising with our product engineers to improve our escalations and triaging processes, etc. In conjunction with our Support Engineer we also have a senior member of the team who has considerable experience with SQL and Python so they spend about 40% of their time outside of the queue working on reporting, as well as creating some scripts that the rest of the team can run to help speed up otherwise manual tasks. I’m excited because these two roles are the beginning of our SupportOps team.

• Admin Support

Figma has an Enterprise product and we have a small subset of our support team who provide what we call Admin Support. They work closely with Sales, Product and Engineering to support the administrators “Admins” of our Enterprise accounts. Admin Support is providing high touch, somewhat more technical support for our top paying customers, largely focused on provisioning and setting up complex accounts for large companies. It’s a “flavor” of support that touches a very different part of our product and will eventually be a growth opportunity for support team members who are looking to branch out into this type of support and work cross-functionally with other teams.

So, that’s a long answer to your question. Our support team is made up of what I refer to as Core Support, Admin Support, Product Education, and our nascent SupportOps team.

How do you process user feedback from reviews of your product?

We currently have several ways that customer feedback, largely around feature requests, is made visible to everyone across the company.

When anyone comes across some particularly great, insightful product feedback it gets posted in our #feedback-customer Slack channel. It’s a public channel and people often chime in with additional information. For instance, an engineer who works on that particular part of the product might add their thoughts and provide some insight on what they’re working on. Or perhaps a designer sees the customer feedback and chimes in about how they were thinking the exact same thing. That might initiate a broader conversation internally. This is probably the most lightweight way that all “Figmates” can get a quick glimpse into what our users are talking about.

Another way we surface customer feedback across other teams is with our “Feedback Tracker”. One of the managers on our support team has worked really hard on this alongside people from our Product and User Research teams. When a support team member is wrapping up a conversation with a user in Zendesk, they will add a quick summary of what the user was looking for, where they were confused, what they expected, etc. in a special field in the ticket UI. Using a “Zap”, that field is pushed into a Coda doc that can be filtered in a number of ways similar to a spreadsheet.

Let’s imagine a PM from our Prototyping team is thinking about working on something new, but is wondering, “I wonder what type of enhancements users would like to see for prototyping?” They can open the Feedback Tracker and filter by various product areas to see what people are asking for, how many people have asked for it, and most importantly why they need this feature or enhancement—what problem it solves for the customer. If our support team is properly using the summary field in Zendesk, the customer feedback should be captured in the tracker. We’re working to ensure that feedback from other channels like Slack, Twitter and Salesforce are also funneling into the Feedback Tracker. Our hope is that this makes it a little bit easier for our Product and Research teams to make data driven decisions about what to work on, what to research further, and how to prioritize that work.

Find out how to analyze sentiment of your mobile reviews.

Insights from the Feedback Tracker, along with data from the User Research team and several other inputs, all comes together and ultimately informs our quarterly Product Roadmap in Coda. Every quarter our support team meets with our product team to discuss the roadmap. Our discussions also happen in Coda where we can “thumbs up”, “plus one” and add comments for the product team to consider. Our product team graciously spends time with many other teams to be sure everyone’s voice is heard. Eventually, final decisions are made and everything is communicated back to the company.

We may not always get exactly what we want (balancing business needs with all the amazing feature requests from our community is tough) but the process is transparent and we all have a seat at the table.

When user feedback skyrockets (new release, outage, etc), how do you prioritize tickets?

Fortunately, outages are quite rare at Figma. In these situations, it’s “all hands on deck” and quite amazing to see how quickly cross-functional teams come together and start working to (i) resolve the issue, and (ii) manage communication with our customers. Back in April, there was a service interruption that did affect a relatively large number of users. Afterwards, and in the spirit of transparency, our engineering team wrote a blog post about it. I’ve always admired how the Figma team handles these challenging scenarios.

We occasionally have what we call “red alerts”. An outage is certainly a red alert, but not all red alerts are outages. A red alert could be a regression after a weekly deploy that breaks something in the app. Maybe it’s caught internally before users notice, or perhaps it is something larger that impacts users and they bring to our attention. In the latter, our support team has a process in place on what we do.

We use Zendesk so we create a problem incident, notify the appropriate teams internally via our protocols, spin up a saved reply to help quickly communicate with customers if our inbound conversation volume warrants it, create an Asana task with links to Zendesk tickets and helpful details or repro steps, keep our status page updated for our users, and work with our marketing team when we need to communicate proactively via social channels.

We try to have a point person on the support team overseeing the red alert and communicating updates to the rest of the support team. This allows the rest of the team to continue supporting other users in the queue who need help with other things unrelated to the red alert.

Outages and red alerts are stressful. We work hard to have our internal processes well-documented so there’s less room for confusion regarding who does what and when. It’s also not a perfect science. We’re always learning how we can do things better.

When we release a new feature we tend to see an influx of new conversations from happy, excited users, as well as some users who may have some additional questions that are not immediately addressed in our help center articles. Oftentimes someone on the team will create a Notion doc and gather screenshots from conversations so we can (i) share the positive feedback with the company during a launch week, and (ii) to share critical feedback on where there may be lingering questions about the new feature. If we continue to see recurring confusion about a new feature we will start to track that information by creating a new product area in Zendesk, tagging conversations, and pushing details into the Feedback Tracker.

What kind of tickets go to your marketing, product, and tech teams?

For us, as is the case for many other companies I would assume, the way support teams convey feature requests, bugs, or other interesting feedback from customers to other stakeholders has evolved over time. It’s also largely dependent on who we’re communicating to internally and what their preferred mode of communication might be.

When we were a much smaller company we could Slack bug reports to specific engineers who we knew were working on that part of the product. As our engineering teams grew and restructured, and as their responsibilities shifted, it was no longer realistic to ping engineers 1:1. It starts to cause a lot of “thrash” when individual people are constantly being messaged. We needed to introduce lightweight processes for more effective communication. Instead of messaging “Sarah” about something, we started to post in the “prototyping” group Slack channel where Sarah, or one of the other engineers working on prototyping, could have a chance to chime in. As we continued to grow, we hired engineering managers and eventually product managers for each engineering team. The communication process changes when you have managers acting as filters for incoming information to their respective teams.

As for when to communicate information to other internal departments it’s important to know if you’re reporting a one-off edge case, or something that’s trending and warrants bringing it to the attention of others. Our team likes to have some clear examples with reproduction steps created in an Asana task before we start communicating to other teams. It’s important to have our ducks in a row; to know what we’re seeing/hearing and fully understand the implications before moving forward.

What is your main priority when supporting customers in turbulent times?

During stressful times, such as a service interruption, the top priority is to be there for the users; to let them know that we’re aware of the issue, working to address it, and provide them with suggestions and any workarounds that might help in the meantime.

However, in these situations there are a lot of things happening behind the scenes internally and you can’t communicate effectively with your customers if you’re scrambling around and struggling to communicate internally. It’s important to have protocols in place for emergency situations that include clearly defined areas of responsibility and point people for each.

At Figma we have clear escalation paths. Once escalated, we know the appropriate teams have been notified and are working on a fix.

• There’s a team of engineers working to resolve the issue
• There’s an engineering point person providing updates to other teams in Slack
• There’s a point person on our support team who is overseeing the red alert and communicating to the larger support team. This person is also working with others to make sure our status page is updated with relevant details

During stressful times like this the focus is on following our processes, frequent communication, and supporting our users.

How do you analyze the efficiency of your work? 

This is actually a really interesting question, and now that we have a couple more experienced support managers on our team, it’s something we’ve been talking about recently. I would say your support strategy is working if your support team and your customers are both happy and productive.

Are your customers happy?

There are all kinds of KPIs that support teams can look at to make some conclusions about the overall quality of the support they are providing to their users. Some are industry standards like CSAT and NPS and others are a bit more “new school” like Customer Effort Score (CES). Each metric has pros and cons and I don’t think any of them are the Holy Grail. They are data points that, when used in conjunction with other metrics, can help answer the question, “Is our approach working?”

Figma’s Net Promoter Score has historically hovered around 72 which is incredible, and our average CSAT across paying and non-paying users is upwards of 90%. Our customers enjoy the product, they recommend it to their friends and colleagues, and when they need help from our support team they’re impressed with the timely, thorough, and friendly interactions they have with us. We help to get them unblocked so they can get back to work. We have a Product Education team within our support team that focuses on our Help Center articles and YouTube video tutorials. All of their hard work ensures that our users can self-serve without needing to contact our support team directly. In addition, we keep a close eye on our reply times as well. We quite often exceed the targets we commit to.

Is your team happy?

Does your team feel like the expectations you have of them are reasonable and achievable? Is your help desk set up optimally with easy access to tags, macros, and other automations that help speed things along? Do they know how to prioritize their work? Does the team have a good balance of time in the queue and time working on projects that help improve the operational efficiency of the overall team? Are they growing, learning, and provided with stretch goals and opportunities to interact with other teams?

If you can say “Yes” to most of these things, then I would argue that your team is probably pretty happy!

If you have a story to tell about customer support in your company, drop us a message.