Feature Requests
Share ideas, discuss and vote on requests from other users in community
 
This object is in archive! 

Personalize the support ticket format

BryanB shared this idea 6 years ago
Under Consideration

It would be nice to get rid of the "Ticket ID: 2091209109190" in the subject line of support tickets to make customers feel like they are interacting more with a person than a machine and are not just another ticket number.

It seem a lot of helpdesk software providers are starting to go this way, a good example would be helpscout.net

Having the option to get rid of the "Ticket ID" in the subject would be a nice start, then possibly having the ability to show the "from" name of the email as the support agents name instead of the department.

Comments (2)

photo
1

Hi,

Thanks for taking the time to submit this idea.

WHMCS currently uses the Ticket ID value in the email subject to pipe a client's reply into the corresponding support ticket system if they reply via email. It would be interesting to find out how the other help-desk systems you mention handle email piping without such a unique identifier.

If using the support agent's name as the sender there is the potential for SMTP server configuration problems; you'd have to ensure that each address was an authorised SMTP sender. It could also cause problems if the client replied directly to the individual's email address rather than the department's email address - that would not result in the email going to the ticket.

What are your thoughts on those potential hurdles?

photo
1

Hi,

Regarding the "having the ability to show the "from" name of the email as the support agents name instead of the department."

I think @BryanB meant that the display name will be changed - not the actual email address.

So if My name Is Ram Freedman - and I sent a mail from the support department with [email protected] the email will be sent from Ram freedman ([email protected]) and not from Support ([email protected])

Any way - this is just my understanding from what @BryanB wrote 2 years ago.

In my opinion this should be optional...