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?


Multitasking, Testing Style


I’m currently doing a little extra testing on my Mac, to pass the time while Firefox installs on my Windows 10 virtual machine, Android installs an OS update on my new Nexus, and my VPN connects on my iPhone.

P.S. As part of my testing I scheduled this post for the future, so it isn’t actually my current status as you read this. ;)


VaultPress to the Rescue!

This site is hosted at, which means I don’t have to worry about backing up my content or breaking things. (At least not when I’m blogging — and so far I haven’t broken anything while working, either. Knock on wood!) But I also have a self-hosted site, Happy Photos, where I share photos and test all sorts of things. You can see where this is going, right?

I was doing some testing on Happy Photos earlier this week, and I managed to break something. I’m not exactly sure what happened (I think it had to do with rashly deactivating a plugin I relied on) but the end result was a broken login page.

Now, a broken login page isn’t the end of the world when everything else still works. My site itself was still running and I had access to the dashboard. So I was ok. And then, for some completely unknowable reason, I had the bright idea of logging out.

No more access to my site’s dashboard.

Thankfully, I had some other options. My site uses Jetpack, including Jetpack Manage, so I could update the site and even manage the plugins directly from And I had FTP access to fall back on. Unfortunately, none of the fixes I tried worked … at all. Plus, I was feeling a little impatient to just get back in there. So I turned to VaultPress.

VaultPress is another Automattic service, and I spent a few months last year learning the ropes and providing support for it. In a nutshell, VaultPress provides backups and security for self-hosted WordPress sites. And ever since last year I’ve been using it to back up my self-hosted sites. So tonight I logged in, chose a backup from a couple days ago, and hit the restore button. A few minutes later, this glorious screen appeared:

VaultPress to the rescue
You don’t actually have to keep your browser open during this process, but I couldn’t look away. As soon as I got this success message, I pulled up my site — and there it was, login page and all!

To all of my incredible coworkers and Safekeepers, thank you. You give me the courage to go on testing and breaking things without fear.


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. :)