We are here to help. That should be the mantra of any good technical support crew. After all, it is their job to provide support. Providing consistent quality support is challenging. You have to be abreast of the latest bugs, exploits and network issues; you have to keep up with the latest software releases; you have to be ready to handle an emergency at any time. Meeting these challenges takes training, experience, and, most importantly, good communication.
Generally, communication takes two participants. There are a few of us who enjoy talking to ourselves but that's an entirely different matter. Clearly communicating the technical issue does not require understanding the benefits of dense wavelength division multiplexing for fiber optic communications. A simple understanding of internet services will do. We find that for most minor support issues as much as 70% of our time is spent getting the necessary information to understand the issue. Once we have what we need, the problem can be resolved quickly.
To help you help your support team, we want to share a few common support issues and how you can help get the issues resolved quickly by providing quality, pertinent information up front: a Dos and Don'ts for requesting support.
Now "Don'ts" does not mean you will not get support from your crew, they should be happy to help. Don'ts will simply take more time to resolve. More time often means grumpier clients and higher support costs. Consider these issues and how providing clearer information can help your support team.
"Email is not working."
Short and to the point, this should be simple. Unfortunately, email systems are not single programs. On most servers, there may be multiple items involved with email services. Typically, the program that allows you to send email (SMTP) is not the same program that allows you to receive your email (POP3/IMAP). The method by which you authenticate yourself (login) to check your email may not be the same method that is used to authorize you to send email. On many servers, as many as a half a dozen underlying programs may be involved handling email.
Some programs operate server wide. Consider the case where a single user is having problems checking their email versus all users cannot check their email. In most cases, if a single user cannot check their email, they are either using an incorrect password or having network issues. If all users cannot check their email, then the problem is likely an issue with the POP3/IMAP service. It may be offline, overloaded or otherwise unreachable. The same can often be said for sending email. If no users can send email, then there is probably a problem with the SMTP server.
A common issue with email is authentication. Most recent mail servers require you to login (authenticate) to both send and receive email. Behind the scenes, the service that authorizes you to check your email may not be the same as the one that authorizes you to send email. So it is entirely common to have a user who can receive email but not send.
It is important, when sending support requests, to specify account information, especially if only a single user is impacted. If reporting a server wide issue, your techs will often find it useful to have a few email accounts that they can test. Providing just a few (3-4) user details is often all that is required to put your tech support crew on the right path to getting the issue resolved quickly.
Keeping all this in mind, instead of "Email is not working," a more helpful request would have been:
"I have an Ensim 4.0.3 server running Fedora Core 2. Several users cannot send email. They are getting new messages and can check email via Outlook but they get an error when trying to send. A few of the users having issues are: bob@domain1.com, jane@anotherdomain2.org, and joe@domain3.com."
Now, when I read this I start diagnosing the issue immediately. If I am abreast of recent bugs for your platform, I may already suspect the culprit before I even touch your server. From this request, I know POP3/IMAP is working because people are checking email successfully and SMTP is working because they are getting new messages; however, SMTP authentication may be having issues, a known issue on Ensim 4.0.x on Fedora Core 2.
A simple revision of the original request could save as much as 10-30 minutes in communication and resolution. So when reporting email issues, a quick guideline to use is:
- Is the problem sending, receiving or both?
- Is the problem with a few users or with all users?
- Are new emails being received?
- Does webmail work but Outlook (pop3/imap) clients do not?
Including answers to these questions and providing a few example email accounts will help your support team get right to work. Answering these four questions could easily trim 30 minutes off of many email support issues we receive.
"My website is down."
Fortunately, most people include a bit more info, but not always. Keep in mind that many techs deal with hundreds if not 100's of thousands of domains, so "my site" may not ring a bell in their over-caffeinated brains. When reporting website issues, be specific. Like email, a large number of programs drive a website. A single site may require Apache, MySQL, Perl, and PHP. All of which could be the cause of an error. Though website problems can be complicated, there are a few major categories that you can identify easily.
A key distinction in understanding website errors is if the issue impacts all sites on your server or just a few. If the Apache web server has crashed, all of your sites will be down. If only a single site or a few sites cannot be reached but others respond fine, then DNS or an Apache configuration issue may be the cause. Checking a few of the sites on the server can immediately limit the scope of the problem. When you report the issue, be sure to include examples of sites that fail and sites that work.
When reporting website problems it is very informative to distinguish from web server (HTTP) errors and application errors. For example, 403, 404, or 500 messages are specific HTTP error codes indicating an error with the web server itself. A PHP error message does not necessarily mean that there is a server problem. PHP errors can result from programming mistakes, failed database connections, improper file permissions and PHP configuration issues. You can quickly determine if the issue is with HTTP (Apache) or your application by calling an image file. Images are static files, so no scripting is involved. If you can load an image fine but the web page fails with a PHP error, then the problem is likely not with your web server but with an underlying system with which it depends. When reporting website errors, always be specific. Include the URL and copy the error message that you get.
We often get reports that some people cannot access a website while others can. When this occurs the problem is typically due to network issues at the users' ISP or your server provider, but there are a few cases where server issues could be responsible. A key server problem is firewalls and htaccess files. We often see firewalls or htaccess files block users. To help your support staff identify this area quickly, you may need to get the end-users' IP addresses. Various websites like www.whatismyip.com make it easy for end users to get their IP address. When reporting such issues, provide a URL and the IP addresses of people that can and cannot reach the site.
Of course there are many more scenarios regarding website problems, but these are common ones that by submitting an informed request, your tech team can resolve the problem quickly. In general, when reporting website issues we suggest including:
- Provide the URL to the page in question. Not the site. Be specific. If the page requires authentication, then provide a valid user name and password.
- Indicate if all users get the error or if only some users see the error.
- Indicate if the error happens on every request or just occasionally.
- If access issues are a problem, include the IP addresses of a couple of people that can reach the site and of people that cannot reach the site.
Also, if you have the information, it is useful to note if a site depends on a database or another site or not. If a database is in use, provide the database's login information.
So using the guides above, the original request, "My website is down." becomes:
"I cannot access two sites (www.some-domain.com and www.xyz.com) on my server, the other sites are fine. However, some users can access all sites. My IP address is 192.168.1.1. A person that can access the websites has an IP of 10.20.30.40."
This immediately points to an htaccess or similar access issue. Firewalls typically do not block people on a per-site basis, so this is likely not a firewall problem. A little bit of info will help your texts quickly identify the problem.
"My server is down!!!"
This is probably the worst one you can send to your support team, especially via a helpdesk at major dedicated support providers. Support crews see this often. While it undoubtedly expresses your frustration, the message means something very different to that Level1 tech, who says, "His server is not down; it responds to ping and ssh!" You then find your ticket closed.
The problem here is simply semantics. To you, "my server is down" may mean you cannot access your site, the control panel or your email. To the tech, it means your server is offline, powered off or otherwise completely unreachable. So they ping your server and close the ticket or just put in a reboot.
A reboot may not fix the issue. Linux can boot into a single user mode where only SSH will come back online. Your website, email and other services will remain offline. At several server providers, I have seen scores of support tickets, each with more frustrated language.
This confusion can be avoided. Instead of saying your server is down, say, "My control panel is down!!!". The exclamation marks will still get your point across. The key difference is that the tech knows not to simply reboot your server, test ping and ssh and close the ticket. The tech knows they need to login to your server and find out why your control panel is down.
In short, be specific. Yes, it is your support team's job to fix the problems, but you can help them, your clients, and your wallet by including just a few key bits of information. Providing key information is critical to a prompt resolution. Don't flood your support crew with forwarded emails, screen shots and other items unless they specifically request them. For many email and web issues, the information outlined above will be all they will need. Be brief and specific. This way you can help your helpers help you.
