Hosting Partners  |  About Us  |  Blog  |  Legal  |  Portal Login

The Planet Blog

 
Posts Tagged ‘issues’

Sean OtmishiHi everyone! I started working at The Planet a few months ago in the technical support department, and I’ve really enjoyed my experience here. I’ve been on the customer side of technical support calls for most of my life, so I’ve never understood what it was like to be on the supporting side of the call. Now that my perspective has changed a little, I’ve noticed that the best customer support occurs when the support provider and the support requester work together to create the best experience possible.

Shelves of books have been written about providing great customer support, but I haven’t seen many written about how to get great customer support. When you work with a service-based company, you’re likely going to interact with customer support representatives regularly. During these interactions, your experience will not be defined by your question or the issue you have. Instead, it will be defined by how you present your issue to technical support.

It can be extremely frustrating when a server goes down or a script isn’t working the way it should. When this happens, my gut reaction is to get upset and throw my keyboard. I’ve also noticed that when I am angry, I have a difficult time trying to explain my problem to technical support. I’ve come to realize that I’m not alone in that regard, and with my newfound perspective, I came up with a few tips that might help you get the most bang for your buck when you work with customer support:

  1. Remember there’s a human on the other end. It doesn’t matter where the customer support representative is; they’re human, and their responsibility is to help you. I don’t have any empirical data, but human nature tells me it’s easier to be nice to someone who is nice to you. Once you realize there’s a person on the other end of the phone trying to do his/her job, it’s a little easier to thank them in advance for their help. It may seem insignificant, but if you thank me in advance for my help, I’ll subconsciously work harder in an effort to deserve that gratitude.
  2. Don’t assume your request will be ignored. I’m surprised by the number of people who start or end their e-mail with, “No one will probably see this, but …” or “Not that anyone cares, but …” Don’t assume that you’ll be ignored. That assumption is more of an overarching negative sentiment than it is a “reverse psychology” play. The support process can be defined by the expectations you set for it, so get started on the right foot and expect that your questions will be answered and issues will be resolved.
  3. Don’t start with a threat. “If you don’t do this, I’m going to report this to my bank and other authorities,” or “If you don’t respond within 25 seconds, you’ll be hearing from my lawyer” … It’s not uncommon to hear things like this in the first message in a ticket. Starting with a threat never helps your cause. It’s much easier to help someone who seems easy to help. Invoking lawyers does not make your ticket seem easy to address. :-)
  4. Provide useful, descriptive and relevant information. This tip can be tough since it’s hard to understand what information is relevant, but think about it before you send a support request. If you are having trouble logging in, then “I can’t log in. Any ideas?” is not quite as clear as “Whenever I try to log in, the login screen just reloads without an error message. I know my username and password is correct. Any ideas? Thanks.” That extra information will help considerably and will reduce the number of back-and-forth e-mails between you and the support representative.
  5. Don’t write overly detailed, wordy support requests. The longer your e-mail, the more difficult it is to read, diagnose and to respond. A representative has to read the entire ticket to find what’s meaningful and figure out exactly what’s wrong. Since they’re trying to help you, you want to reduce their burden. You want to make it as easy as possible for them to help you. So, be clear, concise and brief. If you’ve got a couple different issues for support to look at, break them out into individual tickets … different issues may need to be addressed by different departments, so multiple issues in a single ticket can lead to delays in responding to specific issues in the ticket.
  6. More Tickets ≠ More Support. Don’t create multiple support tickets for a single issue … While it seems like you are drawing more attention to the issue and creating a sense of urgency, you’re really slowing down the support process. Support representatives might be addressing the same issue in parallel or information might be lost between tickets, elongating the time to resolution.
  7. Escalate your tickets smartly. If you think a ticket should be handled differently or if you would like a supervisor to look into a specific issue, you should always feel free to request escalation to a manager or a supervisor. The best way to make that request is to update your open ticket, initiate a live chat or place a call into the technical support phone line. If you aren’t satisfied with your support experience, then we aren’t either, so we want to hear from you.

As you can see, the prescription is not too complicated: Prepare yourself to receive the best support, and you’re much more likely to receive it.

- Sean

Anthony LedesmaI’ve spent many years in various tech support roles throughout my career, regularly reviewing issues customers face. At The Planet, our goal is to provide excellent service for our customers, which usually comes through our support tickets. Most of our customers use the ticket system, so I thought I’d offer some thoughts on how to ensure we help you resolve outstanding issues quickly and thoroughly.

Here is an example of a support ticket that provides just about every detail that’s necessary to remediate the issue:

