As I’ve mentioned before, my day-to-day customer-facing work right now is in Woo Happiness. While both Woo Happiness and WordPress.com Happiness are part of Automattic Happiness, they are incredibly different.

I’ll pause here and explain a little bit. WordPress.com is the freely available blog and website platform; you can make a blog or website for free, or you can pay for plans to get access to more fun stuff. The pros of WordPress.com are that you can get up and running really quickly – you don’t have to worry about waiting for a domain to propagate, to set up a server, to purchase hosting, to configure security, to worry about backups, nor do you need to do one lick of coding. Because we host every WordPress.com site, we have specific limitations in place – like limited plugins (or, widgets), themes must be chosen from our internal repository (not all WordPress.org themes work on WordPress.com), and specific code isn’t even allowed. For many people, these aren’t an issue at all – they don’t ever bump into one of those limitations. But other people want something a bit different, and that’s where a WordPress.org set up is a better fit. One example of someone who would be better served on WordPress.org is someone who wants to set up a ecommerce store. Enter WooCommerce – a plugin for WordPress.org that is incredibly flexible. With 300+ extensions (that is, bits of code you can enable on your site to work with the WooCommerce plugin to add functionality), it can do pretty much anything you would ever want an ecommerce store to do. Woo Happiness helps customers who have WordPress.org sites and have purchased WooCommerce extensions and need help.

On WordPress.com, we are the host. We don’t have to worry about server set up, we don’t have to wonder how the customer is securing their site, they are always running the same version of WordPress.com, we have access to their dashboard without them having to make us an admin – it is all very streamlined. But with WooCommerce support, the customer can have almost any host – and some of them are not very good for hosting WordPress and WooCommerce, which adds additional wrenches – the customer may or may not have site security, they may be running a wildly out-of-date version of PHP and mySQL, they may be running a wildly out-of-date version of WordPress and WooCommerce! They can have any number of plugins – which vary from 4 or 5 to 90+, they can have any theme – some of which haven’t been fully tested with WooCommerce, and accidentally omit critical elements (like a “purchase” button).

The way we manage supporting these customers is by working with specific plugin developers for WooCommerce extensions and testing the extensions ourselves on test sites. When we find a bug or cannot progress any further with a test site, we talk with the developer – sometimes that is someone at Automattic, and sometimes it’s a third-party-developer. We file bug reports in Github when we uncover bugs, and we keep the customer in the loop throughout.

So what might a typical day look like? I’m going to just focus on this specific customer-facing support, since I’ve run through an average day already, and it involves a lot of other things. We use ZenDesk in Woo, which is a helpdesk with a lot of features. It took me awhile to get up to speed after using WordPress.com’s very old installation of Kayako for so long! There are a few different queues, that are divided up into different umbrella subjects- such as Payment Gateways (tickets that address the various payment gateways, like PayPal, Stripe, Square, and more), Shipping (all the shipping-related extensions), Core, and more. My team focuses on the Payment queue, but more extensions than strictly payment gateways come through our queue, so we have a few different areas we cover.

I’m still a novice at Woo support, because it helps a lot to have a strong understanding of various hosts, WordPress.org set up (specifically what can go wrong with both), be comfortable with FTPing into users servers to check files, and dig into debug logs. These are all things I have a passing acquaintance with, and I’m lucky to get a chance to grow more here – but everyone else on the team is far ahead of me! Consequently, I ask for a lot of help. Luckily, everyone on the team is very generous with their time, and I’ve learned a lot from them.

