As many of you know, our team started to handle all plugin support from last year. This was an interesting change for us, as our team had previously been involved in second-tier support, with the WooCommerce team responding to incoming questions and working with our team as needed.

Just about a year has passed since this we fully transitioned support to our team. We’ve learned a lot about providing better customer service, and have built a team around support.

Why system status information is key

It hasn’t always been easy, as learning how to handle large changes in support volume is challenging — for example, we’ve had weeks with a 30% increase in our usual support volume for seemingly no reason, which makes sending timely responses much harder for our team.

These “ebbs and flows” in new conversation volume aren’t predictable for us yet, and one of our focuses this year has been learning how to streamline support so we can handle these changes better and provide more timely support.

One of the ways we’ve tried to streamline support processes is by building internal tools that help our team diagnose problems. When you submit a support conversation in your WooCommerce account, you’ll notice that you’re asked to provide a system status report. The information in this report is really valuable for our team, as it lets us identify potential configuration issues or conflicts.

When we get a system status report, our internal helper looks for important information in that report, and highlights it for our team in a note (we use Help Scout for support, which supports internal notes). We’ve affectionately dubbed this helper SkyBot.

SkyBot: internal note

This gives our team hints as to potential problems that can be investigated first.

SkyBot also adds other information to the sidebar in Help Scout so it’s easy to reference. Our team can more quickly see if an extension is out of date, or if there are environment issues that should be highlighted (such as outdated version of PHP, cURL, or WooCommerce). Between SkyBot’s CRM widget and initial notes, we’re often able to cut out several steps and questions in each support conversation.

SkyBot: CRM

However, while system information is really helpful, it’s not always reliable to try to read it from a system status report that’s copied and pasted into an email. As a result, sometimes information is outdated or unrecognized when our support team works with a merchant to resolve issues, which can cause frustration on both sides.

What we can do with accurate information

When we do have accurate information, our support team is also able to quickly recognize trends given how many stores they help every day: there have been hundreds of support conversations solved this way already. If we see an issue that’s strange or new, we talk about it in Slack, and add it to our internal field guide (most of which is private). Our entire team can therefore assess issues quickly and learn as a group, helping us recognize support patterns and deliver faster resolutions.

When we combine accurate system status information with patterns we’ve recognized across thousands of support conversations, we can do some really cool things. Usually this results in improvements to our extensions, but product changes aren’t always able to resolve these problems.

So, one of our hackathon projects at SkyTrip this year was to figure out a way to ensure system status information is always accurate, then pair it with the knowledge our team has gained from working with thousands of stores. Max, Chase, and Ian put together a proof of concept to show that SkyBot could become public-facing to fetch accurate site details, then compare it to rules outlined by our team to help diagnose problems (like our own Watson).

Since then, Jared has taken over the project, making SkyBot available to connect to your site, and run some automated diagnostics based on your support request and site system status.

SkyBot: authorization

Cool, huh? The goal behind these changes is to let you run SkyBot’s automated checks right away to diagnose common issues as fast as possible. I’ll turn it over to Jared to tell you more about how SkyBot’s new set of upgrades work. ????

Meet SkyBot

Like most software, SkyBot looks smart, but is a little dumb. With some training, though, we’re excited at what it can learn. 🙂

Right now, SkyBot works by taking a few steps:

  1. When you submit a help request via, you choose the extension you need help with. SkyBot remembers this information and correlates it to your support conversation number.
  2. In our support autoresponder, we ask you to connect to SkyBot. If you do, it asks for read-only REST API permissions to your site. This allows us to read your system status report programmatically.
  3. SkyBot reads the system status (which is more reliable than copying and pasting data), and, knowing which plugin you’re asking about along with other site information, makes some targeted troubleshooting suggestions. These suggestions have been fed to it by our support team from trends they’ve recognized, conflicts they’ve debugged, or problematic settings combinations.
  4. SkyBot also tags conversations in our help desk as “high priority” when a site is connected, as our team can move more quickly when they have the data they need to troubleshoot.