—–SNIP—–

Department: Support

Subject: New York City AT&T DSL unable to connect to my server in DLLSTX6

Server: servername-1.2.3.4

Body: My customer, Jon Smith, is unable to ssh into 1.2.3.4 on tcp/22 from 255.255.255.255. We have insured that Jon is not being blocked via iptables and he can connect to Apache on tcp/80.

[root@server ~]# iptables –nLChain INPUT (policy ACCEPT)target prot opt source

destination Chain FORWARD (policy ACCEPT)target prot opt source

destination Chain OUTPUT (policy ACCEPT)target prot opt source destination[root@server ~]#

[root@server ~]# traceroute 255.255.255.255

myserversgateway (1.2.3.1) 0.004 ms 0.020 ms 0.011 ms

1 dsr01.dllstx2.theplanet.com (12.96.160.9) 0.901 ms 0.944 ms 1.174 ms

2 …3 ……10 …11 255.255.255.255 (255.255.255.255) 42.211 ms 50.421 ms 45.114 ms[root@server ~]# ping 255.255.255.255PING 255.255.255.255 (255.255.255.255) 56(84) bytes of data.

64 bytes from 255.255.255.255 (255.255.255.255): icmp_seq=0 ttl=43 time=49.0 ms

64 bytes from 255.255.255.255 (255.255.255.255): icmp_seq=1 ttl=43 time=45.4 ms

64 bytes from 255.255.255.255 (255.255.255.255): icmp_seq=2 ttl=43 time=45.5 ms

64 bytes from 255.255.255.255 (255.255.255.255): icmp_seq=3 ttl=43 time=54.0 ms

64 bytes from 255.255.255.255 (255.255.255.255): icmp_seq=4 ttl=43 time=46.1 ms

— 255.255.255.255 ping statistics —

5 packets transmitted, 5 received, 0% packet loss, time 4003ms

rtt min/avg/max/mdev = 45.453/48.060/54.077/3.277 ms, pipe 2

[root@server ~]#

[customer@remoteserver ~]$ telnet 1.2.3.4 80

Trying 1.2.3.4…

Connected to myserver.tld (1.2.3.4).

Escape character is ‘^]’.

HEAD / HTTP/1.0

HTTP/1.1 404 Not Found

Date: Fri, 06 Jul 2007 17:34:37 GMT

Server: Apache/2.0.52 (Red Hat)

Connection: closeContent-

Type: text/html; charset=iso-8859-1

Connection closed by foreign host.[customer@remoteserver ~]$

ssh 1.2.3.4ssh_exchange_identification:

Connection closed by remote host[customer@remoteserver ~]$ telnet 1.2.3.4 22

Trying 1.2.3.4…

Connected to myserver.tld (1.2.3.4).Escape character is ‘^]’.

Connection closed by foreign host.[customer@remoteserver ~]$

You can login to my server with the credentials listed in Orbit. You can reach me any time at (555) 555-5555.

Thank you,Bob

Customerbob@remote.tld

—END SNIP—

Without ever logging into the server, our trained technicians are able to immediately identify the problem. The issue in this case is that either through a script(bfd) or other means, the remote user is being denied by TCP WRAPPERS (man 5 hosts_access). We are able to see that iptables are not blocking any connections, and we are able to reach the server without issue on another TCP port that’s not typically controlled by the wrapper. The customer ensures that the ticket subject was descriptive so that our technicians are able to evaluate the ticket in the support system queue. Each technician typically has a different area of expertise, so we work to steer the ticket to the right person for the job. Here is a list of subjects that provide helpful information for the support techs responding to the ticket:

  1. cPanel: WHM is not responding. Server is accessible via SSH
  2. Apache: My .cgi is giving a 501 error
  3. cPanel: Apache is segfaulting after I upgraded PHP
  4. Exim: User so-and-so cannot send outgoing form mail after tweaking security in cPanel
  5. Server kernel panics daily. Need to have the RAM tested/replaced
  6. MySQL: forums refusing more than 100 concurrent users
  7. Reboot Request**
  8. Network: San Jose, CA – 350ms RTT via Sprintlink

** #7 should not be a Support Ticket but a Reboot Ticket.

At The Planet, tech support is always eager to help resolve issues quickly and efficiently, so when customers add a bit of detail in the subject line, we’re able to ensure the ticket is routed to the most appropriate individual.

Just a few tips to help bring a quick resolution to a number of support issues. Thanks for stopping by.

- Anthony

 
 

Dedicated Servers

Managed Hosting

Colocation

Business Solutions

Why The Planet?

Contact Us