So, I open a ticket, and if I’m very lucky, it’s about an extension that I’m already familiar with – like the Min/Max Quantities plugin, or the Measurement Price Calculator (notice that neither of these are payment gateways!). There are a small handful of product extensions that I have gained something I can call mastery in (but is really just a basic familiarity with the docs and the plugin settings). I read the customer’s message to us, and what they ask and the ticket history determines what I do next. If it’s a very complex ticket that has been going on for some time, I write an internal note with what the issue is right now – a customer’s need can grow and change throughout their conversation with us, so their very first message may be about something completely different, and their most recent message can be something like “didn’t work. now what?” So having an up-to-date note that explains the current situation only is incredibly helpful for me – particularly because tickets take me awhile to plough through, so I will be configuring my test site, come back and wonder “ok, so what else did they need here?” Writing the note also helps me clarify in my own mind what I should be doing.

Sometimes, the customer is asking for clarification on what an extension can or cannot do. In those cases, I read the documentation, and about a third of the time, the answer is there. Simple! I can answer and direct the customer to the documentation as well. The other 2/3 of the time, I need to set up the plugin and fiddle with it to see if I can get it to do what they’re asking. More often than not, I can. If I can’t figure it out, I ask my team or the wider Woo Happiness team if it is or isn’t possible.

Other times, they have a problem with an extension – it’s either not working as they think it should, or there’s an error message, or it’s not working at all. In those cases, I set up my test site to match the user’s as best I can, and see if I get the same problem. Sometimes, they have a lot of plugins, and in that case, we recommend that they disable all their plugins but WooCommerce and the extension and switch to a standard theme, like Twenty Seventeen. That’s because we know that the plugins we support will work in that environment. Sometimes that means they should set up a staging site, so they can fiddle with their theme and plugins, and not have their live site suddenly look different to customers. Other times, they’re just getting set up, and disabling plugins isn’t a big deal. Usually, there’s a conflict between the plugins or between the plugin and theme. Other times, something else is afoot. It could be that they need to upgrade their PHP or mySQL (or need to ask their host to do so), or it could be that their host installs a plugin that quietly runs in the background and breaks everything (it happens!). When we find a genuine bug, we report that in Github in the appropriate repo, and let the user know that we will take a closer look. Occasionally, the issue isn’t exactly a bug, but something is wrong, and we are out of troubleshooting options. If the extension is managed by a third-party-developer, we can ping them in the ticket (perk of ZenDesk!) and leave a detailed note for them to take a look. They will reply back in a note with a solution, or suggestions for next steps. There are also some devs we can ping in Slack to get further clarification or just get confirmation on something before replying to a user.

If that all sounds very confusing and involved and exhausing, it’s because it is! It’s all those things! But it’s also deeply satisfying. You might be asking yourself “wouldn’t batching those tickets be easier?” (Batching is when you assign yourself all of one kind of ticket, rather than taking the tickets from the oldest->newest strictly.) We have SLAs (service level agreements) for our extensions, which means we promise to reply to our customers within X amount of time. Because of the volume of tickets we receive, our best strategy is to consistently reply from oldest to newest. However! There are a few exceptions. With one extension in particular, we’ve been experimenting in having week-long rotations dealing with those tickets (one person signs up for the week and takes all those tickets, plus whatever other tickets they can manage). It’s been working well, since the extension is so complex it is far more efficient to batch in that case. Other times, a subject-matter-expert arises, when someone has dug into a particular plugin in-depth, and they are a great resource for getting quick confirmation on how that plugin works. Ticket replies may be relatively quick – passing along information from a dev, for example – or they may be long and difficult to work through. Our Slack channel might be casual chatter, targeted questions about a specific plugin, or even answering questions from other folks in Woo about the plugins we care for.

Digging into a tricky ticket, setting up an extension to function flawlessly, and explaining it in detail to a user is really cool – these are sites that people are using to generate income and support themselves, their families, their employees, or sometimes just something they’re doing as a hobby. Sometimes, they are in the business of setting up sites for clients, and getting to help that one person who will then turn and use that knowledge with all their clients is really cool, too. I’ve said it before, but the coolest thing about WordPress is that users manage to use it for so many different things – I constantly come across sites I never would have dreamed up. Working with WooCommerce sites affords me the chance to see a whole new dimension of this, and it’s incredibly exciting work.