As our team uncovers issues or areas for improvement, we try to improve our products to counterbalance these questions or issues. However, SkyBot also helps to recognize common issues or questions that may not be solvable with plugin updates, and to share that knowledge in an automated way.

What can SkyBot do?

Right now, not a ton. 🙂 Our team needs to feed it new troubleshooting blueprints, like this:

If the support conversation is for WooCommerce Memberships, and the site default timezone is not UTC, share this information:
“Hmm, looks like your server’s default timezone is incorrect — it should be UTC. When a server does not use UTC as its default time, it can affect when members can access restricted content. If you see issues with members getting access at incorrect times, please ask your hosting company to reset your server’s timezone.

SkyBot also links to relevant troubleshooting in the plugin documentation, and asks to give our team the info they need if its diagnosis doesn’t work.

SkyBot: suggestions 1

If SkyBot has a list of multiple potential issues, it will list them all:

SkyBot: suggestions 2

Finally, it asks you to review the plugin docs and create an account for our team to troubleshoot. While this isn’t necessary in every case, it helps our team to see how a product, membership plan, or settings are configured so they can replicate issues on our test sites for the fastest troubleshooting. (Note that, for security reasons, the “Create account” link takes you back to your site to create a user account, we don’t create one programmatically.)

Thus far, SkyBot has already resolved some issues within minutes! ????️ Letting our support team share patterns they’ve recognized in a targeted way makes it easier for merchants to get fast help, and having a way to read site data at a glance has helped our team with faster debugging.

We’re looking forward to expand what SkyBot can do over time to help improve our support and share common solutions where they apply.

Published by

Beka Rice

Beka leads product direction for SkyVerge and technical documentation. She spends a lot of time on research and interviews, but likes to write so she has an excuse to spend more time jamming out to anything from The Clash to Lady Gaga.

Jared Burke

Jared is a PHP engineer at SkyVerge, focused on maintaining and building new features for our WooCommerce plugins. When he's not solving code puzzles, he solves real puzzles as a bonafide Rubik's cube master.


  1. I love the reward of getting tagged “high priority” in exchange for allowing API access. As a site owner I want to do all I can to make your job easier when you’re helping me.

    BTW, Is your Help Scout integration all custom or are you using one of the available extensions for that?

    • Great question, Doug — this had to be entirely custom for how we receive new conversations. When you submit a help request via, it gets sent to us via email. Rather than piping this right to Help Scout, we use a distinct email address for that inbox that sends the email to Mailgun first. Mailgun takes the email and sends a webhook with the email content to our Support Bot app for processing.

      This app is what handles the magic here:

      It reads the email webhook for key information like the plugin submitted, customer email address, and plugin subscription information (e.g., when the plugin subscription ends). It also tries to parse the submitted system status to see if it can pull out helpful information, like PHP or WooCommerce version (doesn’t always work great due to inconsistent formatting, which is why we ask to connect via API).
      Once the app has read the conversation, it creates the conversation in Help Scout via API with the message content, customer email, and tags the conversation based on the plugin it’s related to. It also adds an internal note with the active plugins on the site, and potential issues related to the plugin the customer asked about.
      The app saves the Help Scout conversation ID and the shop URL the conversation is related to in its database. This is how it generates the authentication URL to connect to a store. (Of course, saving as little information as possible for privacy, only what it needs to link a Help Scout conversations to a store. ????)
      If the store connects to support bot, then this is where it reads the store status via the API to offer suggestions and add more information to our CRM widget.

      So since we had a pretty custom workflow, we built the custom app + Help Scout widget to fit into this. With that said, there is a pre-built Help Scout widget for WooCommerce that can show some purchase information if you’re doing support for a WooCommerce store. We just couldn’t make use of it here because we can’t connect our Help Scout account to, so we needed something that could work solely from that initial support email.

Hmm, looks like this article is quite old! Its content may be outdated, so comments are now closed.