Ask HN: A completely e-mail based support helpdesk
1 comments
The problem is that it's rarely that easy.
For support issues that would be as easy and simple as "reply 3", you usually put up a FAQ on your website covering those issues.
But more typically you have people who tell you "I can't get feature Y" to work, and the root cause of the issue is something like feature Y clearly says it is a function to manage a window on a second monitor, and the user has a single display (ie: they have no clue WTF they are trying to do).
Email support handling in general is a good process to try to implement. I've done this several times, I have a support/ticketing system that I wrote (in perl) ~8 years ago that I've adapted to 3 different companies now.
My personal findings in dealing with support queue management efficiencies are more about tailoring the support system to the business. The process you follow for creating a ticket, assigning a ticket, and gathering relevant data can be very different among two companies that have a similar SaaS approach, for example. So, I have a base framework that can read and respond to emails that I adapt to the particular use case.
My system has implemented some of the things you mention though. The "reply 3" concept is a knowledge base of common issues that a tech can look up a KB item, enter an email address of the customer, and the system will send a message to that address with an intro along the lines of "Alice thought you might find the following knowledge base article helpful with your issue. If this solves the problem, no response is necessary. If this does not prove helpful just reply to this email and we will reassign the ticket."
For support issues that would be as easy and simple as "reply 3", you usually put up a FAQ on your website covering those issues.
But more typically you have people who tell you "I can't get feature Y" to work, and the root cause of the issue is something like feature Y clearly says it is a function to manage a window on a second monitor, and the user has a single display (ie: they have no clue WTF they are trying to do).
Email support handling in general is a good process to try to implement. I've done this several times, I have a support/ticketing system that I wrote (in perl) ~8 years ago that I've adapted to 3 different companies now.
My personal findings in dealing with support queue management efficiencies are more about tailoring the support system to the business. The process you follow for creating a ticket, assigning a ticket, and gathering relevant data can be very different among two companies that have a similar SaaS approach, for example. So, I have a base framework that can read and respond to emails that I adapt to the particular use case.
My system has implemented some of the things you mention though. The "reply 3" concept is a knowledge base of common issues that a tech can look up a KB item, enter an email address of the customer, and the system will send a message to that address with an intro along the lines of "Alice thought you might find the following knowledge base article helpful with your issue. If this solves the problem, no response is necessary. If this does not prove helpful just reply to this email and we will reassign the ticket."
To handle cases like I can't get feature Y to work, we could probably have something like a conversation tracker, which tracks all the relevant bits of information the support person asks from the user. Then, the next time another user is having the same problem we could just sort of replay out the prior conversation.
Example: A cannot get feature Y to work because they have a single monitor setup, so A fires an email off to support. The support guy reads it, realizes he needs more info and replies that he needs some more info about A's monitor setup. This reply gets tagged as 'request for more info'. Once, A has replied with the required information, Support responds with the appropriate solution. Now along comes B who is having the same problem, so he sends a similar mail to support. The software realizes that it is a similar issue so it automatically responds with a request for information about B's monitor setup, and after B replies to it the entire information is presented in a single email to the support person along with the email and response previously given to A, who then decides if B gets the same response as A.
In my experience people rarely tend to read an FAQ/KB. I have pointed people to a particular question on the FAQ and then bolded and put it in red, and yet have people miss it. They would much rather send an email griping about the issue than read the FAQ. So I've had to send out the same email repeatedly. This was aimed at solving a problem such as that.
Example: A cannot get feature Y to work because they have a single monitor setup, so A fires an email off to support. The support guy reads it, realizes he needs more info and replies that he needs some more info about A's monitor setup. This reply gets tagged as 'request for more info'. Once, A has replied with the required information, Support responds with the appropriate solution. Now along comes B who is having the same problem, so he sends a similar mail to support. The software realizes that it is a similar issue so it automatically responds with a request for information about B's monitor setup, and after B replies to it the entire information is presented in a single email to the support person along with the email and response previously given to A, who then decides if B gets the same response as A.
In my experience people rarely tend to read an FAQ/KB. I have pointed people to a particular question on the FAQ and then bolded and put it in red, and yet have people miss it. They would much rather send an email griping about the issue than read the FAQ. So I've had to send out the same email repeatedly. This was aimed at solving a problem such as that.
Reading the recent thread about the launch of Freshdesk from a HN comment made me go back and read that entire HN thread. While thinking about what a better helpdesk system would be like, I remembered a line in a recent post from Paras Chopra of Visual Website Optimizer, wondering how to cut time on support.
So here's my theory: Early stage startups typically can't afford to have dedicated support guys, so they usually have one of the founders or the developers doing support also. Also, a founder/developer (in such a startup) typically has much better ways to spend his time, than answering support requests. So what if there is a support helpdesk which acts entirely through email?
Imagine: When a support request is sent to [email protected], the email is read, automatically categorized depending on predefined categories, tagged, indexed, and then assigned to a particular person depending on predefined criteria. An email is then fired off to that person with it's content being the original text of the support request, a list of 5 similar support requests previously handled (numbered 1 to 5), and the actions performed and responses given to those previous requests.
The developer can then simply reply with a command verb such as 'reply 3' to tell the support desk that the same response as the third request in the suggested list should be sent back to the user. Or, if none of the suggested responses match, they can simply type out a new response to that request. Or, if they are working on some crazy awesome new feature, they could simply reply with 'reassign' and the system would reassign the request to another person and send them the same email. The responses are then indexed and tagged and sent back out to the user who first asked the question.
This way developers/founders answering support don't have to deal with clunky interfaces, and they can save time by quickly responding to a query without having to search through a knowledge base or something similar. I realise that this is probably not the way you would want to handle support as your company grows, so there would be easy ways to export all your data for use with some other service too.
So what do you guys think of such a system? Does it already exist? If not, is there a good reason it doesn't already exist? Most importantly, would you use such a service? Why or why not? Also, how much would you be willing to pay for such a service on a monthly basis?
Regards,
chaosprophet