This has been happening randomly since the email change a while back, but it is now to the point where we are probably going to just cancel our service with you. What happens is, a customer's email blocks an email from Freshdesk one time, then Freshdesk puts them on some kind of 'bounce list' and no longer attempts to email the customer. This means that even after the customer's email system has white listed Freshdesk, they cannot receive any communication from us until we contact Freshdesk to have their email allowed again. The big problem (and this is beyond insane), is that your system does not alert us that it's not delivering our messages to the customer. This means that our customers simply receive none of our answers to their helpdesk ticket, and we have no idea they are not getting the replies. We nearly lost a customer due to this!! Let me make it very clear, we were considering legal action against your company if we had lost this customer. You cannot have a system that simply refuses to deliver our messages to the customer, then fails to alert us to this. This is continuing to damage our reputation, and only due to the terrible design of your email delivery system. This needs to be completely resolved in one week (meaning we are either alerted when the system does not deliver an email, or you eliminate the stupid 'bounce list' nonsense completely), or we will absolutely be cancelling our service with you.
Customers randomly stop getting our Helpdesk emails
+1I've reported this problem many times, each time the answer was, that it will be planned in the roadmap.
I personally consider that this is a HUGE issue. You cannot offer a ticket portal, mainly operating with emails, which does not support notification upon unsuccessful delivery of the email.
It just appears as sent. And this is applicable for all type of events - reply, forward, new email. If you make a tiny typo adding the to address in send email or forward email (with contact which is not in your customers lis), you are done. The recipient will never receive it and you will never know.
The more frustrating thing is the one Tim H mentioned. If you get your email to a certain recipient(s) bounced several times, the mail service Freshdesk is using will mark this particular email(s) and put them to their suppression lists. This could be caused due to temporary configuration problem at your recipient's mail server.
After being put on the suppression list, EACH email you sent to those email addresses will appear as properly sent in the portal, but they are actually dropped and never reach their destination.
And the worst part - you will NEVER know. Freshdesk team cannot give you information about all contacts being sent to the suppression list. You must specifically ask for a certain email address.
Dear Freshdesk Team, you will lose a lot of clients (when they realise this fact) if you do not implement receiving some sort of notification that the email is not being sent.
As discussed in my support ticket - I do not want you to change the mail services you are using or emails being sent in the suppression lists. This is normal behaviour.
If I know that there is problem, I'll contact you and ask if the email is in your suppression list in order for you to whitelist the domain or remove it from there.
But now - we are left in the dark.
This seems like a pretty serious issue, and I'm concerned that there is no response here from Freshdesk.
+1As a developer myself, this is a top priority issue. The functionality is in the essence of sending emails. The sender MUST know if his message reached its destination or it was bounces and with what reason.
Furthermore, some of your contacts gets in the suppression list due to temporary email relay problem and you never know that he is not receiving your emails anymore.
Just imagine the impact we've got on our SLAs with the clients. And an answer like "we never knew you did not receive this" is not an option.
I've opened a thread with feature request here. Still no response. This should be moved on top of the queue.
Regards,
Anton
To me, the most obvious way to do this would be to provide access to a list of every email sent by the system, how it was sent, and whatever is known about its status.
Even if a UI is deemed too difficult to do quickly, surely it should be possible to make an API available that lists sent messages, their contents, and their status.
+1I think this is not possible since Freshdesk use third party email providers which keep their logs for the account of their customers, in this case Freshdesk.
However, I know of two of their providers and I think I glanced an API for retrieving the status of the sent email. This would come handy for integration within their porta.
For example, most of the messengers for Android or Web have delivered status for each message sent. It could be a small icon in top corner of the sent message:
- Sent
- Delivered
- Failed (whether because recipient is in suppression list or the recipient mail gateway bounced it)
Not sure how all those dots got there, but...
It is really silly that this is still an issue. Sendgrid has a really great API that shouldn't take a competent programmer more than a couple of days to integrate.
How about adding a front-end component that allows administrators the ability to search for addresses on a bounce list and delete them?https://sendgrid.com/docs/API_Reference/Web_API/bounces.html
Get your programmers on it. You have lost business over this issue. Given the quality and ease of integrating the sendgrid API, the ROI should be measurable and immediate. This is "the most obvious" way, and as an added bonus, it is the easiest and most robust way.
This is becoming a serious issue and causing a lot of mistrust in our system. I don't know how Freshdesk is not making this a priority as this is a serious issue that could drive customers away.
+5We are also experiencing ongoing e-mail issues. Anything that affects our customers damages our reputation and we cannot allow our vendor to make us look bad. Unfortunately, Freshdesk does not fix issues, they just put it on the roadmap. We are a software company. When major issues appear, the roadmap is suspended until the problem is solved. Freshdesk needs to reassess their priorities.
+1I'm glad that finally people are starting to realize the severity of the problem... Please escalate more so FD team realises it too and make it top priority. After all, this is the CORE of their service...
Hi everyone,
Thank you for your responses on this thread - we understand the severity of this issue and apologise for not having picked it up earlier. Rest assured, we have picked this up now and are analysing the best approaches to solving the problem.
We typically want to provide you with the following information:
(a) Information pertaining to the reason for a failed / bounced email delivery
- This could be when a "hard" bounce occurs typically because of an invalid recipient address
- This could also be in context of a "soft" bounce when an email got as far as the recipient's mail server but was returned before reaching the intended recipient's mailbox. Typical example of this scenario is when the recipient's inbox is full.
-
While the two scenarios mentioned above are fairly straightforward, there are also scenarios when mail servers do not necessarily return bounce notifications and block certain emails with the intention of preventing potential spammers. If emails to recipients of a specific domain are alone failing, we often find this to be the reason.
(b) Information pertaining to corrective action, if any
- In the scenarios mentioned above, we also want to inform you of corrective actions that you can take wherever applicable. At the very least, letting you know the reason of a failure in itself will help you take corrective actions, but that is something that we need to properly evaluate as there may be multiple recipients to a single mail and not all the recipients may have faced an issue for the same reason. Additionally, emails could have been sent manually by agents using the ticket page or by automations and I am sure you will want to be informed either way and we want to evaluate the best approaches to this.
We intend to the fix this problem iteratively and I will periodically post updates on this forum with potential fixes and timelines. In the meanwhile, let me assure you that we are actively working on resolving this concern and you will definitely see an enhancement in the near future.
Thanks,
Arvind
Quick update to my previous post - we will be actively tracking this request on this forum post going forward, so please do follow our updates there.
Join the Community
Sign in to the Community
Social Login
Login with LinkedInEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.