6 ms·

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

by brk 16y ago

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 16y ago
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.

by brk 16y ago

chaosprophet 16y ago

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.