Good customer support has been a cornerstone of how we do business at DNSimple since we launched in 2010. It isn't always easy to provide the level of support we want, but it is fulfilling when we do it right. To that end, today I would like to show you how we do customer support at DNSimple.
First, I've created a diagram that shows the functional areas within DNSimple:
As you can see, the 5 core functions are Business Operations, Customer Acquisition, Customer Support, Research & Development and Technical Operations. Let's focus in on Customer Support.
There are three core elements to how we handle customer support:
In today's post I'll cover customer assistance. In future posts I'll write up more on how we approach customer education and how we respond to incidents.
While we do our best to develop software that makes DNS and domain names as simple as possible, sometimes you need a helping hand from a human. At DNSimple, that could mean anyone on the team.
At DNSimple, everyone is a member of the customer support team. When someone joins DNSimple, regardless of their primary role, they are given an account on Groove, the customer support tool we currently use. With this account they now are part of the DNSimple support team.
There are a few features of Groove that influenced our decision to choose it when we evaluated support tools.
First, it had to be easy for us to direct inbound support email into the appropriate support queue. Groove can have multiple mailboxes, each set up with its own inbound email address. This allows to have a queue for firstname.lastname@example.org as well as a queue for email@example.com (which is where we receive all security issues reported by researchers).
Next, it had to work well with email. Specifically, our customers needed to be able to simply send us an email, and our response would return to them via email, and then they can continue the conversation that way.
Finally, it had to have a way for everyone on the team to contribute and still be cost-effective.
Groove met all of those needs, and along with some other nice-to-have features and a clean UI, it turned out to be a good fit for us.
One of the nice elements of Groove is how we have been able to integrate with our application. Groove includes a feature that allows us to add custom information to the sidebar of any ticket. With this feature we are able to provide links to manage a customer's account directly from within Groove. We can also display information about each customer, such as their current subscription level.
Groove also integrates with Twitter. We recieve questions on Twitter from time to time and using the Twitter integration in Groove any member of the team can respond from the @dnsimple Twitter account. This saves us significant time and energy and has allowed us to better respond on Twitter when necessary.
Having a good support tool is just the beginning though. Any tool is just a tool until it is skillfully wielded. With that in mind, we came up with a simple set of rules for how to answer support:
Intelligent, kind, helpful responses are more important than speed, but leaving a customer in the dark, especially when they are under duress, is worse. Thus, our goal is to respond with a thoughtful response in a couple hours of first receipt of a ticket, but no more than 24 hours after receiving the support request.
Ideally a support request requires minimal research and can be answered as soon as someone from the team looks at the ticket queue, but sometimes it takes longer. In cases where the response requires more research, we will simply tell the customer that. At the same time we will ask for additional information to help troubleshoot issues. Customer support is a conversation, and thus there it is normal to communicate back-and-forth while finding a solution.
I'll be the first to admit that I have, at times, been angry at a business for one thing or another. In the past I might have taken that out on the support representative who answered the phone or responded via email, but after helping customers for several years now, I know what it feels like to be on the receiving end of someone's anger and frustration.
Still, I know that from time to time we will receive an email from someone who is angry at us, and our response should always be kind. It can be firm, but it should be kind none-the-less. We owe it any frustrated customer to listen to them, to empathize and to see the issue from their point of view.
While we don't publicize our refund policy, we have always had one internally. The goal is simple: satisfy the customer, if they are not satisfied then refund them if appropriate.
The three rules outlined above represent the foundation for any answer we craft in response to a support request, and they essentially represent the way the DNSimple team and I would like to be treated when we ask for help from a company whose services we use.
There are numerous benefits of having everyone on the team handling support.
One of the benefits of having the entire team handling support is that no one person is forced to handle the burden of support. Since the DNSimple team is located in several timezones, we often have team members coming into the support queue to answer tickets at various times of the day, which is a good thing, because it means that a team member is less-likely to see a massive queue and feel overwhelmed. It also means customers tend to get better response times for support requests.
Another way we try to avoid support burnout is by turning common support requests into better documentation on our support site.
Finally, we also make sure to help each other out. If someone is getting overwhelmed by the support queue, they will speak up in our chat room and another person from the team will jump in and help get the queue down.
When you receive a support response from someone on the team, you are not receiving a scripted response from someone who is hired to block and tackle, rather you're talking directly with one of the developers here. Removing the multiple layers of customer support means you get better answers, faster. This also cuts down on the overall time needed to deal with issues because a developer can identify critical issues and fix them quickly without necessarily needing to ask for someone else to step in.
One of the greatest benefits of the entire team seeing and responding to support requests is that it becomes clear what parts of our system are causing the most pain for our customers. Repeatedly responding to the same type of support request usually means we are lacking good documentation on how to use an existing part of the app, or that the application user experience is not intuitive and clear, or perhaps both of these things.
For instance, the design and deployment of an SSL certificate installation wizard and the article about transferring a domain to without downtime are both the result of our team members' daily involvement in customer support.
Support tickets can often point to hard-to-reproduce bugs in the system as well, and having someone to communicate with to get deeper details about the failure can be a godsend when trying to debug a challenging problem.
Just so you don't get the impression that we got everything right from day 1, we've had failed experiments around support too. At one point we tried out the idea of a Customer Champion, which would be one person who would be responsible for support for a particular period of time. Poor Javier ended up being the initial guinea pig for this experiment, and while he learned a ton about what our customers pains were it turned out that having one person spearhead customer support for a period of time was not a sustainable approach for our team.
Providing intelligent and kind customer support isn't easy, but it is a core part of what makes DNSimple what it is. It's also not something that we consider finished - we are always looking for ways to improve our customer support. If you have any thoughts on how we can do better, please get in touch - we'd love to hear from you.
I break things so Simone continues to have plenty to do. I occasionally have useful ideas, like building a domain and DNS provider that doesn't suck.
Configure HTTPS redirects with our easy-to-use DNSimple Redirector and a certificate from your DNSimple account.
With GDPR is WHOIS Privacy still necessary? Read on for our opinion.