Loading ...

Transparency Report #14 – New Definition of "Headache"

Transparency Report #14 – New Definition of "Headache" image

Welcome to the 14th edition of the transparency report (for March 2016)! In this series, I share everything going on behind the scenes here at CodeinWP and Themeisle. Each month, I do my very best to focus on the most important and interesting goings-on, while also sharing my opinions and advice on related topics. To see the previous reports, click here.

New definition of …


To manage the operations of a WordPress theme store.

Okay okay … I’m not being reasonable, I admit.

I’m exaggerating, but the message I want to convey here is that this WordPress-theme-store thing can be really really tough at times.

Namely, the main challenges we’ve been struggling with for a couple of months now (still are, but things are getting better) are our project management and support processes.

And it’s not that we’ve failed to get things done, far from it, but there’s just been too much stuff happening in too many places / online dashboards.

For example, when it comes to project management, we’ve been handling most of it in Redbooth … and in Slack … and in GitHub … all at the same time and simultaneously. Where by simultaneously, I mean that the same task/project had ongoing conversations on either/all of these platforms.

Of course, each such conversation did focus on a slightly different aspect of the matter, but this made everything very difficult to manage nonetheless. Some problems:

  • tasks getting duplicated and people not knowing what to do or where to respond to queries,
  • deadlines being missed or tasks being forgotten completely,
  • a lot of additional meta work – handling things like describing the work in progress in multiple places, rather than focusing on the work itself.

So obviously, a situation like that isn’t perfect…

In its core, having some place to manage your projects is essential for a business, any business. But having too many such places leads to a lot of confusion and creates only an illusion of having things under control.

I guess trying to use one too many project management tools is a form of procrastination. I mean, you think that you’re doing work, but it’s far from it.

Using one too many project management tools is just procrastination Click To Tweet

Okay, so how to fight this urge to over-manage, and instead focus on the things that really matter? Here’s what we’re doing:

First, we’re moving everything development-related over to GitHub permanently, with the help of the ZenHub extension.


Secondly, even though we love Slack for its familiar IRC-like old-school nature combined with the modern, our communication process is dependent on it too much for my liking. The discussions are way too fragmented, and if someone isn’t there from the start, it’s hard to get up to speed and join in later.

That’s why we’ve set up some regular meetings to tackle projects more hands on. Right now, we’re experimenting with our:

  • Global meeting (recent achievements, business overview, product strategy, administrative stuff, current goings-on, and etc.)
  • Support meeting (discussing current goals, challenges)
  • Dev-talks meeting (discussing our development goals, projects, and tasks)

