

Ask HN: A completely e-mail based support helpdesk - chaosprophet

Hi,<p>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.<p>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?<p>Imagine:
When a support request is sent to support@foo.baz, 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.<p>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.<p>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.<p>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?<p>Regards,<p>chaosprophet
======
brk
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."

~~~
chaosprophet
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.

