I am a huge fan of Yammer, but this guidance goes for any enterprise collaboration tool that you might be using. I now receive too many e-mails to keep up with. If I spent my whole day processing e-mail I wouldn’t be able to get through it. So I don’t try anymore.
For this reason I’ve actively been trying to shift more and more of my collaboration to Yammer to try and leverage my network as a way of coping with the volume.
Quite a bit of my e-mail volume is notification messages from Yammer which I will soon be turning off (except for direct e-mails or replies to threads I’ve engaged in) since the Yammer app on my phone uses notifications to let me know about things that I’ll be interested in.
What this means is that I am starting to move to a model where e-mail is more for external organisations who don’t use Yammer (or some other tool). Is Yammer a perfect replacement for e-mail? Nope! Both tools have a place and one of the tricks of being an effective communicator is to know when to use e-mail, phone, Yammer or any other mechanism.
Personally I’m looking forward to caring less about my Inbox.
In our environment at Readify we have a mail-gateway in a private environment that we use to route e-mails from various internal systems onto our cloud hosted environment (was BPOS, is now Office 365). Due to the e-mail problems we had last week those e-mails queued up, and queued up, to the point that we had thousands of the e-mails sitting there.
When we finally switched that mail gateway to use Office 365 we got a flood of e-mails, followed by a series of errors inside our various systems. Turns out that we were hit by a policy around sending limits inside Office 365. We raised a support case but unfortunately this can’t be configured. I guess they are trying to mitigate the risk of people using Office 365 as a spamming platform.
In our case its completely legitimate. We have a lot of systems that generate unique e-mails to various users. Most of those e-mails come from one account (firstname.lastname@example.org) to signify that they are machine generated. Incoming e-mail to the email@example.com mailbox is periodically checked for issues but hopefully the e-mail address discourages it. The kinds of systems that use this are:
- Team Foundation Server
- Dynamics CRM
- Heaps of custom applications.
As I said, it appears this can’t be changed. We only hope that we won’t be impacted again since the volume of e-mail that was queued up was a result of days of delay. That said, this limit could be an issue for larger organisations wishing to use Office 365 where internal systems need to interact with mailboxes and send personalised e-mails.
The URL that outlines the policy on the Office 365 site simply suggests that you set up an on-premise mail server. In our case I guess we can probably add our mail gateway as an entry to our SPF records and get it to route mail directly. Its kind of a shame that you have to do that however.
A Better Way
For developers building applications that send customised e-mails on a regular basis, you might want to consider using a service such as Mailgun or the Amazon Simple Email Service. I’m not sure which is better since I haven’t used either (good old SMTP relay is usually good enough for me) but these tools do add an extra level of reliability around detecting issues and allow for corrective action, where SMTP relays, or more precisely programs that use them just drop bad messages like a hot potato, even if it is a transient issue.
P.S. After some searching for how this problem is generally addressed by Windows Azure customers I came across a link to this other service – Elastic Email.