Ask HN: how quickly do you answer support emails?
14 comments
Respond quickly, even if you can't answer the question immediately. The most frustrating thing if some service isn't working is if users think nobody knows or cares. Just a quick mail saying, "Hi, one of our guys is looking into it. We'll send you an update in a few hours." helps a lot.
From my experience, while working on a software development team and replying all the time to questions from testers, business owners, managers, etc., I think I would sum it up like wheels did: as soon as possible, even if you don't know the answer. People will appreciate the consideration.
There are cases when may not have the time to reply immediately to all questions (e.g. small team). In that situation common sense will tell you which ones are more pressing, I guess.
Going a little off topic, one thing I've been noticing that works pretty well (especially in agile environments), if you can afford it time-wise of course, is to have one person exclusively dedicated to support for a week. Then rotate to another person next week. That will both keep the requesters happy to get answers on time, but also the repliers, who can fully focus on other things when they are not "support person of the week".
There are cases when may not have the time to reply immediately to all questions (e.g. small team). In that situation common sense will tell you which ones are more pressing, I guess.
Going a little off topic, one thing I've been noticing that works pretty well (especially in agile environments), if you can afford it time-wise of course, is to have one person exclusively dedicated to support for a week. Then rotate to another person next week. That will both keep the requesters happy to get answers on time, but also the repliers, who can fully focus on other things when they are not "support person of the week".
We have a ticket system (which is just a basic Rails app I built). When a ticket is submitted, the customer gets an auto-reply that we're looking into it. The ticket is emailed to almost every staff member (6 of 8 people). An initial reply is usually submitted within 30 minutes (not necessarily a resolution). Tickets become a thread of messages until it is resolved.
I'm a big fan of a distributed/threaded system like this. I don't like direct emails for support.
BTW, if anyone is interested in using our ticket system, let me know–I could open source it on GitHub or something.
I'm a big fan of a distributed/threaded system like this. I don't like direct emails for support.
BTW, if anyone is interested in using our ticket system, let me know–I could open source it on GitHub or something.
I'm interested. We use email currently which is not very flexible.
Ok, here you guys go:
http://github.com/bigfolio/big-help/wikis/home
There's nothing there yet except a wiki page and an empty Rails app. Give me a day or two to the code organized and commit some updates.
Contributors more than welcome.
There's nothing there yet except a wiki page and an empty Rails app. Give me a day or two to the code organized and commit some updates.
Contributors more than welcome.
Open source it please!
Think this depends on the pricing structure. Are you offering a free or a paid service? Is support part and parcel of this, or do you offer different levels of support?
No different levels of support: best-effort is the best we can do. This means that sometimes it may take a while for us to get respond to somebody, given that we have to sleep occasionally.
I'm mostly curious how other people deal with it. Do people carry a laptop everywhere so they can plug in whenever something happens? Or do people just hope for the best and deal with problems only during "office hours"?
I'm mostly curious how other people deal with it. Do people carry a laptop everywhere so they can plug in whenever something happens? Or do people just hope for the best and deal with problems only during "office hours"?
If our team is going to be away for a few hours, we usually do have a laptop on hand. Otherwise, we just do it through our phones (which is slow and painful), or ask another team member to cover for a few hours.
Side note to parent comment -- we do offer the same support to free and paid plans right now.
Side note to parent comment -- we do offer the same support to free and paid plans right now.
In my current venture, we're not yet to the point where we have very many support questions, we're mostly still in "Friends and Family" testing. However, prior to this venture I worked on some other projects, specifically in gaming / gaming server management and for some small hosting companies. With them, responding to support "tickets" if you will was one of our top priorities. However, rather than using an e-mail support system we relied mostly on forums and, for the game, in-game support message systems.
Every company is different and for most of these we were just a bunch of hackers running free communities (with the exception of the web host provider - which was free with premium memberships). However, the importance of answering support quickly was still the same. In terms of the free service, when things didn't work right or we wern't able to instantly respond we were able to write it off as "we're not paid to be here." That didn't always stick though. You might also consider making sure people know what times you guys are generally available. Letting people know that you're not available from midnight to 6am in your local time is a good thing for your users to know.
Depending on what it is you're offering, looking at a message board / forum as a means of technical support might not be such a bad idea. It allows not only you and your team to answer questions (and quickly from almost anywhere you have net access) but it also gives your other users ways to contribute as well. Most importantly, it's an active way to build a knowledgebase, if done correctly. It also saves you from having to necessarily answer the same e-mail's over and over. Even with an e-mail contact available, you could easily put in an auto-responder that lets them know you got it and gives them a link to your support forum for them to browse for a solution in the mean time.
Note: If you use forums, make sure you find some method of making your support posts easy to manage and your official team members easy to spot.
Every company is different and for most of these we were just a bunch of hackers running free communities (with the exception of the web host provider - which was free with premium memberships). However, the importance of answering support quickly was still the same. In terms of the free service, when things didn't work right or we wern't able to instantly respond we were able to write it off as "we're not paid to be here." That didn't always stick though. You might also consider making sure people know what times you guys are generally available. Letting people know that you're not available from midnight to 6am in your local time is a good thing for your users to know.
Depending on what it is you're offering, looking at a message board / forum as a means of technical support might not be such a bad idea. It allows not only you and your team to answer questions (and quickly from almost anywhere you have net access) but it also gives your other users ways to contribute as well. Most importantly, it's an active way to build a knowledgebase, if done correctly. It also saves you from having to necessarily answer the same e-mail's over and over. Even with an e-mail contact available, you could easily put in an auto-responder that lets them know you got it and gives them a link to your support forum for them to browse for a solution in the mean time.
Note: If you use forums, make sure you find some method of making your support posts easy to manage and your official team members easy to spot.
In my business, which involves $600 software, I reply within 30 minutes. Many deals are lost because you delay in replying emails.
And many can be gained.
It's amazing how many potential customers use e-mails as a sort of "test" to see whether they'll go with you or not. Striking these while the iron's hot can almost guarantee dollars in the pocket a month later.
It's amazing how many potential customers use e-mails as a sort of "test" to see whether they'll go with you or not. Striking these while the iron's hot can almost guarantee dollars in the pocket a month later.
Yes. Once you start emailing with a potential customer, the success rate is about 70%. The effort is certainly worth it.
My answer seems to differ from most people here.
I do all sales and support once per day, first thing in the morning, getting the mailboxes to completely empty. I then glance at the mailboxes a few more times during the day, but don't send any more replies till the next morning. The only exception is if there's an urgent issue or serious bug.
This works for me because:
* I can concentrate on productive work (building new features) most of the day without serious distraction. If I were to reply to emails all day long, I'd get far less done.
* In my experience, users put that little bit more effort into solving problems themselves, if they're given the motivation to do so. They read documentation and FAQs. If you reply to emails within half an hour, you'll often find yourself in a lengthy back-and-forth that takes up a lot of time.
This second point might sound like heresy in a world where the customer is always right. But it's not so bad to lose customers whose opportunity cost in time is greater than their revenue is ever going to be worth.
While a small minority of users are unhappy to wait more than an hour or two for a reply, a guaranteed 24 hour turnaround is still pretty good compared to large companies.
I do all sales and support once per day, first thing in the morning, getting the mailboxes to completely empty. I then glance at the mailboxes a few more times during the day, but don't send any more replies till the next morning. The only exception is if there's an urgent issue or serious bug.
This works for me because:
* I can concentrate on productive work (building new features) most of the day without serious distraction. If I were to reply to emails all day long, I'd get far less done.
* In my experience, users put that little bit more effort into solving problems themselves, if they're given the motivation to do so. They read documentation and FAQs. If you reply to emails within half an hour, you'll often find yourself in a lengthy back-and-forth that takes up a lot of time.
This second point might sound like heresy in a world where the customer is always right. But it's not so bad to lose customers whose opportunity cost in time is greater than their revenue is ever going to be worth.
While a small minority of users are unhappy to wait more than an hour or two for a reply, a guaranteed 24 hour turnaround is still pretty good compared to large companies.
Just responding to every email (except form letters) we've ever gotten asap has gotten us countless buyers, blog write ups and press.
I think this also raises the issue of "personifying your company." Whatever you do, try to show the human side of things as much as possible rather than acting as an autonomous servant.
Use a ticketing system or issue tracker that creates tickets based off of e-mail (I like Jira personally). Setup an auto-reply to let them know their e-mail was received, and someone is looking into it. If your ticketing system is world facing (which I think is a nice idea), ask them to visit their ticket (Jira can auto-create accounts for people who don't have them yet when they send an e-mail that creates a ticket), and set the priority.
Give your timezone/part-time issues, I'd provide a cell phone or something for people to use in case of dire emergency. If people abuse it, you cut off their support service.
I'd also instrument as much as possible so that in the event of a disaster you are first to know, not last. I use a heavily customized nagios setup that sends SMSes to my cell phone. Works out well.
Give your timezone/part-time issues, I'd provide a cell phone or something for people to use in case of dire emergency. If people abuse it, you cut off their support service.
I'd also instrument as much as possible so that in the event of a disaster you are first to know, not last. I use a heavily customized nagios setup that sends SMSes to my cell phone. Works out well.
I've been using email for my main company, which isn't great. Just finished putting together the new support system, which is still email-based, but also logs everything in a private ticket system and texts if there's an emergency.
Response time: it varies, but it's definitely good to send a "hey we're looking into it" canned response so their issue is acknowledged. It would almost be worth it to have a few of those prepared and auto-reply within 10-20 minutes with one...
Response time: it varies, but it's definitely good to send a "hey we're looking into it" canned response so their issue is acknowledged. It would almost be worth it to have a few of those prepared and auto-reply within 10-20 minutes with one...
The answer is 'as quickly as possible' - especially when you think about support as pre-sales and marketing.
I'd recommend live chat similar to http://support.mozilla.com/en-US/kb/Live+Chat
If people are paying you, then you're going to have to make an effort to not only solve their problem, but solve the general problem of support. If you weren't getting paid, you can always make the case that support services are simply unsustainable. But if you're making money presumably you've factored the cost of support into your rate, right?
I think you should think out of the box here.
You didn't ask the right questions.
How can you make people don't email you every time when they have problems? Like building a good knowledge database .... give them the solution of the problem before they asked for it and so on.
How can you prevent the disaster strikes to be less then a minimum and hopefully never to happen?
For does question the right answers depends on you and what you can find on the net ....I think.
How can you make people don't email you every time when they have problems? Like building a good knowledge database .... give them the solution of the problem before they asked for it and so on.
How can you prevent the disaster strikes to be less then a minimum and hopefully never to happen?
For does question the right answers depends on you and what you can find on the net ....I think.
Of course, prevention is better than the cure. No argument there. But no matter what you do, you will still receive some support requests. And I'm curious how quickly people here feel obligated to respond to them.
It's quite expensive to reduce the risks of disaster, and funds are tight. Mirrored servers + high level SLA costs thousands of dollars. We can't spend that to soften the blow of a disaster, which has only a 5% chance/yr per server or so of occurring.
It's quite expensive to reduce the risks of disaster, and funds are tight. Mirrored servers + high level SLA costs thousands of dollars. We can't spend that to soften the blow of a disaster, which has only a 5% chance/yr per server or so of occurring.
How quickly do you respond to support requests? And when disaster strikes (server down/hacked/etc) is there always somebody ready to deal with it?