I'm working on a SuiteCRM solution that will send notifications via workflows to clients.
These notifications are sent from an email address and a subject line that changes on a project basis. So "Project A Notifications" will send from "Project A Manager" with the subject "Project A"
The idea is, for every project, to have these conversations be grouped as threads in email - Gmail and elsewhere. That way, a single project could have tons of small notifications but they are all organized within the same subject line and thread. Our team could then do back and forth emails with clients while occasionally a new notification email jumps into their conversation, so all information is organized.
What I've discovered, however, is that conversations thread ONLY when emails with the same subject are sent on the same day. When I was testing this solution, I was completely convinced it would work because I had the system send tons of notification emails and did mock correspondence in the same thread with no problems. However, these tests were conducted on a single day basis.
Emails sent on different days do not thread. This crucial fact means that my tests were not at all useful.
Does anyone know why this is? Is there a possible solution that I can setup that would accomplish this (same subject, same sender, different day, same thread)?
Related
I want to learn different ways how you guys handle incoming emails in Dynamics CRM.
How you make sure that everyone is responding to their emails?
Can we filter incoming emails to get the ones which are not yet
replied? On daily basis we are getting a lot of emails and we want
to have a filtered view where we can only see the emails which are
not yet replied yet.
How you deal with incoming emails which are sent to sales#
accounting# etc.
3A. How you distribute them among different users?
Assigning to them?
Forwarding to them?
3B. And how you make sure that they are replying to those emails?
I will appreciate if you I can learn from your experience on this subject
Use the existing Customer Service module which Microsoft has built for this purpose. Incoming emails create Case records, which are actionable items with associated statuses.
How you make sure that everyone is responding to their emails?
Set up workflows so that unassigned cases cause escalation of some sort (i.e. an email sent to a manager)
Can we filter incoming emails to get the ones which are not yet replied? On daily basis we are getting a lot of emails and we want to have a filtered view where we can only see the emails which are not yet replied yet.
Filter by Case status
How you deal with incoming emails which are sent to sales# accounting# etc.
- How you distribute them among different users?
You can set up routing logic so that cases are tagged with specific attributes, or assigned to specific users based on what address the originating email targeted.
Assigning to them?
This is out of the box case functionality
Forwarding to them?
Set up a workflow to send an email to the case owner or other user
And how you make sure that they are replying to those emails?
A simple option is to review the email history associated with the case. Automating this task is certainly possible but can get complicated.
You could add each email into a queue, and have users process emails out of the queue.
There is a setting to enable this on the entity configuration with the customisations area.
Emails when tracked or synchronised then appear within Dynamics within the queue.
Users then process the queue. This also caters for the scenario where emails do not need a reply - they can be removed from the queue. In this model, the emphasis switches from checking emails are replied to, to checking queues are cleared.
Reply email are linked back to the original email via the Parent Activity Id. So you could build a filter around this.
Create a queue for these to receive email.
The email address that you enter in the Incoming Email field receives all messages sent to the queue.
A) Users can pick items from the queue, a team leader can assign queue items to others, or use bespoke customisation or development to automatically route items.
B) As above.
We have been using iContact for Salesforce to send our company's mass emails for a couple years. We typically have low bounce rates (1-2%) and are consistently sending large numbers of emails (30,000 - 40,000 total sends per month, spread across 10-20 different emails).
Earlier this year, we launched a new product (The Outcomes Survey), and I created a new HTML email template for it with unique branding for the new product. Every time we send an email with this new template, the bounce rates are in excess of 15% (even though it's sent to the same group of contacts we send our typical emails to, and comes from the same email address).
When I pull a bounce report, most of the diagnostic codes are: "spam-related (554 rejected due to spam content)"
I have run the email template itself through several online spam tests, and it comes out clean. As far as I am able to tell, there's nothing in inherently wrong with the email. You can see a sample email here.
When we send emails using our original company branding and template, our bounce rates are low. Any email sent with The Outcomes Survey branding, bounce rates jump up again.
I'm stumped!
I was able to solve the problem by recreating the email from another template that has worked in the past. So, I guess there was some code in the original HTML email template that was causing problems, although I wish I knew what it was!
I've set up a Mandrill webhook which will update my app whenever an email hard-bounces or is rejected, so I don't keep that particular email address in my database. The way it works is this: a user gives me an address, I send him a confirmation, and if I don't hear from Mandrill's webhook in 30 minutes, I assume it's OK.
So I ran a some tests with non-existing addresses, and they didn't go too well. Most of them appeared as delivered for hours, long after I'd assumed they were fine.
Also, I didn't account for the delay in receiving webhook batches. One mail bounced at 2:01pm, according to the outbound activity logs, but the webhook history shows a batch being sent only at 2:52pm.
My questions is: how long should I delay my app's assumption of deliverability in order to give Mandrill enough time to detect hard-bounces / rejections and then send me webhook batches? I can live with letting some 5% bad emails going by because of delayed in processing on peak-time or other extraordinary events, but it seems like my 30 minutes isn't enough to catch anything at all...
Not the answer you're looking for, but Mandrill doesn't let you do this. The only way of checking if an email has been delivered is to poll Mandrill (with the message/info.json API). To see if the message is delivered you have to check the smtp_events and look for an event with diag starting with 250. As you've already experienced it may take a long time between delivery and when a message is accessible through the API. In my experience the normal case is around 10 minutes, but it might take many, many hours (this is the case for bounced emails as well as emails that got delivered immediately).
If it is important to you to know when an email is delivered, I would recommend you to switch to another email provider. There are plenty of different ones out there. I've personally used Amazon SES. They're cheaper than Mandrill, and you can expect a delivery notification after a second or so. Do note that Amazon SES is a bit more bare-bone than Mandrill (they don't have support for open/click-tracking, templating, dedicated IP, etc.), so it might not be the right provider for you.
With regards an OMS, what is the best method to send a confirmation email? The 2 options I have so far are;
A script on the order page sends an email once the record is written to the database.
A scheduled task on the server, send the email, polling the database every-so-often to find new entries.
Which method do systems currently use?
For e-commerce websites, it might be better to think about the best user experience.
Given that, you would want to send the email as soon as the order is received so the user knows that they have purchased the item. The sooner it gets into their inbox, the sooner they will be happy that they have made their purchase.
I agree with Digbyswift that sending the confirmation email once the record is written to the database is the least scalable. But I would argue that if your system has gotten to the point that you are taking so many orders that your system cannot keep up, you have a wonderful problem on your hands that you now probably have resources to handle.
At PostageApp, we handle the emails of a few e-commerce websites, so perhaps you would benefit from an arrangement with an email service provider to off-load this task so that all of your resources can be spent on keeping your site up and your databases running.
Here are some great alternatives if PostageApp is not your style:
Sendgrid
Postmark
Mailjet
This is a question of scalability. Sending a confirmation email once the record is written to the database is the least scalable. The more orders that are taken , the more emails are sent potentially tying up resources.
A scheduled task is certainly better as emails can be queued up and can be sent in a separate process.
A further option which you could consider is using neither and delegating the responsibility of sending emails to a 3rd party dedicated emailing service, i.e. via an API. This is much better since your hosting does not have to consider the load and you can utilise any reporting offered by the 3rd party. Plus many services offer a free quota up to a certain threshold. This will allow you OMS and business to scale appropriately.
If you apply a message based architecture; you could just publish an order created message and have any number of subscribers respond to that event. You could create a listener that sends the email in house (bespoke option) or another listener that called the API of a 3rd party emailer to send the email on your behalf (as per #Digbyswift)
What I've always liked about this approach is
You can have any number of listeners live at any one time.
You can create a new listener and change how you send the email without needing to change/redeploy the OMS application itself.
You can take the listener(s) off line and stop / delay the sending of the email without losing any notifications or affecting the OMS itself.
There are many articles and threads about guidelines while sending bulk emails. Most of the times it was mentioned that emails should be sent to the subscribed users. So that we can avoid "users clicking on spam in their mail boxes".
There are some features in famous social networking sites where we can send invitations to Yahoo contact list. In such scenarios the persons in our contact list actually did not subscribe with Linkedin to get invitations or other mails. But the hard thing to understand is how do Linkedin and Facebook mails don't go to spam?
Developers often attack this problem from "how can I do everything (DomainKeys, et al) to ensure the message will not end up in someone's spam box?".
I used to work on a website that mailed 20,000 users weekly.
The key point in keeping out of the spam box - beyond all the technical components laid out in the link above posted by Martin - is making sure that your recipients do not spam-can you.
Bayesian detection algorithms on mail servers source data from users who click "this is spam" in their mail clients, so if your users think you are SPAM, you are - and you'll get lower delivery percentages (be prepared: 100% is impossible).
Use your brand or website name as the From: field. Your customer is most likely to remember that, if nothing else. Attempts to "be close" to the customer by using a name of someone in your organization is usually a bad idea, even if you're consistent. Identify your organization UP FRONT, and in the subject line every time.
Make the unsubscribe link incredibly easy to find (not at the bottom!). Users will say "this is spam" to make the message go away if they can't figure out how to get off your list. You don't want these people on your list anyhow.
Double opt-in. Don't add anyone to your list without their explicit opt-in. Not only do you have their blessing, but the delivery of the opt-in message indicates that they're getting your mail. The ever-famous "call to action" of "please add us to your address book" is viable, but I personally never do this when a service asks me to.
Have a schedule on which you send, to whatever the user has agreed (weekly, monthly, etc). If you are not consistent, users will forget registering with you and the mail will seem random. Also, allow them to change the frequency as the next link right next to "unsubscribe" - many people unsubscribe because they are annoyed by too-frequent messages.
To avoid being considered as a SPAM, the easiest and most powerful method, is to not send a SPAM.
Check this to understand what is a SPAM and avoid sending one: http://en.wikipedia.org/wiki/Spam
Jeff Atwood has written quite a good article on this.
From now on, we are using a commercial provider. There are several on the market (like critsend, which is among the more inexpensive ones) which also do bounce handling and make sure that "permanent failures" are not sent out again in the next bulk.