While great customer support is increasingly common, doing it amazingly well is still a fantastic way to establish a competitive advantage. Before starting Sifter, I was worried about the time and effort required to support it. I was afraid that I’d be spending a couple of hours a day answering emails. I was wrong. At the peak, I spent maybe thirty minutes each day doing support.

If your customers succeed as a result of using your product, you will too. A support request is a perfect opportunity to take great care of your customers, as well as learn where you can improve. Ideally, your software doesn’t have any bugs or confusing features, but that’s not going to happen. So be incredibly responsive about bugs you can fix, or frequent requests you can streamline by making it easier for you or by making the feature self-service.

While you shouldn’t jump at a solution for every request, for every inquiry you receive, there are likely many more customers suffering in silence. Think of each support request as a clue to how you can improve, and then research it to understand if others are having issues too.


It shouldn’t be hard to support your product. Of course, if your software is plagued with bugs or usability issues, that’s another story (but if that’s a problem, you’ll know right away). If you’re being overwhelmed by support requests, take a step back to look at what’s gone wrong. Are there too many bugs? Are people confused? Are you missing key features? Once you identify the underlying problem, set aside some time to fix it and move on.

Support requests are the single most important piece of design feedback you can receive in your early days. To this day, nothing helped me grow as a designer more than being responsible for answering support emails for something I designed. If you’ve never had to provide support for something you’ve created, you’re probably overestimating your abilities. Support is always important, but in your early days it’s critical.

Every application is different, but I hope my experience with Sifter can provide some context. We had 10,000 monthly active user accounts, and we averaged just under three conversations a day with about two replies per conversation. That means I wrote four to six emails to customers a day. Each of those probably took me five to ten minutes, so that’s twenty to fifty minutes a day for support. That’s also an average–there were slower days and busier days. Your mileage may vary, and your support commitments will likely correlate to how tech savvy your customers are.

For better or worse, I replied to support requests almost immediately, regardless of their time of arrival or impact to our customers. So I spent about thirty minutes on support over the course of each day, including weekends. But don’t rush your responses. A great response in an hour or two is much better than a crummy response in five minutes.

With Sifter, the vast majority of emails we received were feature requests. Whenever I started seeing the same question over and over again, I’d write a blog post to address it. The next time that question came up, I’d still write a custom reply, but having those blog posts in my back pocket let me shorten my response. Then I could include a link to other relevant posts if I felt a more in-depth answer was required.

This helped me in a couple of ways. First, it helped me cut down the time I spent answering emails. Second, by writing blog posts, I could use images to help illustrate concepts, and I could more carefully edit my thoughts. Customers ended up receiving much more detailed and carefully considered answers.

Unfortunately, while this let me reply faster and with better answers, it didn’t cut down the number of emails I received. The next step that helped reduce our support load was creating a page for frequently asked questions, which I linked to from our support request form. If people can find the answers they need without emailing, it’s a win for everyone. It’s faster for them, there are fewer distractions for me, and they don’t need to spend the effort typing their question.


Nothing beats self-service when it comes to customer success. The idea is to give as much control as possible to your customers so they don’t even need to email you. For instance, if you offer a trial period with your software, people will inevitably need extensions for various reasons. Once someone’s trial is up, your system has the data to know whether they’ve used it or not. With Sifter, I could have detected that a customer hadn’t created a single issue, and I could have given them a simple button to extend their trial on the spot without emailing me. I never built this, but in hindsight, I absolutely should have.

Bounce handling is another great way to reduce support. From time to time, there will be issues delivering email to a customer’s servers or a specific user. Sometimes, the user is a new employee whose email address just isn’t working yet; other times, there are DNS or hosting issues. Regardless, the emails bounce. For an account holder inviting their team to use the system, this can be problematic if their team doesn’t show up. So you could add bounce handling to alert them to delivery issues so they can fix it without contacting support.

There are countless ways to simultaneously empower your customers and reduce support. That translates to faster turnaround for customers and more time free for you to focus on other things. You don’t want to get caught up in premature optimization, but if you start recognizing patterns, see if there’s a way you can write a little code to enable customers to handle the problem directly.