Before I start, I should highlight that I’m currently providing support for a free plugin. So I suspect my experience differs slightly from supporting paying customers.

Most pertinently, everyone I’ve interacted with has been uniformly polite and appreciative. I think this can be largely attributed to the fact that people just don’t expect much or any support from free plugins. When the bar is low, it’s easy for me to surpass it.

Having said that, I believe there is still a lot of overlap. And with that, let’s dive in!

How should I set up support?

There are a great many ways to set up a customer support system. But I don’t have visibility into anyone else’s aside from my own.

So let’s begin there…

How I do it:

I use Gist for my support software. They are very reasonably priced and give me a number of features including: live chat, support desk, email, and a knowledge base. The software is great and their support team is, unsurprisingly, amazing.

I also connected both Twitter and Facebook DMs to Gist. This means that any time a user DMs me, Gist picks it up and sends me an email notification.

From there, I can choose to reply that email directly, or go into Gist to respond. Either way, the user gets a reply natively — on the same social media platform they first reached out on.

Simple for them, and simple for me.

We also added ways for users to get in touch with us inside the plugin itself. This makes it easy for a user to let us know when they have issues or feature requests.

I believe in giving a user as many opportunities and platforms to get in touch with you. The easier you make it for them to reach out, the more likely they’ll do so. For me, this is a good thing as it means more feedback, and the ability to make the plugin even better.

On the whole, I believe my set up is fairly simple. I’d love to scale it up over time, but I think it’s sufficient for now.

If you have suggestions for how I can improve it, I’d love to hear from you.

How can I manage the stress and emotions that come with providing customer support?

Customer support can be stressful. Here are some common emotions that go through my mind while I’m doing support:

Guilt: the thing we’ve built has broken! A user was relying on us, and we’ve let them down!

Insecurity: Arggh! Have we built a shitty, unreliable product?!

Panic: Oh no! We’ve caused an urgent problem that needs to be fixed ASAP or someone’s newsletter isn’t going to go out this week!

Under appreciated: because someone has failed to say thank you or worse!

Sometimes, it’s all of the above.

Now multiply this by the total number of support tickets.

And you can see how support can be an emotional minefield.

What I’ve been doing:

I think the best one can do is decide ahead of time where to draw the line, and what your principles are.

Then constantly communicate them both internally and externally.

Finally, stick to your principles and be at peace with the consequences.

Here’s my first attempt at articulating my principles and guidelines:

I look at incoming support tickets daily, and try to give them a first response in under 6 hours.

However, I don’t feel bad if I send my first reply in 24 hours.

I’m not rigid about when I do support. If I happen to receive an email that catches me when I’m not doing anything, I’ll happily respond to it immediately. But if I’m busy, responding later is fine too.

I try to answer all tickets fully, rather than rush to close them… Even if this means that a conversation might stretch days. For example, if a Loom video is the best way to help a user but I can’t get to it right away, I’m not afraid to tell them to expect a video in a couple of days time.

How should I talk to users?

I really enjoyed Andrew Spittle’s thoughts on providing certainty for a user and avoiding the word “easy”. And that’s definitely guided my own approach. Here’s a snippet of what he has to say about certainty:

One of the best things we can do in support is provide people with certainty. It gives the people we help confidence to reach their goal and increases the likelihood they’ll be successful using our service. To do this well we must pay particular attention to our language, as it’s all too easy for uncertainty to slip in. And uncertainty is not why people turn to support.

People contact support only after something’s gone wrong. They’re stuck, they fear they broke something, or they’re stressed in our unfamiliar world of bits and buttons. Our queues are not filled with messages from self-sufficient customers who have it all figured out. If only! Instead, we help motivated-but-lost people. People who are looking for certainty.

Andrew’s worked as a Happiness Engineer at Automattic since 2010 and has just started a newsletter on the craft of customer support. If you’d like to learn more about doing customer support well, I highly suggest you head over there and subscribe.

What I’ve been doing:

On the whole, I try to take a personal approach. Almost like I’m helping a friend out. People know it’s me answering them. Not a bot or outsourced call centre operator.

I’ve also tried to avoid using the word “easy”, and to provide certainty as Andrew suggests, but I don’t always succeed with the latter.

I often find myself saying “I’ll get back to you”, then going to double check with Ahmed. Also, some times there are bugs in the plugin that take time to explore and fix. So it’s not always possible to go in with confidence and certainty.

This, however, is balanced out by my goal to try to answer each legitimate query fully. This means that we’ll take the time to explore the issue, solve it, then guide the user to fixing it on their end.

At the end of the day, users seem to appreciate my approach. But, like I mentioned right at the top, this might be because users generally have low to zero expectation of support from a free plugin. So any support they receive from me already exceeds expectations.

I’ll be curious to see whether my approach remains appreciated once we launch the paid plugin.

How should I deal with multiple channels?

One of the tricky things about support in 2020 is that there are so many channels through which users can contact you.

As with most things, the best approach for you probably lies somewhere along a spectrum. Here are the two ends of this spectrum:

1. Staying sane approach: Some companies funnel all support tickets through email. If you message them on Twitter or Facebook, you’ll get an automated message instructing you to email their support team for help.

2. Customer-first approach: Others companies happily answer users on whichever platform they first got in touch.

What I’ve been doing:

In my case, I’m closer to the latter approach — I respond on whichever channel a user reaches out on.

Sometimes, I take it a step further: When a user messages me on one channel but forgets about it, I try to hunt them down on other channels to give them the support they need.

I’ve found and spoken to users across Telegram, Twitter DMs, Slack, Discourse, Email, Facebook and WordPress forums.

This is definitely one of those “do things that don’t scale” moments, but until I have to scale, it’s nice forming stronger relationships with users this way.

Sorry to interrupt, but if you’re enjoying this post, you might want to subscribe and receive new issues via email. Your future self will thank you!

[memberhero_form id=244]

How much access should I ask for?

This is a question that’s specific to WordPress plugins. A WP plugin is a file that a user uploads to their site. This means that I don’t have access to or visibility on their site unless the user goes out of their way to give it to me.

When it comes to getting access, the tradeoff is obvious:

More access = easier to trouble shoot issues but more responsibility for anything that happens on their site while I have access.

As usual GiveWP’s excellent open sourced Support Manual is my first port of call for learning best practices on this topic and any other support-related queries I have.

In their Asking for Credentials section, they detail how to request access to a user’s site, and when you should do so.

To save you the trouble of reading it, the main thing you should know about their process is that it’s very safe and responsible.

What I’ve been doing:

If I had a support team and many tickets, I’d probably follow GiveWP’s process word for word. However, that process is overkill for us right now.

In our case, we’ve accessed less than five users’ sites, and in each case, it was the user who first suggested giving us access.

In all of these cases, I suspect the user is willing to do so because their site is not huge or mission critical. They also feel more comfortable with us because they know they’re speaking directly with the two co-founders, and not some nameless, faceless corporate drone.

Whenever a user wants to grant us access, I’ve requested they create a new user account for us. And to delete our account right after.

This is simple for both us and the user. So it works for now. But I imagine I’ll have to make this process more robust over time.

How do I write good documentation?

My favourite support documentation comes from Mailchimp. To be honest, I can’t highlight a single outstanding thing about their documentation. But that’s a good thing. Documentation isn’t like marketing copy, it’s not meant to stand out.

To me, the two most important criteria are:

1. Could I quickly and easily find the document I needed?
2. Did it solve my problem?

When it comes to Mailchimp, the answers to both have consistently and resoundingly been: Yes!

Having had to trawl through the documentation of other email service providers, I can assure you that the quality of Mailchimp’s documentation is not an industry standard.

What I’ve been doing:

Honestly? Not enough. I’ve spent a lot of time and effort writing the docs we currently have, but they’re still not great.

Here’s a list of areas I’ve identified to improve on:

1. Structure of knowledge base – This should be done based on what is most intuitive to the user, not what makes sense to me as the author.
2. Level of detail – Right now, I’m trying to balance between clarity for the user and my own sanity when writing a doc.
3. Breadth – I need to write more docs!
4. Depth – As our user base increases, we’ll find more issues, misunderstandings and edge cases. All of which will enable me to document an issue more deeply.
5. SEO – I haven’t worked on any SEO optimisation yet. However, I’m happy that Gist, the support software I use, has SEO settings for each doc. So SEO becomes a “simple” matter of filling in blanks.

Wrapping up: Here’s how I look at support…

All support tickets are valuable to me. It means someone relies heavily enough on something I built to bother reaching out and getting help for it. So I always try to help, and let them know that I actually give a shit.

It honestly confuses me whenever I hear founders bitch about their users demanding random features or requesting support for something obvious or not relevant to their software.

Even if your customers are outright nasty, I think the correct approach is to calmly help them, then try to fix your product so it doesn’t produce this level of angst for your customers in the future.

As Andrew Spittle says, “We must treat their frustration as a signal that we should invest more in our understanding of their situation.”

Maybe I’ve yet to encounter a deluge of support tickets, so I’m not jaded. But as of right now, I feel like that’s the wrong attitude. When you view your users adversarially, it’s hard to have enough empathy to build a good product, write marketing copy that resonates, or even just give them the support they need so that they’ll stick around.

And obviously, you need all three of those things to build a profitable business.

Don’t get me wrong, I don’t blindly say yes to everything. It’s more that I appreciate users reaching out even if I have to tell them the feature they’ve requested isn’t going to be built any time soon, or ever.

All in all… I’m looking forward to selling my paid plugin, getting more support tickets and scaling up the quality of support we provide.