Per-category default reply when emailing in


(Carlo Kok) #1

While the category email-in support is maturing, are there plans for a feature where the user would get a reply from discourse when they email to a category incoming email address?

this would make it possible for the user to add extra information to the private thread, since they now have an address they can reply to, and it would give some sense of “this email didn’t go into a black hole”.

I couldn’t find anything like this on the private support portal page in regard to this but this would finish up the feature quite nicely


(Matt Palmer) #2

As a private support portal system supporting e-mail, I think this feature is rather important, for exactly the reasons @carlokok listed.


(Jeff Atwood) #3

I’m not understanding this request? You mean a reply from Discourse when a topic is created based on your email?

Seems like it would be simplest to echo your topic back to you, if that’s what you want, and that’s certainly how others who have category watch on (or mailing list mode) will get it via email.


(Régis Hanol) #4

When you send an email to a ticketing/support system, they usually send you back an email acknowledging that they’ve received your email and will have a look at it.


(Carlo Kok) #5

Indeed. The reply has an added advantage that you can reply to the reply to add extra information to the request.


(Jeff Atwood) #6

Still, replying back with your own topic seems most logical to me.


(Sam Saffron) #7

Sort of, in some helpdesky situations you reply with:

“Thank you for submitting an issue to us, we will look at it in the next 24 hours, if you have anything to add please reply to this topic, your issue id is #221

I am not convinced this is required though cause it just adds noises and is a very “helpdesky” like bit of feature creep.


(Carlo Kok) #8

I doubt anyone really cares about the id. But having something to reply to, and some kind of indication that, oke something is on the other end and I’ll get a response in the future (for support purposes). Our current support thing looks like and it’s always quite clear to customers what’s going on:

Hi.


I have received your email message requesting support and have logged an issue as SUPPORT:12345 so that someone who is alive and conscious can have a look and help you. Please expect a response from someone in our support or development team, soon.

Expected response times are within 24 hours (on work days) for Premium Support, and within 72 hours for general support. Depending on our workload, responses can happen quicker or slower.

Also, please make sure to keep the identifier "SUPPORT:72977" in the subject line for all further communication about this issue, so that it will be easier for me to track future responses from you and make sure they are associated with the already open support request.


PREMIUM SUPPORT

If you have sent your message as premium support item, I have opened an initial support ticket for you. As per our premium support guidelines, individual tickets will apply for unrelated requests; if your message fits these criteria, a member of our support team will contact you and let you know how many support tickets will apply to solve all issues.


Yours,
...

(Matt Palmer) #9

Hmm, I thought making Discourse a private support portal was pretty much making a “helpdesk”, with a UI that didn’t make you want to cry. Could you explain the differences, as you see them, between what you think of as a “helpdesk”, and what you envision “Discourse as a private support portal” providing?


(Sam Saffron) #10

It is a bit rough in my head but as a guideline

Features that I do not see in core, but are fine in a plugin

  • Assign user to topic
  • Stop watches to measure how long a user worked on a topic
  • Custom list of statuses for a topic (open - in-progress - requires help)
  • Elaborate reporting dashboards
  • Assign priority to topic
  • Due date

Features that I see in core

  • Way better handling of messages
  • Better messages UI, suggested topics for messages
  • Presence features (who read the message, who is reading it, who is typing) - opt-in feature needs to be in core to hard to integrate from the outside
  • Canned replies

On topic I can see either echo or optional “receipt of topic” a feature we have for improved mail support.