Blog

support (2)

The art of asking a support question that gets answers

You've updated WordPress to the latest version, or you just hit that update button thinking everything will be fine. Then you stare at the front end of your site in disbelief as everything is now out of wack, and your deadline is less than three days away. What do you do in situations like this? Ask a support question, search for answers, debug or just restore a backup?

If you ask a support question, with the site down and a deadline looming you may be getting angsty at not receiving a solution in the first reply or delays in tickets that take 24 hours or more to respond to.

In this guide we're going to take a look at getting support and making sure you ask the questions that get answers.

Not sure what Tickera is? Go here to find out!

 

Let Me Google That For You

Many issues can be solved with a quick search of Google. What if your Google Fu isn't on point though? Don't worry the secret of anyone good at finding stuff you can't on Google is specificity, or should that be lack thereof. If you type a query into Google and never get what you need, you may be too specific. Try just using keywords rather than structuring the query like a question.

 

Often Googling an issue can get you the fix to the issues you're having, or at least clue you up on what could be happening.

 

It might be a known issue that you can stumble across in either the official support forum for the plugin/theme you're using or a more global issue like the recent text widget changes in WordPress 4.8. Whatever the issue though, searching can save you countless hours waiting for that support response and could stop you needing to open a ticket entirely.

 

Read the Damn Manual

Ok, everyone knows the first thing you do with anything. Be it software, electronics or your new Ikea Desk is throw the manual to one side and just try and figure it out. While it's a perfectly valid way to do things. It's not the smartest idea when it comes to advanced and complicated matters like WordPress plugins and themes.

 

Any decent WordPress Plugin or Theme will have a manual or a knowledge base.

 

One of the first ports of call, if you have an issue or question, is to check out said manual or knowledge base. Often developers have thought of the most common questions long in advanced and have a range of useful code snippets, answers and more just waiting to be read. So before you jump into opening a support ticket always read the damn manual.

 

To Update Or Not To Update?

Ever asked a support question to get the answer "Please update to the latest versions and we'll take a look" annoying isn't it? Especially when sometimes you know full well it's not version specific. However, support agents are often trained to make sure sites are running the latest versions, and in most cases, many developers won't even support older versions of their software as later versions will have bug fixes and new features.

This means that before writing in that email to support or starting a topic on an official support forum. Take a backup and then proceed to update your plugins and themes to the latest versions along with WordPress core. Still, have the issue? Don't worry at least now you've saved yourself at least one email in the support chain.

 

Test Before Asking

Yep, conflict testing. The thing everyone hates to do, but it's always required when trying to debug an issue with any WordPress. While the old versions of a plugin and theme may have worked together, once one is updated it doesn't mean it'll play nice or that it won't suddenly have a conflict with another plugin/theme on your site.

What do you do though if you have 20, 30, 40, plugins or more? Deactivating one by one is a complete pain.

Let's say you've updated your theme and nothing works. Top tip; rename the plugins folder to anything you want such as pluginsOFF. Then create a new plugins folder and see if your site loads. By renaming the folder, you'll be deactivating the plugins without technically deactivating them. As long as you don't visit your wp-admin, the plugins won't deactivate in the database and won't run any deactivation scripts. One way though to help in debugging and to run conflict testing is to use AUS (this abbreviation is made up and in no way stands for Australia). Rather I call it Always Use Staging. Yes, the humble staging site. Saviour of many a site breakage. Some of the best managed hosting companies like WPEngine, offer one-click staging, push to live, and one click restores. Allowing you to test updates in confidence you aren't about to break your main site.

 

Just asking the question

The time has come. You've sworn at your PC, thrown your keyboard out the window. And you are still no closer even after trying everything outlined above. Have no fear that's where the silent heroes in capes come in and save the day. Or as you may know them - the support agent.

Don't ask something stupid like "Hey, My site doesn't work since the last update, what should I do?" This is extremely non-specific. All the support agent can gleam from this information is that after the last update your site doesn't work. But what update. For their plugin, theme, WordPress core? What steps have you already taken to try and resolve it? Do you see any errors? What's the URL of the site in question?

As you can see asking a question such as the above, can get you involved in a long chain of back and forth emails that aren't fun for you or the support agent. Ultimately they want to assist and need as much information as possible, and you want a solution as quick as possible.

 

Asking the question the right way

You should structure your ticket/email something like this:

"Hey, I've recently updated your plugin to version 4.2.5 on my site (example.com), and I'm getting an error error

Parse Error: unexpected T_PAAMAYIM_NEKUDOTAYIM

I've tried deactivating all other plugins and switching to the default Twenty Seventeen theme but still have the same issue.

Happy to provide login details if required, but it appears this could be a bug in the plugin?

Thanks!"
Notice how much extra information we provided there? We've given the website URL, the error that's showing and also what we've done to try and resolve it. You could include logins in the original ticket. But always make sure you don't provide logins on a public forum, and many companies usually prefer to try and resolve issues without needing logins even though in some cases login details may need to be requested to accurately debug what's happening.

Did you also notice the tone though? We were polite, said thanks and didn't write in all CAPS LIKE THIS or come across aggressive. At the end of the day being rude won't get you a solution quicker and will just cause bad feeling all round. The support agent is trying to do their job and treating people as you'd like to be treated is the way forward. After all, you wouldn't want someone screaming at you in an email trying and swearing would you?

 

Try and make your question as specific as possible. Asking seven questions in one ticket can get confusing fast, especially if one support agent isn't assigned and multiple people are replying.

 

Support teams can quickly get lost in trying to deal with so many questions in a single ticket. Lastly be patient. Companies can be dealing with hundreds if not thousands of tickets on a weekly basis. While your ticket may be urgent. Many people's tickets are urgent and important to them. Support teams always deal with tickets in order and bumping your ticket in many tickets can actually push it back in the queue.

 

In summary, be specific, be polite, be patient

 

Conclusion

Waiting for a support response can seem like waiting for paint to dry. But know that support teams work hard often round the clock to help and assist users with issues. Have you ever received a poor support response even after trying to be as specific as possible? Maybe you want to sing the praises of a support team you've dealt with recently. Let us know in the comments below.

Jack Kitterhing is a WordPress developer from England. His love of WordPress began at age 11 when he set up his first blog. After a stint as WPMU DEV's Project and Quality Assurance Manager, he's now a Software Developer at Themeco.
Leave a Reply

Your email address will not be published. Required fields are marked *