There are only two people in our company, yet we manage to run quite a few websites, handle a decent amount of clients and are generally quick to respond to support queries.
A lot of the positive feedback we get early on with someone is how much faster we respond to things when compared to previous developers with which they’ve worked.
There are some things I think we do when it comes to support which others may not, so today I wanted to share six of them.
1. Limit the places support queries can happen
For each project, there are precise places where support can happen.
When working with a client, this is communicated up front and will generally either be email or Slack.
When it is general support for a project we look after, there is usually a support email address, contact form, or similar.
Limiting places where support can happen means support can be efficient. You’re in the mindset of giving support when you check that area. It isn’t that you receive a text message at 9 pm to which you inevitably forget to reply.
2. Limit the use of holding emails
A common theme I’ve seen some people use is to send a holding email, either automated or manual.
I rarely use holding emails. I don’t think they serve any purpose. There is no value in telling someone you’ve received their email if you hadn’t received it they’d have received a bounce-back.
These emails are cruft and are a step in between the reported problem and the communicated resolution.
The only time I send a holding email is when I know we won’t be looking at something until a date in the future. A reply like this helps manage expectations.
3. Check for new support queries regularly
The cadence that you check your emails or other support locations depends on how much time you can spend on support and how much support you typically have to give.
We want our clients to trust that we will support them, so we such we try and respond to all support requests quickly and are happy to dedicate the time that this requires.
It pays to assume the worst-case scenario. If someone emailed you 2 minutes after you’d finished checking your emails, what is a sensible amount of time you’d allow them to wait before having the email read? If you check the support email once a week, that feels like too long a time for most people.
The act of checking for support queries doesn’t have to take long. You don’t need to sift through every email in your inbox; you need to check for support style emails. Unless you’re getting dozens a day, this shouldn’t be time-consuming.
4. Use TextExpander for common responses
One of the biggest reasons I can reply to support emails so quickly is my use of TextExpander.
TextExpander lets you type a small snippet and have it expand into a much larger piece of text.
When a recruiter emails us something completely unsolicited and irrelevant I reply with;
When I type that it gets replaced with the following text
Thanks for getting in touch.
This link explains our current status: https://tosbourn.com/recruiters/
Not the longest email in the world, but you can imagine how much typing you are likely to save over weeks and months.
I wrote a blog post about my TextExpander usage statistics which you might find interesting.
TextExpander does so much more than simple text replacement. You can run scripts and have the result become part of the replaced text, have TextExpander ask you to enter text to personalise responses, and more. However, since we’re just talking about support in this article, the most important use I have for TextExpander is allowing me to share lots of text very quickly.
5. Answer on a first come first served basis
Wherever you allow support to happen should allow you to see which requests came in first. Always making sure you tackle support as a first-come, first-served basis means that when you have limited time to spend supporting something, each person will feel like they were getting answers promptly.
The only time I would veer from this is when two support tickets come from the same person, in that case, use your judgement to tackle the highest priority first.
6. Give more information than needed
One of my main goals when communicating with someone is to give them enough information not to need to contact me again. Doing this is a win-win; no body wants to give or receive support. If you can share something that lets your client get on with their day, they will thank you for it.
For example, when someone asks for a sponsored post on tosbourn.com, I use TextExpander to send them this;
Thanks for your interest.
We do accept sponsored posts on tosbourn.com, so long as they are relevant to a web development audience.
Our non-negotiable rate is £120 per post.
If that is in your budget then happy to talk more if that isn’t in your budget, I do own some other websites that accept content for a lower price. All information here: link
We accept payment by bank transfer or PayPal.
Sponsored posts contain a small comment at the end saying this was a guest post, but apart from this is treated like any other post on our website - it is indexed, shown, and promoted the same way we would for posts we create.
Look forward to hearing from you
They rarely ask if we accept PayPal upfront, but from previous experience, I know that this will be one of the next questions, I’ve added way more information than was needed to answer the original email, but the receiver will be in a better position to move forward.
Hopefully, you found these tips useful. I’m still learning how to be better at answering support questions. If there is anything you do that you think has helped you stay on top of support requests, we’d love to hear it. Comment below.