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.
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?
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:
- Understand the problem from the user’s perspective
- Determine if it is expected behavior or a bug
- Search for previous reports of the bug or discussion of the feature
- Test to see if the bug is reproducible
- 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:
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. 🙂