How to Support 5,000 Customers with No Support Staff

Last week, New Relic hit another incredible milestone: in just two years on the market, RPM has skyrocketed to 5,000 production-deployed customers around the world. 5,000 customers in 2 years. That’s amazing to me! My previous company, Wily Technology, took 8 years to reach 500 customers, prior to its acquisition by CA. This time around, we are clearly we are doing things a little differently in tackling the app performance management problem. One particular difference is how we support such a large, diverse customer base.

This morning, I looked at New Relic’s support queue and dashboard (courtesy of Tender, a slick SaaS customer support offering brought to you by the great folks at ENTP, a longtime New Relic customer.) I saw some pretty good metrics for such a large customer base: 14 Pending Issues, 1 of them pending today, and an average response time of 10 hours.  We are continuing to work on our average response time and would like to see that be lower.  But when you think about it, same-day service across the entire customer base is pretty good, given that the majority of our customers are getting free support for RPM Lite, a free product.

New Relic's Support Queue

It will probably surprise you to find out that we actually have no dedicated support personnel inside of New Relic!  Each and every support request is handled by a development engineer who has full access to our entire source base, and the full authority to do whatever is necessary to make things right. This includes agent tweaks, production patches and – on rare occasions when we mess up – free upgrades to RPM Gold. Our engineers also have an after hours on-call rotation for urgent issues raised by our Gold customers.  So our Gold customers can call any time, day or night, and get a New Relic engineer on the phone within an hour.

So how can a small company of 32 people support 5,000 customers with no support engineers?  In a nutshell, it’s about product quality. Not just fewer bugs, but a more intuitive product that’s easier to use and understand. If the product just works, the customer won’t need to reach out to support in the first place.

We have our engineers take support calls because engineers like to code their way out of the support queue rather than execute manual repetitive tasks. Instead of coming up with one-off workarounds for specific customer issues, our team is more likely to implement solutions that the entire customer base can benefit from. Some of our best product ideas come out of support cases. If we can avoid future support issues by adding a feature or fixing a bug that makes the product easier to install, use, or manage, then everybody wins.

Also, our customers like the fact that they are working directly with some serious technical talent. We will never ask our customer if they restarted their computer as our first step towards problem triage.

We also see yet another benefit of being a pure SaaS provider. 95% of our source base is running in production in a single data center over which we have almost complete control. So we don’t need to wrestle with figuring out why a customer is having a problem with a data collection server in their environment. Or if another customer has trouble making sense of data that the RPM user interface is presenting, they can send us a link and we can look at the exact same page. In my previous company, both of these issues would require either an on site customer visit, or months of back-and-forth emails of log files and screen shots to isolate and address the problem. Today, these types of problems are resolved in minutes, and usually benefit the entire customer base as soon as we push to production.

At some point, New Relic will be a large enough company where it makes sense for us to have a separate, dedicated customer support team. It’s hard to imagine our developers handling every support request from a customer base of 50,000 or 100,000 customers. (Yes, we set our sights high!)

Until then, I think it’s great that our development engineers have responsibility not only for writing great software, but supporting it too.  In the long run, I think it makes for happier customers and a better product.

Founder and CEO, New Relic View posts by .

Interested in writing for New Relic Blog? Send us a pitch!