We’ve been running DoneDone for the past six years, growing from a small app with a few customers here and there to a critical business tool that’s helped tens of thousands of users resolve issues in over 140 countries.
We’ve picked up and moved our entire hosting environment twice, while fundamentally changing our technological infrastructure each time. We’ve gone through an overhaul of the UI four different times in six years. We’ve added dozens of big new features and enhanced hundreds and hundreds of small ones. Undoubtedly, much has changed since our humble beginnings in the spring of 2009.
However, there have been a few ways we do business that haven’t changed much at all. One of these is how we handle customer support. Our technique for working with our customers has historically been pretty hands-on and low fidelity. I wanted to give you an insight into how we’ve done things up until now, what we’re tweaking, and a few lessons learned along the way.
Getting good by repetition
Last year, we worked on over 2,500 unique customer support requests. They ranged the gamut – from feature requests to system bugs to questions about the service to billing issues to seeing if we had any extra Field Notes to give away (which we did!). If you’ve written to us via Twitter, our support form, or an email, either Jeremy or I wrote back to you directly. It just so happens we’re the primary developers on DoneDone. That means we don’t have to hand off a ticket to tech support or the billing department. We really do manage most everything.
An average day sees us collectively spending about an hour of our time helping customers – significant enough to make this part of our daily routine, but not yet intrusive enough to pull us toward automating things yet. Besides, we cherish the personal connections we make with our customers. If you’ve written us more than a handful of times, we definitely recognize your name. We can probably tell you what city you work in and what your company web site looks like, from memory.
However, we are programmers. And programmers have a natural tendency toward replacing inefficiency with efficiency. To that end, we’re working on a couple bigger objectives over the next few months. We want to get back to your questions faster, and provide you with more detail than simply asking you “Did you try X, Y, and Z?”. But, we don’t want to sacrifice that personal touch solely in the name of efficiency. Here’s two ways we’re going to do that.
The DoneDone Knowledge Base
When you’ve gone through a few thousand questions over the years, a handful tend to rise to the top. For the most common ones, like “Can I bulk edit issues?” or “How do I change my account domain name?”, we’ve saved our replies so that we don’t have to reinvent the wheel.
As we talked about our objectives for 2015, the main theme was to keep improving our customer support. So, today, we’re excited to announce the new DoneDone Knowledge Base. We’ve curated our most common questions into a central portal. For incoming requests, we’ll still be answering them individually, but we can now reply with a link to a page with step-by-step directions and screenshots. This will make us more efficient, but also provide you with even better direction.
A Central Administration Portal
It may come as a surprise to some, but, we don’t have a central administration tool in DoneDone. Instead, our administration tool is really a suite of tools. We go right to our billing software for billing issues. We query our own database backups using Sql to get to the root of a technical issue. We look through logs in our logging database for server errors, and the AWS web portal to assess the overall health of our servers. The nature of our administrative digging sounds crude. But, it’s helped us solidify the most common sets of administrative tasks we perform. In parallel, we’ve kept a writeboard open in Basecamp to detail the exact steps to take for each kind of common issue.
Having worked on many web applications prior to working on DoneDone, I know how administration tools tend to look like half-baked, stitched together web pages full of bloated extra features, as if there were no specs or wireframes used to build it. That’s because they usually are half-baked, stitched together web pages full of bloated extra features because there were no specs or wireframes used to build it.
I think this happens when you try to build a central administration portal too early. It’s hard to predict what features make sense. You may build all sorts of user administration reports that you end up not finding important. Even more likely, you won’t think of all the features that you’ll later find really handy after working with hundreds of customers.
Six years in, it feels right. Our writeboard has a list of about 15 common processes we do for customers that we can now work on baking into code. We now know that trial extensions, freeing up domain names taken by now canceled customers, and making billing updates for accounts whose owners have left are three of the most common things our customers want. We can focus on those features first, and leave out all the other potential guesses.
We hope you’ve enjoyed your experience with us, and enjoy it even more with the updates to come!