43
31 Comments

What I've learnt about customer support so far

No one really talks about customer support when building software.

The exception being when they complain about having an overwhelming amount of it.

Or when hiring their first employee, which is usually a support person (because of exception #1).

As a result, I’ve never really given much thought to customer support till now.

And in typical founder fashion, I’ve had to dive into the deep end of the support pool, despite not knowing how to swim.

In this post I try to organise some of my early thoughts and takeaways around this topic.

You might find it helpful if you’re just beginning to get support tickets too.


Before I start, I should highlight that I’m currently providing support for a free plugin, Newsletter Glue. 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:

Gist platform
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.

Newsletter Glue admin bar

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.


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:

Could I quickly and easily find the document I needed?
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:

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.
Level of detail – Right now, I’m trying to balance between clarity for the user and my own sanity when writing a doc.
Breadth– I need to write more docs!
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.
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.
Gist SEO settings for docs


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 angry and nasty support tickets, so I’m not jaded. But as of right now, I feel like defending your product and complaining about customers is 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.

Thanks for reading! This post first appeared on my weekly newsletter about personal growth and bootstrapping.

  1. 3

    This is gold: "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." Great post! Thank you for sharing Lesley!

    1. 3

      Exactly my thought too. An overall great post, but that sentence needs to be framed!

      1. 2

        Thanks @Merott and @mariordev! You guys rock.

        That's one of my fav bits from the post too. 😁

  2. 3

    Good post. I hold myself to a really high standard for customer support. Any delay of more than an hour I consider a huge failure. This may seem crazy, but I am just addicted to the feedback loop of "Wow, that was fast!" 8 out of 10 times when I reply within an hour, I get a comment like that and I think it makes an enormous difference. When someone is actively working inside your product, has a question or an issue, and you can answer it immediately, it really helps keep them engaged.

    1. 1

      Does your 1-hour goal include sleeping for you?? A huge amount of my support emails happen overnight, and I wish I could deal with them faster.

      1. 1

        No, good point. I don't wake up in the middle of the night! But fortunately, most our business at StatusGator is in North America so I have no issues replying during my waking hours of 6 AM to 10 PM Eastern (UTC minus 4 or 5).

        1. 1

          Gotcha, makes sense. I also look to get a response as soon as possible, I think it's a great thing to do for a small company!

    2. 1

      Oh wow. 1 hr is GOALS.

      Maybe I should aim for that with my paid plugin. Thanks Colin! Really setting a high bar for me. 😉

  3. 2

    Excellent article, really helpful, thank you so much for that!

  4. 2

    Thanks for sharing Lesley.

    It's a really valuable inside look into the magic of the powerful Lesley Pizza show! Super impressed. I think it's so useful for other bootstrapped founders and I'm taking notes for if I build my SaaS in the future.

    Appreciate great content like this on Indie Hackers.

    1. 1

      Thanks so much Janel! 😻

  5. 2

    How do you determine what to write next in your docs? Do you use your docs' search data at all? Great writeup by the way!

    1. 2

      Thanks so much! 🤗

      How do you determine what to write next in your docs?
      The quality of my docs and approach to them are still quite weak right now. So I wouldn't suggest you blindly follow what I'm doing.

      But in general, it's 2 things:

      1. when I'm building something or testing something, there are typically bits I encounter where I think to myself "ok, users are definitely gonna get tripped up here". Then I make a note to write a doc about it.
      2. a user is tripped up and reaches out. If it's a problem I can see lots of people also having, I'll make a note to write a doc about it.

      In terms of actually writing the doc... Tbh, I'm pretty lazy about it. I only write docs about once a month.

      I'll spend a day inside the docs... I'll write new docs. And also do a spring cleaning: Go through all the existing docs and update outdated text, images and videos.

      This is a PAIN. But obviously needs to be done.

      Do you use your docs' search data at all?
      Unfortunately, I only get # of views and # of ppl who found the doc helpful/unhelpful. And the volume is tiny right now, so it's not very meaningful.

      In any case, I have so many obvious qualitative problems with the docs that I don't need to worry about quantitative ones.

  6. 2

    It can be so stressful. I developed an ERP with my dad for a company with about 200 users, to this day I always feel shame when I publish an error. But one thing that has changed is that users respect me because I've always been humble, and people start to blame themselves when you're humble to them. Another thing I do is take the blame, even if it was not my fault directly, I don't say "my team" or "my coworker", I always say "it was all me, I'm sorry Juan..."

    1. 1

      Nice!

      Humility and earnestness are such underrated qualities and competitive advantages.

      It majorly stresses me out too.

  7. 2

    This is super detailed, thanks for the write-up Lesley!

    1. 1

      Thanks Kevin! 🙏 Really appreciate it!

      1. 2

        Of course, really excited to see what you continue to do with Newsletter Glue and the paid plugin!

    1. 1

      Thanks so much Yaro!

  8. 2

    I've been on the roller coaster of offering customer support as well lately. You summed up a bunch of aspects of it super well. Thanks!

    1. 1

      Thanks so much Jesse! 😻

  9. 2

    Customer support is definitely something I have paid attention to recently. I found that I really needed to listen to people and hear them out especially if they experiencing issues that I wasn't. Check out my post about getting feedback that my site was slow

    1. 2

      I am personally going to be setting up GitLab's service desk to start gaining more feedback from users.

      1. 1

        Sounds like a good idea! The more places you can get feedback from, the better!

  10. 2

    Thanks for reading! I'd love to hear your experiences with customer support and if you have a different approach from mine!

    This post was first published in Failing Forward -- my weekly newsletter about personal growth and bootstrapping.

    Read the entire issue here. It includes my highs and lows, and my favourite links for the week.

    1. 2

      Somehow I wasn't subscribed to this :) I am now!

      1. 1

        🎉 thank you! Now I have more pressure/motivation to write awesome newsletters with you as a subscriber. 😜

  11. 1

    Wow, thanks for the detailed writeup! What are you using for writing/hosting documentation?

    1. 1

      Thank you!! 🙏

      I use Gist. They're great and very reasonably priced.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 15 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments