Editing Customer Interaction (section)

= Customer service interactions and company philosophy =

Ok, this lesson takes a bit of a departure from the other lessons, in the sense that it is non-technical.  This lesson deals with the company philosophy and how we deal with customers.

The primary JohnCompanies philosophy is that we are a technical company. We are a technical company run by engineers.  There are no glitzy slogans or marketing campaigns, there are no gimmicks or hidden costs, and there are no silly, arbitrary restrictions on what customers can do with the products we give them.

When customers interact with JohnCompanies, there are no "levels" of support - there are no escalation procedures.  When a customer contacts JohnCompanies, the very first person they contact is a UNIX engineer that can solve their problem right at that moment.

So, what does this mean in the real world ?

First, it means that the only people that deal with customers are actual UNIX engineers.  There are no "front line" support personnel that answer some questions, but don't answer other questions, or pass them along to other people.  When a customer calls or emails JohnCompanies, they are immediately dealing with a person that can solve their issue.  Further, they are immediately dealing with someone that can go further – can suggest better options, can understand the configuration that the customer is using, and can offer additional advice or insight into their problem, or related problems.

Second, it means that there are no artificial divisions or restrictions in how the customer can contact us, or how they can present their problem to us.  For instance, some companies would require a customer to send a different piece of email for each different question or issue they had.  A customer would not be able to email a DNS request, and in the same email mention they need some additional disk space, and finally at the end, ask a quick question about their sendmail configuration.  They can do that here at JohnCompanies.  They can mix and match their questions in any way they want, because they know that whoever looks at the email will know the answer to all the questions, not just some.  So, there is only one support INBOX for freebsd systems, and one support box for Linux systems.  There is no seperate box for dns requests, or a seperate box for space increase requests, etc. (*)

Third, THERE ARE NO TICKET SYSTEMS AT JOHNCOMPANIES !!!  (or at least, not that the customer can ever see).  Ticket systems are impersonal.  Nobody wants to get the little autoresponse email, or have to stick with one topic in their email exchange, or be forced not to respond to certain emails, etc.  All email support at JohnCompanies is normal, back and forth conversational emails.  Email support will consist simply of real people replying back and forth in real email clients.  This way the customer can feel comfortable talking about multiple problems, digressing into other subjects, and generally getting a very personal touch.

Now, some specific guidelines for answering emails.

First, all answers will be in the form of complete sentences that clearly indicate what you mean and what you are telling the customer.  So
many times I see answers from other vendors that are not clear - I can't tell exactly what they mean.  All of our answers will be in complete
sentences, and those sentences will clearly reference the specific item that the customer is asking about - so that there can never be any
confusion as to what you are talking about.

Second, all questions in the email will be answered - no matter how trivial.  Many times a customer will ask an important, primary question, and somewhere hidden in their email is a quick side question.  Every item that the customer brings up in their email must be answered in the response.

Third, although we need to churn through support requests as fast as we can, and be as efficient as we can, we want to recognize all opportunities to give the customer a little extra information or advice whenever we can. So anytime it is clear that the customer could really use a quick example or a quick explanation of what you performed for them, or why something had to be fixed.

Some specific examples:

First, every time we respond to a DNS request, we always respond with:

"This is done - please test."

Encouraging the user to test the settings that were just put in place for them.

Second, any time we add a new firewall ruleset, or even change just the slightest portion of their existing ruleset, we always paste the entire firewall ruleset into their email for their reference.  That is, we tell them that the new rules are in place, and we then say:

For your reference, here is a copy of your current firewall ruleset:

(paste)

Third, anytime we reboot a virtual system for a customer (jailkill/jail on FreeBSD, vzctl stop then start on Linux) we always, in addition to telling the customer that we have done that for them, also tell them how long the system was down - we do this mainly to impress them, because when rebooting systems like this, the downtime is always 8-12 seconds.  So, after telling the customer that the system has been rebooted, as per their request, we also tell them:

"Total downtime was 8 seconds."

Finally - and this is IMPORTANT - ALL EMAILS WILL BE ANSWERED SAME DAY!! 
Any request a customer sends will be responded to and serviced that day. There are no "we are working on it" or "we will do this tomorrow" answers - any request that can be serviced that day (and there are very few that can't) will be.  Now there are some common sense exceptions to this ... first off, requests like space additions that require a confirmation from the person that sent it obviously cannot be serviced same-day - same with requests involving resets or downtime, etc., that need to be scheduled. Also, a request that comes in after you are in the middle of the final shift at night can be saved until the next morning - but no longer than that.  The point is, the customers will get their responses fast.

Further, any request that comes into the mailbox and is a very very simple one should be serviced immediately.  So much of our reputation and customer satisfaction is based on customers being amazed when they get a turnaround in 30-60 seconds.  So if you are working on something - a long support request, or some project, or something like that, and you see a quick and easy firewall add or dns add pop in, go ahead and stop and service that right away - see how fast you can pop it back out to the customer and amaze them.

(*) Actually there is an exception to this - there is a seperate inbox for
payment/billing/account issues - and someday we might seperate out a box just for dns requests, but that will be all.