In the end, looking at everything that’s been going on in our house, my advice is this (if you’re struggling with similar issues):

  • Minimize your management tools to the bare minimum. Remember that this sort of meta work is only meant to make your actual work better and more effective. You shouldn’t ever over-manage things just for the sake of it.
  • Always bet on person-to-person communication (see #3 here). Slack is great, but just not for everything all the time. If your gut is telling you that you should talk with someone (or a group of people) in person, it’s probably right.

Documenting your support process = making your support better

Just like Uncle Ben said, “With great power comes great responsibility.” … In the WordPress theme market, it’s more like:

With great downloads come great support tickets. Click To Tweet

When you’re just starting out, support isn’t that big of a challenge, and you can usually handle all the requests in a helpful and timely manner. Also, you’re getting a lot of valuable feedback that way, and a chance to improve your products at their early stages.

But when things start getting off the ground more rapidly, solving every new unique and individual issue becomes difficult. You quickly learn how non-standard people’s server setups can be, and what sort of weird bugs can come up.

Add hiring new people to the mix, and you’re not only dealing with the issues that your customers are having, but also with the challenges related to managing your support staff and making sure that everybody’s happy and knows what to do when faced with a challenge.

So to facilitate the onboarding process for our Happiness Engineers, and to ensure a general standard in communicating with our customers, we’ve created a doc detailing our support guidelines.

It’s a work in progress, but it’s the first step to documenting the good practices and the overall process of helping a customer out in an effective and friendly manner.

Here’s a screenshot of the TOC:

support guidelines TOCsupport guidelines TOC

(UPDATE. And here’s a link to the whole doc (click). Just remember it’s a work in progress. Also, any tips on how we can make it better?)

I’m saying all this just to motivate you to create a similar document for your business. For us, it’s already proving to be a valuable asset, and especially in situations where a member of the team doesn’t know what to do in a certain support scenario – they can just go to the document quickly and get their answer.

And most importantly, whenever someone comes up with a better way of dealing with something, we can update the doc and make it the new standard.

But wait, there’s actually more happening in the support department of our business…

The second thing we’re doing is optimizing the way we use HelpScout. We’ve been setting up Automated Workflows (31 in total so far), so that specific types of support messages come through the door straight to predefined folders. Example:

HelpScout workflowHelpScout workflow

This kind of setup can help a lot if you’re getting many tickets every day and spending quite a while just grouping them together somehow. Also, this allows you to delegate specific categories of issues to specific people on your team. Even if that team is very small right now, it is still a great investment for the future.

The next thing we’re working to improve is handling all the different support channels that are currently in use. We have:

  • our support forums,
  • our contact form (which leads to HelpScout),
  • the official forum at WordPress.org (for free plugins and themes).

Dealing with all three at the same time requires a lot of resources. So we’re doing a couple of things to make the most out of our efforts:

  • Better segmentation of incoming messages (like I said; the HelpScout Workflows). This is done in our contact form itself. So based on what the user selects, their message gets redirected to a specific workflow.

contact formcontact form

  • We’re looking to get feedback from our users, so we’re asking them for reviews after we’ve helped them with an issue. This generated about 17 five-star ratings for Zerif Lite on WordPress.org in just one month. (There’s a tip for you!)

reply ask for feedbackreply ask for feedback

  • Building a database of solutions for the most common issues, and expanding our docs.

That last thing is perhaps the most important. Here’s why:

Like with most software tools, you rarely stumble upon a truly new issue that someone might have with your product. Usually, you keep seeing some versions of the same things over and over. Of course, if it’s an obvious bug, go and fix it already! But if it’s more complicated than that, you can (and should) prepare a detailed guide that your users can follow to solve the issue for themselves. And that’s what we’re doing with the docs.

So the new policy regarding the docs is this:

  • 3 new doc entries per week … per person.
  • There’s a new Docs Pipeline document – to oversee the production of new docs.
  • We’re setting up some templates for the docs. That way, we can standardize every article in the docs, and also make creating them easier for our support team.
  • We’re updating old doc entries, especially the ones that are the most popular.
  • We’ve also made our forums public (not just for logged in users), and added a support tips box to the forum pages – helpful when someone visits the forums for the first time:

forums tipsforums tips

Oh, and by the way, we’re looking for a Happiness Engineer to join our support team! For those interested, check the Workable.com listing for this position. Some main requirements:

  • a genuine concern to help people(!),
  • working experience in a technical support department,
  • excellent knowledge of WordPress, PHP, HTML5 and CSS,
  • happy to work in a distributed team,
  • great at organizing their work,
  • excellent English writing and communication skills.

Do you know of anyone like this? Help us spread the news via Twitter:

Great job opportunity — #WordPress Happiness Engineer Click To Tweet

Looking for writers!

We’re planning to take our content game to the next level in the next couple of months, so we’re now actively looking for regular writers as well as occasional contributors.

If you want to help us out, or know someone else who could potentially be a great fit, check out either of these pages:

New logos and brand identity

Themeisle was always meant to be a fun place.

After all, not every theme store calls their customers “pirates” and not every CEO is the “King ‘o Themes.” 😉

But perhaps it’s time to change our identity a bit. But I don’t mean anything too brutal. Being fun is still a quality that we want to convey.

That being said, we do need a new logo.

The main problem with the old Themeisle logo is that it doesn’t separate the two words well enough (theme and isle). This makes it difficult to read and memorize, especially for first-time visitors.

themeisle logothemeisle logo

So separating the words in some visual way was the main goal for the redesign. We tried a number of things here … using different letter sizes, title case, mixing thin/bold fonts, even using two rows instead of one.

Some alternatives:

themeisle logo optionsthemeisle logo options

In the end, though, we’ve decided to go with this version:

themeisle new logothemeisle new logo

What do you think?

A shout-out to Catalin Vasile, who designed the logo!

Revenue breakdown (Mar 1st – Apr 1st)

Here are the numbers for March (from our in-house tracking system):


(Again, a moderate 4.2% increase compared to 30 days ago.)

So that pretty much sums up March.

Or … wait … almost forgot:

Speaking at WordCamp!

A while ago, I mentioned my personal goal to speak at least once on a WordCamp stage by the end of the year.

Well, it’s happening!

WordCamp Porto is the place, and as you look at the calendar, it’s only about a month away!

wc portowc porto

To be perfectly transparent with you, I didn’t do much to further my speaking goal until now. So my reasoning here was that the best way to accelerate things is to just take the leap and apply to speak.

If the organizers approved, I would be super-motivated to work on making my talk as awesome as it can be.

And … they did approve, so I’m both excited and terrified … in a good way, though.

Okay, that’s it for now. As always, thanks for reading and for supporting CodeinWP! Stay updated and get new reports delivered to you by subscribing here:

Subscribe Now ImageSubscribe Now Image

All edits and witty rewrites by Karol K.

Was this topic helpful?0% of users found this helpful
  • Tags:
  • Categories: