The Hazards of Proclaiming 'Fanatical' Support

gistfile1.txt

http://kukulinski.com/the-hazards-of-proclaiming-fanatical-support/

Please feel free to leave comments here.

Excellent post Ross!

To give folks some perspective, I'm gonna take the liberty to speak about the quality of support offered by Ross' own employer, ASTi. This company is known especially for its humble and personable engineers. A team of people who reach out to customers periodically to see how things are going. That's right: don't call them, because they've already called you. They'll reach out to you out of the blue to make sure your system is running as well as it was when they dropped in for the initial on-site integration. ASTi's world class customer support culture is ingrained in their engineers - it's second nature.

One day, after wrapping up a full 8+ hour work day at an industry conference my coworker and I dropped in to see a customer about their ASTi system (I was an ASTi employee at the time). It was an impromptu support call; the customer dropped by our conference booth earlier in the day and mentioned they were having issues setting up their ASTi system. No problem, we packed up our booth at the end of the day and headed over right after (read: we didn't go to dinner). We were on-site for about 4 hours helping the customer: first debugging sidetone issues on operator headsets, then looking at JavaScript errors on older versions of Firefox.

There are many stories like this at ASTi, I think every project engineer had at least one tale of support heroism. This is something I truly enjoyed about working there, and I think it's something only a small organization can realistically achieve. When an engineer, who deeply understands the source code, can go on site and debug customer issues - that is awesome. Or when they skip dinner just to make sure your system is ready for tomorrow's demonstration - that's fanatical support.

Thanks for posting Juan. Obviously scale and efficiency comes into play when comparing the support architecture of a large company and a small one. Fundamentally I think it comes down to two things:

1. Culture
2. Communication effectiveness

I don't have any doubt that Rackspace has a culture of 'fanatical' support. In fact, I know they do because I can sense it anytime I interact with a Racker. This alone is a great thing -- it's extremely difficult to shift company culture so the fact that they have this already is awesome. I think their problems (at least in the cases I've been involved with) result from failures to communicate effectively. Sometimes internally, other times its externally with the customer.

In regards to ASTi, I don't have a problem giving my personal cell phone number out to the customers that I interact with for three reasons:

1. There aren't hundreds of them that 'actively' need my help
2. We have a personal rapport with each customer. They know we'll tie ourselves in knots to fix their problems (even if its not due to our products). As such, they're not going to call me off-hours unless shit has really hit the fan.
3. Giving my personal number represents my attention to detail and eagerness to ensure that the customer (and his/her customer) is successful. Great product & support ==> successful customers ==> happy customers ==> more business ==> happy Ross

ASTi also has an advantage because our 'support engineer' is also a 'sales engineer' and he or she sits next to one of the 'development engineers' who builds the product. We don't have stove-pipe teams that rely on managers to communicate messages between teams (Note: I don't know the specifics of Rackspace's internal structure). As such, our flat structure allows for very efficient communication when supporting customers.

When you're a 'large' company you have scaling problems when supporting customers (as well as other things) and communication breakdowns are magnified by the number of stake holders.