In this post I’ll share my thoughts on hosting provider technical support – in general. What it is reasonable to expect from tech. support, what kinds of problems one can face etc. A post from WebHostingTalk forum got me to finally write down my thoughts on this subject. It is all written from a client’s perspective (mine that is). Any return info of how exactly it looks like from provider’s point of view is more than welcome in the comments section at the bottom.
Update: I also wrote about prejudice toward “foreign” technical support.
Contents:
- Introduction – technical support in general
1.1. Technical support job - Asking a question / reporting a problem
2.1. Don’t… unless you have to
2.2. Contacting technical support
2.3. Extra tips for communicating with technical support - Technical support scope – client’s perspective
3.1. Customer computer problems
3.2. Asking “a stupid question”
3.3. Some problem with the server – on provider’s end
3.4. Third party software related problems – “Catch 22” - Conclusion
1. Introduction – technical support in general
While I’ve never worked for any hosting provider, I do have around 20 years of experience in the IT industry, including providing and organizing technical support. While I’ve been actively using hosting services for around 5 years. So I do have some idea of what it looks like “from both ends”.
In order to estimate technical support quality, I think it is important to understand what kind of work that is. Those who think they shouldn’t care – they should just fix it all – can skip this entire article and I wish them all the luck in the world with finding a good support and hosting service that suits them (not being sarcastic – I understand and respect that stance – at a high enough price such service is available).
1.1. Technical support job
Tech support job is about getting things back to how they were – when it all worked. You spend all your knowledge, experience and energy to fixing what’s broken. Hardly ever creating/designing something new.
Most of your communication is with people who are frustrated because something is not working. On a bad day, after you’ve had literally about a 100 phone calls, even if Beyonce call’s you to ask for a date, you’d be like: “Madam, please try to sort it out with Jay Z first, this is beyond our support scope. Thank you for calling and let me know if there’s anything else I can help you with. Have a nice day.” Hanging up the phone with another line having started ringing at the same time… yes I prefer tickets, even as a user/customer (wrote about phone vs ticket support). Of course, there are nice days, without too many problems and with the reported ones being solved quickly, with everybody being happy. 🙂
A vast majority of problems/questions asked have been answered about 10,000 times before and included in the knowledge base, FAQ, or are easily “Googled”.
If 5 problems each need 5 minutes for resolving, while the 6th needs half an hour, fixing the “smaller” problems first makes a total average client waiting time a lot shorter, than it would have been if the problem taking half an hour was solved first (22 minutes, instead of 43 minutes average waiting time).
“Trivial” problems can sometimes turn out to be complicated and take a lot of time to resolve. Clients most often can’t estimate how “big” a problem is – it is usually “only 5 minutes for you” in their opinion.
Vast majority of clients considers their problem to be (the most) urgent, while very few are objective and even they can’t know what the nature of other customer problems “in queue” is. So when a client says something is urgent, it means: “this client would like this to be solved right away” – nothing less, but nothing more than that.
The point of hosting and technical support job is, like with any other service, to make clients happy. Not to make it all work perfectly. This is something that even many providers don’t understand. Of course, it is good when it all works – if there are many problems, customers won’t be happy.
But from my experience, solving a problem quickly and just reporting “solved” is often recieved poorly (my guess is: “if it was that easy, it should have been prevented”), than putting in the effort, explaining all the complications, patiently listening to the client without solving the problem!? Not always, but often enough. Yes it is strange, people are like that.
I’ve heard people complain about this with some hosting providers:
“They just closed my ticket!”
” – Did they solve your problem?”
“Well, yes, but…”
2. Asking a question / reporting a problem
I believe this chapter’s title sounds a bit silly. When I explain the first steps, I’m sure it will sound even more silly. But it isn’t. How to ask a question, or report a problem?
2.1. Don’t… unless you have to
First check everything on “your side”. Starting with your computer and modem/router power supply (how to determine potential causes of website connection problems).
Write down all the changes you make to your websites – maybe some of those caused the problems, so “undoing” them could solve them. Oh, and do have backups – always.
Check provider’s F.A.Q, knowledge base and Google: perhaps the answer already exists – most of the time it is so. Doing things this way helps you gain valuable knowledge and experience. Write down solutions that work. Not necessarily on a website (like I do), but keep them somewhere – that saves a lot of time in the long run.
Also check provider’s announcement / outage report page – you don’t want to be the 1,000 th person reporting a problem they are well aware of.
Finally, if all else fails, write down exactly how the problem happened. What you tried / tested to confirm it really exists. What you tried doing to solve it. In a structured, chronological manner. This often helps getting a lightbulb “Eureka!” – so you still manage to solve it on your own. If it doesn’t, that info is valuable to tech. support (an example of customer info helping tech. support solve the problem).
2.2. Contacting technical support
If you can’t solve the problem on your own, of course, you should ask for (professional) help. Assuming you want the problem to be resolved (as quickly as possible), I’ll list some good and bad examples:
“Nothing works!”
This is a completely useless piece of information. Common variations are: “Something’s wrong (with my website)”, “I have a problem” etc.
Calling out problem cause, without explaining the symptoms.
What I mean by this? For example, saying “My IP address is blocked”, when you aren’t able to log into your website control panel and/or view your website. There could be numerous reasons for being unable to do this.
More useful info would be: “I can’t open my website, nor log into the back-end. I get ‘this and this’ browser error when I try to. I can see all the other websites normally. Trying to view my website using phone provider’s network, over a smartphone, works with no problem. I’m suspecting my IP address is blocked.”
The latter approach provides all the important (noted) problem manifestations, explanations of exactly how and when it occurs. With your (assumed) “diagnosis” given at the end. Technical support will always be more likely to rely on the provided information, than on a problem diagnosis by someone who’s knowledge level is not 100% confirmed.
An example of a detailed info provided to technical support.
2.3. Extra tips for communicating with technical support
Try to be clear and precise.
Several short sentences is good. One very long sentence is often counterproductive. Like this paragraph. It could have been written in one sentence, but it wasn’t.
Remember that you are just one of a thousand.
Bear in mind that the person that is trying to help you (they usually are doing that, no matter how it looks) might have a phone ringing all of the time, or many support tickets all at once, with various problems. Also, there could be a change in shift, so another person in a similar “situation” takes over. This is somewhat related to the first and the next paragraph in this chapter.
There are no stupid questions.
Some questions might sound stupid, or needless, or you think you’ve already answered them, but answering them is valuable to the support staff. In my experience: “Do you have electricity?” is sometimes not a stupid question – had people report computer problems while their entire building block had an electricity cut out.
There’s also the “cover my ass” legal stuff, so some questions/answers are recorded and rephrased to fit the lawyer dictated form, being equally pointless to all the parties involved, but still necessary.
“Deaf phones” effect.
Phrase the request and information you provide so that it can easily be relayed to other colleagues. No one knows everything, but usually someone knows how to solve your problem.
As kids we used to play “deaf phones”. You get in a row. First one whispers a sentence to the next one in line. Then it gets relayed to the end. No “repeat, I didn’t understand” was a rule. Final result was very funny most of the time. But if a sentence is simple, clear and with no “tricky” words, it often got unchanged to the end.
The only example I can think of now is pre-sales communication with a hosting provider on their virtualization methods, resource limits enforcing and similar. I had realised that the person I was talking to didn’t know the answers, but they were willing to ask senior colleagues for help. So, after some 5 back and forth emails, I had rephrased all the questions so that YES/NO answer worked for me. That did the job.
It is important to be nice.
Be considerate and polite. I’ve had support staff do things beyond their job description, just by being patient and showing appreciation for any help, while explaining why I can’t do it myself (and what I did try – like googling, testing etc.).
Computers and software get broken. And get fixed. Getting rude and/or upset rarely helps with that.
Write things down.
So you know exactly what you did and in which order. What you tried, tested etc. Provide that info in a form of a PS, or an attachment. Technical support might not bother with it, but if you write it in a clear and point of fact way, those worth their salt might just “bother” to read it and maybe get an idea how to solve your problem (in case they got “stuck”).
Language barriers.
Be tolerant to the language barriers. Some of the top experts I’ve worked with speak extremely bad English. Top like “world class, don’t know who else I’d ask”, not like “can’t afford to pay for good service, as good as it gets on a budget”. Though, this has changed in the past decade to some extent. Wrote more on this in the post: Prejudice with “overseas” technical support.
The bad and the ugly.
Having said all this: some companies simply don’t hire good tech support, or overload them – so you get poor service. If/when that is the case – look for an alternative. Unless you’re tied to a company with a long term contract (or do it in spite of that, loosing some money is sometimes more profitable).
3. Technical support scope – client’s perspective
In other words: what is reasonable to expect technical support to be helping with?
…in addition to dressing in tights at night time and fighting crime…
Things that technical support is able and willing to help with differ from provider to provider. They also depend on the type of hosting that is paid for. For example, a “real” Managed WordPress hosting provider will often help with website and plugin setup as well. While with “ordinary” shared hosting, especially if the price is low, it is not realistic to expect anything beyond making sure the server is functioning properly.
If you need a lot of more extensive support (often referred to as “hand holding”), it is best to check hosting provider’s TOS (Terms Of Service) and/or ask the pre-sales before signing up for a web hosting service.
It is in human nature to like and be willing to help, so technical support might often go beyond their “job description” to help, especially if you are patient, ask nicely and don’t abuse their good will.
Now I’ll list some typical technical support scenarios and my experience with those, as a hosting provider’s client:
3.1. Customer computer problems
If this turns out to be the problem source, there is no reason for the provider to fix it. If tech. support goes out of their way to help with this, I think it’s good to explain that it is beyond what the customers are paying for and should be expecting – it is practically a favour, in good will, not the provider’s duty. Even then, not all the people will be reasonable, of course.
3.2. Asking “a stupid question”
I feel like an idiot when / if I ask something that is covered in provider’s knowledge base, or at least “Googleable”. I do my best to make it a very rare exception, but it has happened.
Most providers help with that, sometimes posting a link from their own knowledge base (probably resisting the urge to write: “Would you also like us to type that into your keyboard remotely, sir?” 🙂 ) .
3.3. Some problem with the server – on provider’s end
This is a clear case of a provider’s technical support service scope. I do my best to state clearly what I did, in which order, how, what I tried etc – putting my speculations on the problem cause at the end of the ticket, just in (not very likely) case that too might help the tech. support.
Many providers are not easy to state it is a problem on their end (could be some legal thing, don’t know), even when it is and they fix it. More likely you get a reply: “it’s working now”, than: “we fixed that problem on our end”. But this is not important to me – as long as it gets fixed and doesn’t occur too often.
Some providers explain exactly what the problem was and how it was fixed – I value such replies since they help me understand and figure things out on my own in the future.
Had a few situations with short, but relatively frequent service interruptions: with tech. support asking me to check various stuff with each ticket, without being able to solve the problems permanently for some time. Then, after a month, or so, I would get moved to another server and then have no problems again – with an explanation that the “old” server was “problematic”.
These kinds of malfunctions that happen for a short time, then go away “on their own”, are often hard to pinpoint in my experience. By the time anyone, including me, gets to look into it – the problem’s gone, all works fine. Not sure what scope of log information is available at provider’s end, but since I’ve had these with two separate providers at different times, and they’ve both been solid after server switch and very prompt to fix any other (“normal”) problems, I suppose it is difficult to pinpoint.
3.4. Third party software related problems – “Catch 22”
Here’s my experience of what I’d call “Catch 22 deadlock”: 🙂
A digression:
Catch 22 book’s plot takes place during the 2nd World War, talking about bomber-plane pilots sent on basically suicide missions, and the catch boils down to this:
Doc, I must be crazy to accept these suicide missions. Can I plead insanity and get released?
– Sure, but it won’t work.
There’s some catch?
– “Sure there’s a catch,” Doc Daneeka replied. “Catch-22. Anyone who wants to get out of combat duty isn’t really crazy.”
BackWPup plugin wasn’t working properly. It’s worked with old hosting provider, but not with the new one. Same website, same setup, had double checked everything.
Asked provider’s technical support whether the plugin is blocked in any way.
Tech. support tried all sorts of stuff, but couldn’t get it to work, then gave up and told me to see with the plugin creator (which is sensible, I was pleasantly surprised they had bothered with it at all in the first place, after answering they are not blocking the plugin, nor any of the functions it uses).
So I contacted the plugin creator to see if they can figure it out. Provided all the relevant / required info.
Nothing helped. They told me to see with the hosting provider (Catch 22 🙂 ).
After a while, I got an idea: cPanel account I had created for the website was limited to 2 GB of storage (website was under 500 MB “large”). I increased that to 5 GB and tried again. That did the trick. For those interested: details on the BackWPup problem I had.
None of us involved had thought of trying that. Even though it’s perfectly sensible and reasonable: plugin uses extra space to pack and backup stuff, before uploading it to a given location.
Strictly speaking: this wasn’t provider’s problem, nor the plugin creator’s. Their products had worked as intended. But that didn’t help me, didn’t work for me. 🙂
Of course, one can’t expect hosting provider’s tech support to know every little “catch” with each software, or software combination.
Plugin creator: well, perhaps they should have thought of that – but again, they can’t be expected to know the exact hosting setup.
In any way, after having solved the problem on my own, I gave the return info to both the plugin creator and the hosting provider – in case anyone else gets a similar problem.
Obviously, since it was my problem, I had spent the time and effort needed to fix this. But didn’t have a “routine” solution straight away. Anyone who’s able to fix stuff like this could be considered top class tech. support (at least in my opinion) – on either hosting provider, or plugin creator’s end.
Solving things like that is not something to be expected, even though I’m sure there are lots of people with similar situations – practically left on their own (perhaps “Managed WordPress hosting” is good for such problems that are WP related, at least). I’m not blaming anyone here for this – it is how it is, don’t expect people to spend hours with every setup/software, without getting adequately paid. But I suppose things like this are the hardest to explain to customers and I’m also sure most customers are not delighted to get: “all’s fine on our end, see with the software company” – especially if they get a similar reply from the software company, directing them to the hosting provider.
Stuff like this can’t really be fixed. Tech. support people who know most of such (and similar, perhaps more frequently faced “catches”) should be kept at the company, respected and cared for, since they are the best long term marketing a company can get: good quality service and support – being advertised by word of mouth of happy customers.
On that note, from my experience: Veerotech technical support is very close to this ideal. MDDHosting has the owner answering some tickets, in similar fashion, trying to make things work – which shows a hands on approach in making sure all is fine. Gnu Host should also be noted – also with the owner themselves dealing with tricky stuff.
All the three noted companies have offered support beyond what I’d expect for the money paid – yet still, with some tricky problems as noted in this chapter, you are sometimes left to your own devices (unless you want to pay someone to spend days figuring stuff out).
Update: for another Catch 22 example – see this on Hosting server and website problems page.
4. Conclusion
Even the best technical support has their limits – sometimes one must hire an expert (or be an expert themselves) to fix a tricky problem. Still, for most stuff: if you provide good information, have patience and don’t have any unreasonable expectations, these people can do wonders – often far beyond their job description.