Can young companies deliver better business critical support than large companies? »

As the CEO of a young company that is growing rapidly, half my time is spent in the field with customers, channel partners and prospects. The initial discussion is primarily on our technology and value proposition. We have been fortunate in that many of those conversations turn quickly into strong interest from our prospective customers.

The discussion then focuses on our ability to support the customer, given our smaller size. In many instances, it is at this stage of the engagement that our competitors start creating FUD (fear, uncertainty, and doubt) about our size. For instance, a few days ago, an account executive at a large competitor had sent our prospect (his customer) an email explaining in great depth as to why we would be unable to match their support expectations. He was basing this claim in part on the fact that even they, a much larger corporation, were hard pressed to satisfy the customer despite their size and resources.

I think that every customer should rightly inspect why we think we can match or exceed his or her
support expectations, and why we can perform better than much larger companies in this regard.

Customer references are great proof points

Ultimately, the best proof point comes from what our customers say about our support and our sales teams draw upon a large base of happy customers as references. So, let me start with some recent examples of unsolicited customer emails as proof-points before I describe how we deliver support:

• “Thank you, team, for the detailed technical report as well as your assistance in proactively addressing the issue. You have a truly exceptional team and I can only wish that all of our vendors/partners were as responsive and effective as Nimble.”
• “Dan, Got your vmail. Thanks for the update. I do appreciate Nimble finding potential issues and proactively resolving them before it affects our systems. Thank you!”
• “This isn’t hard enough! I need thick manuals, on-site field engineers, complicated support web site, a-la-carte licensing charges for using the product’s advertised features, complicated spreadsheets to document configurations, maybe even a storage specialist, etc. Something is very wrong here.”
• “Last Friday night around 8:30pm, one of our employees accidentally deleted some very important documents and I was with my family in a restaurant, can’t get to a computer right away. I told him to call Nimble support, he received help right away and the data was restored. Now that is customer service!!!”
• “Chris, Just wanted to say that the below email from Nimble is very impressive. Never would I have seen the email below come from any other vendor that includes specific information pertaining to our device and letting us know what would fail and how to fix it before we have even performed the upgrade. All I can say is WOW.”

Core philosophy driving our support approach

We started off with a deeply held belief that product supportability needs to be thought of as an aspect of the product, and an area that is as ripe for innovation as any other aspect of the product. We hired support architects a year before the product shipped, and assembled a support team that has built and fine-tuned remote support automation multiple times in prior companies. There are some core beliefs that underpin our approach to delivering support:

1. The lifetime value of a customer trumps any single deal, and support is crucial to a long-term relationship.
2. In a wired world, we can be always connected to our systems. This should allow us to track events affecting our systems at the same time or sooner than our customers. Furthermore, being connected to our systems should allow us to directly access the systems and fix issues much faster by leveraging our deeper knowledge of our systems.
3. As support teams grow, training and expertise cannot keep pace unless we automate as much as possible.

These beliefs have led us to deliver a model of support that is
dramatically ahead of the storage industry.

Our approach to support

I will start off by saying that while we have done a lot already as described below, what excites me more though is that we have laid a foundation for how we plan to scale support and every release and every month allows us to do more.

1. Real-time telemetry: Can we know everything possible about our systems at our customers’ sites?

We all have had instances where a support person starts by asking if the equipment has been powered on, and then proceeds to ask hundreds of mundane questions. We wanted to avoid this. Many vendors in the industry are able to receive daily logs from their systems. We have dramatically enhanced this capability and our systems send diagnostic, configuration related and operational health information every few minutes!! We have architected this such that our systems can send information even if they are unable to serve data in most cases. All of this information is parsed into a database infrastructure that maintains a detailed history for every system in the field.

2. Comprehensive background health checks: How are our systems doing?

We then run a variety of health checks that are constantly measuring the state of every system. We are always updating and increasing the set of checks to make them more comprehensive, as we discover any new issues. For example, during a recent release upgrade, one of our customers found that certain wild card characters in an encoded password would cause issues with authentication. We were able to query our database and rapidly identify the specific customers and the exact systems and volumes within those systems that would be affected and alert them with the corrective action before they encountered the issue!

3. Automated alerting and case creation

The main goal of the constant health checks is so that we can react rapidly to issues with the least amount of lost time and disruption. To this end, our support team is immediately notified of any error that is detected by the health checks, and they proactively call the customer when that happens. Our case management system is able to auto-create a case when the health check can definitively point to a known error or defect or disruption. Some of my best customer anecdotes are when a customer describes a call from our support organization enquiring about the health of a system when the customer had just been reconfiguring a test system for some internal tests.

4. Automated case resolution and prevention

Beyond being able to react quickly, we are increasingly focused on automated case resolution. To this end, our engineering and support teams are focused on correlating a health check alert to a definitive error and beyond that to known solutions that can correct the errors. For example, we can send the customer a knowledge base article if we can definitively correlate a health check alert to a known issue with a known resolution. Another example is that in our systems, recognizing that configuration changes can prevent many problems from occurring in the first place, we have the ability to target specific arrays or groups of arrays and send specific instructions remotely that reconfigures the arrays to avoid an issue.

5. Secure remote access: Can we mimic onsite presence?

Despite all of the above, there will always be instances where a problem has been escalated and needs engineering involvement. In those instances, our approach has been to try and recreate an experience that mimics us being onsite. To that end, our arrays are pre-configured (upon customer delegation) to create a VPN tunnel that allows our engineers to work on the remote system without asking the customer to collect a number of logs and other diagnostic information before engineers can be productive in engaging on the escalation. On numerous occasions, the customer completely delegates the array to us, as we diagnose and fix the issue remotely.

People and culture: The first and last line of defense

Ultimately, the support that a customer experiences when faced with a problem is perhaps more “people-dependent” than any other interaction between a company and its customers. While technology, tools and training can help, the quality of the support interaction depends very much on how the person delivering support feels about the company he or she is working for. In that respect, we at Nimble are fortunate in that we are intensely proud of what we are building and have a strong desire to make every customer successful. Maybe that is the real answer to why we can support our customers better than our larger competitors!