How to ask for WordPress plugin support (the right way)

Uncanny Owl recently passed a big milestone for our Help Desk: Ticket #10,000. We started using a Help Desk system in 2016, before we started selling plugins, and it’s perhaps our most valuable tool. It’s the first thing we check in the morning, the last thing we check at night, and using it ensures that the thousands of customers that depend on us stay happy.

After a few years of providing support to over 3,500 different people, we know all too well what makes a WordPress support ticket easy to resolve and what types of inquiries are going to drag on for some time. Everyone wants a quick fix to their question or problem, and while we as plugin vendors do our best, there’s a lot you can do as a plugin customer to make the process more efficient. In this article, we’ll outline the best ways for making sure that your problem is resolved quickly and accurately.

Be specific

Last Thursday I took a call from a plugin customer who wasn’t very happy with our product. Despite us having a 10 minute call about it, I still don’t know why he was unhappy. The best answer he could give me was that “nothing worked”. I tried to dig deeper, to find out what functionality he was using and even why he bought the plugin, but he could only tell me he bought it to make his site “better”. I know he was frustrated, but he couldn’t articulate specifically what he was expecting that the plugin wasn’t doing.

Receiving a ticket that tells us that a “plugin isn’t working” makes it difficult for us to help and means that we have to follow up asking for more details, which in turn delays resolution. Tell us what you’re expecting to happen that isn’t happening; let us know what you are experiencing now. If you see an error message, include the error message.

Be kind and stay calm

We know that you’re reaching out to us because you’re experiencing a problem that’s causing anxiety and asking us may be your last resort. We do our best to empathize with the situation and we approach tickets as if they were about our own site. When we receive a ticket that starts off with an introduction like, “Hey guys, love your plugins, but I’m running into an issue right now with XYZ and I’m hoping you can point me in the right direction”, it’s going to set the right tone for the conversation and put everyone at ease. We’re also going to stay focused on resolving the issue.

While it is (fortunately) very uncommon, taking the opposite approach slows things down and adds tension to the relationship. Early last week, a customer reached out to point out a small error in a line of code that we shipped out (that had negligible impact on functionality). It could have been a simple interaction: “Hi Uncanny Owl team, I noticed a small issue in this file on line 123, it should be ABC instead of XYZ, can you confirm the fix and include it in the next release?” That would have been fantastic, we would have investigated and confirmed it immediately, and the ticket would have been closed. Instead, the user led with, “Do you guys even test anything before you push updates?”—and then we’re automatically on the defensive. We then have to be more careful about planning our reply and approach to a resolution.

Provide a test case

Last week we had a ticket that effectively said, “Some of our users report that they can’t complete a course, please fix it ASAP.” I didn’t know what plugin they were using of ours, what was supposed to trigger course completion, etc. It took about 4 emails back and forth to put together enough detail to understand what users were doing and what was expected but didn’t happen.

Here’s an example of a great test case related to a real (and recent) issue with one of our plugins:

Hi, I’m using the Uncanny LearnDash Toolkit Pro plugin with the Autocomplete Lessons & Topics module turned on. I have autocompletion enabled globally, but for the first topic of a course I have it disabled at the topic level. When I visit the topic as a user, I’m able to click forward to the next topic and the first is marked as completed. It shouldn’t be marked complete because of the topic-level override. Any idea what I’m doing wrong? Here are some screenshots so you can validate my settings.

That is a fantastically helpful ticket to us because we know exactly what the customer is using, we know how things are configured, we know the steps they’re taking and we know the expected vs. actual result. This kind of example makes it really easy for us to validate the issue in our test environment to assess if there is a problem in our plugin or if it’s a unique behaviour to their site. Be very descriptive, outline the steps someone could take to reproduce the issue, and include additional details like screenshots whenever it’s appropriate.

Outline what you’ve done so far

Once again, the more we know the better. Using the ticket above as an example, it would absolutely help us to know if the user tested with different module settings or with the plugin disabled entirely to see if the results were different.

Let’s take an example with one of our plugins.  Perhaps the site admin wants LearnDash Group Leaders to see the admin bar, but for some reason it’s not showing up.  In our Hide Admin Bar Toolkit Module, they have the Group Leaders unchecked (so those users should see it).  This suggests another plugin is conflicting with the settings in the Toolkit.  Before reaching out to us, maybe the customer already disabled all plugins (except our Toolkit) and changed the theme temporarily to confirm the issue still happens. Knowing that would save everyone time, because that’s the very first thing we would suggest if we suspected a conflict.

That leads us to a related and very important recommendation.

Get a Staging site ready

With elearning sites in particular, testing updates and issues on a site that’s independent of your live site is critically important. Having a Staging site available for that purpose is a must, and if it can be used for resolving issues as well, all the better.

Sometimes we simply can’t trace a plugin issue through descriptions and screenshots alone. We do need access to see what’s going on and to test things. I can absolutely confirm that we do not want access to your site unless there’s no alternative, and if we need it, we don’t want to test things on your live site. If an issue seems like it’s going to need troubleshooting directly in your environment, it’s going to be easier and safer for everyone if that testing can be done on a clone of the live site rather than the real site. If you suspect the plugin vendor will need to see what’s going on in the environment or the conversation is heading in that direction, get a Staging site up and running.

Do some initial troubleshooting

If you’re new to WordPress this guidance is going to be hard to action, but as you get more experienced you’ll start to understand what’s likely to be causing certain errors and where to look to trace them.

If you see a white screen, a page in /wp-admin/ only partially loads, or you actually see a “500” error message, there’s likely a fatal PHP error on the site. Typically there’s going to be an associated message in the web server error log, so you’ll want to check there first for a “Fatal Error” and pass that on to the plugin developer. The WordPress debug tool can also provide really important clues about system-level errors.

If something on a site just looks wrong or unlike screenshots on a plugin developer’s website, or interactive elements on your site aren’t working properly, it’s likely a javascript or CSS conflict. Check the browser console (View > Developer > JavaScript Console in Chrome) for more information, and if you find any errors, they will be immensely helpful to the plugin developer.

Include one issue per ticket only

This one is really important when you want a quick resolution for your ticket. Our team has multiple developers, each of whom has different areas of expertise. We have 3 customer-facing staff handling support tickets and 4 developers behind the scenes providing assistance. Tickets that include several issues slow things down by an order of magnitude, because now we have to split tickets up behind the scenes, assign them to different developers and staff, then wait for an update on all of them before we can reply to the customer. After all, we don’t want to send pieces of updates and end up in situations where only part of the ticket ends up getting answered.

A few weeks ago we had a customer submit a 3-page PDF file outlining 5 completely unrelated issues they were having. None of the 5 had a simple answer, all required testing and validation, and we had to address all of them before we could properly reply (beyond sending an initial confirmation warning the user that it would take longer to investigate all 5 questions). Turnaround time would have been improved for the customer, and things would have been more efficient for us, to have received 5 separate tickets instead.

We want to help

When something goes wrong with a WordPress plugin, it’s absolutely a scary moment and you just want it fixed as quickly as possible. We as plugin developers want the same. By helping us to understand the problem, making it easy for us to test it ourselves and by giving us all relevant information, your tickets will be turned around faster and your issues resolved more quickly.

Give the tips above a try the next time you need to send in a support ticket and let us know in the comments if they helped!