Report a Bug — Start a Conversation

Today at Automattic, I gave a presentation called Life Cycle of a Bug Report. Ostensibly, it was about the elements of an effective bug report and what happens to a bug report after it is opened. Ultimately, though, it was about how Happiness Engineers fit in to the rest of Automattic (or, more generally, how a support team fits in to the rest of a company), and how reporting bugs and other feedback can lead to better communication between support and product teams.

Here’s how customer support can sometimes look:

Dev-User-HE-Brokenloop.png

  1. The product team launches a product to the users.
  2. The users use the product, and when they have questions they reach out for support.
  3. Folks in support help users solve their immediate problems.

Ideally, however, there is a complete feedback loop:

Dev-User-HE-Loop.png

  1. The product team launches a product to the users.
  2. The users use the product, and when they have questions they reach out for support.
  3. Folks in support help users solve their immediate problems and communicate bugs, pain points, and other feedback to the product team.

In that complete loop, the people who spend the most time talking with users can advocate for those users and help set priorities for addressing pain points. Support folks also get an opportunity to connect more with the people who spend the most time creating and improving the product, to better understand existing priorities and resources.

When I write a bug report, I’m not just dumping a problem on someone else’s lap or giving someone a hard time for the product they created. I am pointing out a source of pain for the product’s users and starting a conversation about how to address it, in the context of everything else a product team is working on. In the process, I develop stronger relationships with our product teams and, as a result, can provide better, more informed support to our users.

Advertisements

Embracing Openness

An exciting part of working at Automattic is the open source philosophy. It’s thrilling to help open source projects like Calypso (the new WordPress.com), even in a small way. I spent a chunk of time last year reviewing open bug reports, enhancement requests, and the like before the project was open sourced — it’s fun to see (and help with) new issues that come up as more people work with, get inspired by, and contribute to Calypso.

Open source isn’t just about developers, either — I do a lot of my day-to-day work in the open. I used to mainly provide support out in the open, helping users in the WordPress.com forums. These days I spend most of my time in the WordPress app repos, reporting and testing issues in the open there. (If you’d like to get involved, I also started posting calls for testing the WordPress apps over at Make WordPress Mobile.)

In the spirit of open testing, Automattic also recently released the WordPress.com Automated end-to-end tests into the open. I’m so glad we can share the awesome work that our QA and testing folks are doing. I’d also highly recommend checking out my coworker Alister’s blog WatirMelon for more testing talk.

Openness can really be part of everyone’s work — from open source, to open testing, and open support. Being open helps us learn from each other, inspire each other, and keep us aware of and oriented toward the wider community in which we work.

BetterCloud’s Approach to Proactive Support

With the help of our engineering team and many man-hours from the support team, we were able to do the following:

  • Identify actions or error messages within the BetterCloud app that we wanted to track
  • Work with our development team to configure logs into easily digestible chunks and feed them into our error log management system, Splunk
  • Configure Splunk to email our Proactive Support team once an error alert is triggered
  • Before a customer can even submit a ticket, our team will reach out promptly using in-app chat (Olark) or via email with Zendesk. We are literally opening tickets on their behalf.

“Why proactive support should be the new standard of IT support” — Zendesk blog

 

I love this approach. Why wait for customers to contact you — or, worse, bail on you — before trying to solve the problems they face?

Troubleshooting in 5 “Simple” Steps

I recently talked with my coworkers about strategies for troubleshooting. We were focused on how to troubleshoot issues while chatting with our users, but I wanted to start with a basic workflow for troubleshooting bugs in any support medium. Here’s what I came up with:

  1. Understand the problem from the user’s perspective
  2. Determine if it is expected behavior or a bug
  3. Search for previous reports of the bug or discussion of the feature
  4. Test to see if the bug is reproducible
  5. Report the bug in the appropriate place

I feel pretty good about that workflow, in terms of describing how you can identify and report a bug. As soon as you start considering the rest of the support picture, though, it gets more complicated.

Here’s a rough flowchart I just sketched out that takes into account the larger context:

Troubleshooting flowchart.jpg

I like how that flowchart encompasses not only what to do while troubleshooting a bug, but also some ideas for how to handle non-bugs — and what to do about the user who’s still stuck even after you identify and report a bug. Because let’s be honest, some bugs aren’t going to get fixed, or the fixes might take a while, and we’d still like to help those users get to where they want to go. I guess that’s a more holistic view of troubleshooting, beyond being a bug collector. 🙂