Skip to content

Instantly share code, notes, and snippets.

@rosskukulinski
Last active August 29, 2015 13:57
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rosskukulinski/9358942 to your computer and use it in GitHub Desktop.
Save rosskukulinski/9358942 to your computer and use it in GitHub Desktop.
The Hazards of Proclaiming 'Fanatical' Support
http://kukulinski.com/the-hazards-of-proclaiming-fanatical-support/
Please feel free to leave comments here.
@rosskukulinski
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment