In the past year, WooCommerce has grown tremendously. Not only has our product become more stable, our operations are more organized and our number of people has almost doubled in size. 

Sometimes, though, things go wrong. Whether it’s a bug in a product, an unexpected email that got sent, or something else. When this happens, we want to support our users in these times of urgency. 

Over the years, we’ve gathered insights and experience in how to handle these situations well. In this post, we’d like to share some of our approaches with you.

What we’ve learned

Be transparent. When there is a bug or other issue with your software, your customers want to hear from you about it. It’s important to be transparent and open, as transparency helps to build trust.

For example, in July 2021, we decided to write a blog post and send out a mailer to all users in our database about a vulnerability. We did this right away, and continued updating the blog as we learned new information. 

Anticipate questions (and prepare answers). Before we send out an email or publish a blog post, there are two things that we need to figure out. The first is what we are going to tell our users. 

To answer these questions, we work together with our marketing, product, and legal teams. We brainstorm the questions we expect our users will have, and formulate answers to those questions. The result will be that few of the questions that are asked will be a surprise to us. Doing this allows us to focus on interacting with our users, as we’re no longer spending time finding answers.

Set up routing. The second big question is where we want to have these conversations with our users. When we are the first to report on something going wrong on our blog, our social media, or via email, we invite our users to chat directly to us. We want to keep our channels open and gather as much feedback as possible. 

For example, when we’ve published a blog, we’ve left the comment section on the blog post open and monitored it constantly. When we’ve sent out an email, we’ve ensured that users could reply. By making it as easy as possible for them to do so, we were gathering the questions in the place we could respond to them swiftly. When we were expecting a rather large number of email replies in Zendesk, the support tool we use, we further made sure that replies to our mailer ended up in a separate queue. 

In such cases, if we set up the routing carefully, we know that the majority of conversations will likely happen in those channels that we monitor closely. This allows us to engage with our users and answer any questions that arise. 

Create a task force. In all cases where we need to address an unexpected event, the effort for this is stressful and intensive, but also limited in time. We’ve found it best to have a smaller group of Happiness Engineers handle all of those very specific, ultimately temporary concerns that people have. 

This allows the smaller triage group to reply faster, but it also ensures that our other support requests still get the majority of our attention. Because of our Zendesk routing, a task force can move through the questions connected to this specific problem, while the rest of our support team helps our other users. This task force has the ownership of the process, so they can make close-to-instant decisions, even if that means disregarding minor workflow steps we follow in normal times.

Get moar data. We want to review our actions, both real-time and retrospectively. To do that well, we set up tagging before we even send out or publish anything. Our general rule is that if we expect the same type of question more than once, it should get its own tag. As a result of our careful tagging, we can see what the most recurring questions were. The results also help us make decisions on how many people and how much time to allocate to this incident. Finally, the data helps us to prepare for future incidents. 

So does it work?

Yes, it does. For example, in the incident I mentioned earlier, it took us less than 30 hours to respond to the majority of the questions on both our blog and in the email replies. In the past, when we were less organized to address these, it easily took us five times longer to do so. 

Build relationships 

One final thing we’ve realized is that our pre-existing work relationships are the glue that holds all of the above together. When hearing others in the tech support industry talk about developers, marketers, and so on, the undertone is often one of conflict and irritation. While these occasionally exist at Automattic as well, generally, we work well together. 

It’s important to not wait until things go wrong to talk about our work with colleagues from our product team, the marketing team, and the legal team. At our annual Grand Meetup, we joke together and share meals. With some of the key people in each team, I have a regular Zoom meeting that isn’t prompted by incidents, but that is focused on relationship building. As a result, we can communicate directly and swiftly. We know which people should be involved. 

If the first time you’re chatting to a developer is during an incident, there’s no relationship. There is no shared understanding of company culture and intentions, and it’s going to be challenging to go through a process riddled with stressful communication and urgent decisions. We (try to) nurture a relational culture where whatever I suggest as the WooCommerce Happiness division lead isn’t above critical questions. For example, the way we word our replies and how we approach the triaging will be a lot more efficient if Happiness Engineers feel comfortable critiquing my wording and tweaking my suggestions. 

Don’t wait until things go wrong to build these relationships and culture. And definitely don’t wait to repair relationships with other divisions until everything goes bad. When things do go bad, you’ll need to rely on each other more than ever.

---

Interested in becoming a Happiness Engineer at Automattic? Visit the Work with Us page to learn more about how you can express your interest!