Conversations Inbox Emails To Use "Reply to Email Address" instead of "From Address"
[Posting on behalf of customer]
Hi Team,
It will be great that the "reply-to" email addresses are used to reply to instead of replying to the "from email" address. This is because a lot of email coming from service apps typically have different from addresses and reply-to addresses. Using the reply-to address is what the sender intended instead of replying to a generic email address e.g. info@example.com.
We desperately need this functionality within our Support Inbox since a lot of automated submissions come in here and are not getting assigned to the appropriate owner. It would increase our workflow 10 fold if this were a possibility!
Still asking for this after 3 years. We need this badly as well, for proper customer communications - we have a special reply-to address that our incoming sms to email uses, otherwise we simply can not reply.
We desperately need this, as expanding the header of the sender, doesn't even show the correct reply-to e-mail address. For instance, a message received gets sent from noreply@ and contains the correct message-id@ address, which isn't shown in HubSpot. Having to copy it from another e-mail client. And it is unfeasible to give everyone access to the support mail address, to retrieve the address from.
This is described in the email RFC 2822. You should use the reply-to header when replying to an email. As far as I know every email system and every support system does it - except Hubspot.
The reason you need this is, for example, when you have a form on your website that sends an email to support (which ends up as a Hubspot ticket), that email will be sent from a fixed system (for example form@unless.com). However, in the form the user fills in their email address, which is used as the reply-to header. Of course, any reply in the ticketing system from support should go to that user, not to the form@unless.com email that was used to send the email in the first place.
In the case of Unless, we have an AI that sends that forwards the conversation on behalf of the user to a configured support email address. Again, any reply should go back to the reply-to email of the user, not to the sender (which is our system).
I did talk to support, which told me this was not supported, and is not on the list of being implemented and suggested to make a post here.
This is a relatively large problem for us... we're a hotel and we use the inbox to centralize communication from the Online Travel Agencies (e.g., Booking.com, Airbnb, Expedia, Hostelworld, etc.).
Most/all of them reply on a reply-to address to allow us to reply via email. Our guest service agents have to manually log in to each of these platforms to reply rather than simply replying from within hubspot... which sort of defeats the purpose of having the consolidated inbox.
Bumping this - we had this feature available within FreshDesk (a much worse CX platform!) and it's also available in others, but not HubSpot strangely.
We're an ecommerce store and we have copies of the order confirmation emails come into an inbox, as well as the orders being associated with deals within the Sales pipeline (which works great). We want copies of the actual order confirmation email so the team has visibility on if anything needs to be updated or has displayed weirdly for a customer. However the Conversations think that we are the contact and isn't picking up the "reply to" email which is the customers, so it doesn't work at all.
Please look into this and begin dev on it ASAP - it's not a huge feature at all but will have massive impacts.
This is a major issue & needs to be fixed - basic functionality as many others have said!
We can get 40k conversations into a single inbox per month but HubSpot thinks that we are the contact for all of them because it doesn't recognise "reply to" fields!
Major issue for us also. Emails from our shopify contact form have the customer's email in the reply-to field but hubspot sets the address to the one shopify sent the email from.
.png "HubSpot Employee"){kind=icon}