Is Email a Reliable Communication Tool?
As developers it's easy to email users of our systems. How do we know if the email ever reached the user though? And (more importantly in some cases) can you ever prove it got there?!
Most systems I've worked on have sent email notifications out. Until recently I've never really thought much about what happens after the .send() method has been invoked. Hey, I've sent the email. Now it's in the hands of the internet gods. Whether the user ever actually reads it or not, I just don't know.
One recent scenario involved sending a Booking Confirmation email to users of an online booking application. The first line of the email is in big bold letters and reads:
Please print this email out and bring it with you on the day as proof of booking.
The trouble is that some users didn't print it and didn't bring it. In fact they claim they never even received it.
This is the point where email fails as an effective form of communication. It just can't be relied on. This is especially true nowadays thanks to our friends the spammers. Spam filters are having to get more and more aggressive in order to be effective. In doing so there are bound to be false positives. As I understand it system-generated emails themselves are more likely to fall prey of spam filters, especially when faking from headers. It's a wonder any of the emails we send get there at all.
So, my question to you is, if you have an important message that your user must see, how do you make sure it gets to them?
Alternatives to the booking confirmation email which I've discussed with my customer are:
- Display the content of the email to the user on the last page of the booking. It's at this point they should print the page. The email is still sent, just not relied on as the sole means of communication.
- Have the last page of the booking warn the user to expect the email. It could tell them to make sure they can receive emails from bookings@acme.com and to check their spam filters if it's not there in the next ten minutes.
- I even suggested including a "tracking image" in the HTML email which loaded from www.site.com/bookings.nsf/getImage?OpenAgent&foruser=user@company.com. When the user opened the email the site logged it as read. The trouble is the spammers invented this trick and so most email applications now won't load images in emails and, although this might prove a user did see the email, it doesn't prove they didn't.
It all leaves me feeling sad that the spammers have all but destroyed a wonderfully simple means of world-wide communication. Maybe that's the problem. SMTP is too simple a protocol.
Do you rely on email? If not, what do you do to get round its shortcomings?
Skip to the 
You can subscribe to an individual
Jake,
Why don't you have a link at the end of the booking process which opens up either a PDF or nicely formatted booking confirmation. This way you can track if they clicked on the link.
Also the email confirmation you send could also include the link - which again you can track.
Mark
That's another option Mark along the lines of #1 above. I hadn't thought of PDF though. Nice idea - being printable 'n' all.
What about system-generated emails that aren't triggered by user action though? For example a nightly email to remind users of an upcoming deadline. In those scenarios is there any way to be sure of delivery?
I am not sure if the bigger problem is not the people that should read a mail but if the message is really important I sometimes send a SMS reminder. It is quite cheap nowadays and works much better at least if it is ok that there is a noticeable delay between send and receive.
By the way I am not sure what you mean with faking mail adresses.
In general I often see a direct relationship between the content of an email and successful delivery. The worse the content is the less people will receive it. And claiming that you never received something sounds much better than admitting that you forgot to print that thing out.
Indeed there is no general prove that someone read your mail.
instead of printing something out I would try to use confirmation links and reminders.
If that doesn't work either then maybe adding more useful content like xenis enlargement or advertising little blue pills can raise your success rates!?
Hi Jake,
I think option 1 (in combination with Mark's commants) is the best for your current scenario if you ask me.
And about the discusion you try to start :-).
SMTP is not something you can use to be sure something is delivered. The only sure thing you can give is that the message is delivred to the next hop point. This can be filtered out of the server logs.
And then there is something like Return Receipts but again this is triggered from the remote side (user / e-mail client) so again this is not something you can use to prove that a user has goten the email. If you get the Return receipt back it is a proof that your client/customer has received the email and read it. But again the client/customers who do not insist of sendeing back the Return Reciepts its no prove for them if they got the mail or read it or not.
To have functionality like that SMTP is not the right choice.
Jake, I'm working on an html email for confirmation at the moment. There's a nice resource at http://www.campaignmonitor.com/
You can sign up for a free account, but they do send a lot of emails reminding you to use the service, but there's a nice feature to show how your emails look in all the major mail clients: http://www.campaignmonitor.com/testing/
We're trying to send a php generated barcode (duplicated on the confirmation page of the site) in the hope that they either print the page or the email and bring it along with them for faster registration. I'll let you know how successful we are.
How about using an SMS server and sending SMS at the end of the booking and providing a unique confirmation# to the user.
In the same SMS, provide a URL to open on the web & put the unique confirmation number & print your booking information.
Syncing an SMS server with Domino isn't a very big thing in a corporate environment. So leverage the benefit of it.
In any case, sending a hardcopy of the actual printout is really necessary to avoid any discrepancies. But again, if the delivery of the print is gonna take more than the time required to board the flight / train, its better to use online features.
Like irctc.com uses the method of actually shipping the railway tickets in india. & keeps a history of booked tickets in its web portal, so a user can print it whenever needed.
I would be very careful about adding any type of tracking image. This is a sure fire way to trigger spam filtering.
Can you not approach it from another way?
How important is it for the 'booker' to have a documented proof of booking in the first place? What's the point in being to do all this electronically and virtually when it stands or falls on whether the end user is able to/remembers to print the whole thing off onto paper? What happens if they legitimately dont have access to a printer? It all seems a bit primitive and from a time past.
Are there ways in which you can circumvent this - can you not give them a PIN number to write down/remember/that they must enter along with their credit card details, that way you know they have had it, if proof is so important.
Would I.D just not do? How likely is it that someone would want to go to the trouble of impersonating someone just to get something free when they know that the real person will be turning up soon anyway?
Right. I've got it.
When they book online, as well as all their details you ask them to enter a pin code that will be unique to themselves (could be longer/could be shorter) - this becomes their 'key' - they enter/quote this every time they come into contact with the business, either verbally or online.
When they then turn up in person they should know this code, and this is therefore their proof.
Do I win?
I have seen and used all the ideas here at various events.
I hate "needing" something printed out.
that's just stupid, ESPECIALLY IF CONNECTED TO ANY TECHNICAL CONFERENCE OR EVENT!
Everyone has a phone, send an SMS to it, they have a blackberry get on their messaging list and send them a message to it.
The best one I have seen is where they show your admission ticket online and you can save it as a file or save to your phone, then ical it to your calendar similar to how yahoo maps sends instructions out.
This way no paper is wasted, you have a copy of the registration and all is well.
Yes ... email is now unreliable and can not be trusted.
I have a system that's been running about eight years that sent status reports at various times during a work-flow. (RficSubmission.org) About four years ago many of the customers started emailing to have me manually check the status because they weren't receiving the emails.
I tracked this down and discovered several SPAM prevention measures were preventing my status messages from reaching their destination. So I started saving every status message on the system so that when the customer logged in they could check them. Part of the instructions told them that, if they weren't getting regular status updates to log in and check them on the web site. This cut down on a lot of the administration overhead.
Of course this doesn't address your problem which sounds a lot like an authentication issue. The airlines in the US handle this by letting passengers print out boarding passes from the web site and at the airport.
It also occurs to me that if you're using a printed email to authenticate something, it could be very easily forged with a text editor.
Peace,
Rob:-]
Jake
SMTP is well named. Send Mail Then Pray.
There is *no* general solution to your problem; you have no knowledge of the potential recipient's circumstances so you just have to give it your best shot depending on how serious the situation (ie consequences of failure), and what you believe is a reasonable course of action in light of the transaction type. The level of effort to ensure delivery has to be proportional to the consequences of failure.
The key is to give some choices and either pursue all of them or let the user opt-in to the best for their needs.
You should *push* the info out in various channels that might include email, SMS, snail mail and others.
You should also have a simple way that recipients can *pull* the same data (eg from the web, or the phone). At the start of the transaction you should indicate the time by which a confirmation should reach the user and in the event that it does not how they can initiate the pull.
As already suggested using a PIN as the transaction ID works fine as long as the period the transaction is open is not too long. The longer the time the more PIN digits needed !
If the transaction is a financial one and paid for using plastic then the card number used to buy can act as the PIN. Theatre booking offices use this simple mechanism to ensure that tickets collected at the box office get to the person who paid for them.
All transactions are a two-way street and in your own words if the user *must* read the message then they too bear some responsibility.
All channels are fraught (email spammed, phone out of range or dead) but if you cover push email and SMS and pull from a website and phone you can probably demonstrate 'reasonable endeavours'.
IMHO you should *never* require that anything is printed and bits of dead tree produced as 'evidence'. Trivial to forge and I for one am a full time traveller and usually have no access to a printer.
Regards
BTW never undertake 'best endeavours' to deliver as that *will* be understood as requiring you to do it regardless of time, trouble and expense.
Thanks guys!
I will feel a lot more confident now when I plead ignorance as to why an email one of my systems sent was never read by its intended recipient. By calling the .send() method I've done as much as I can to ensure they get it. Why they might not is anybody's guess.
As for the reason for requiring a print-out let's not go there. Suffice to say I'll suggest they have a re-think on that policy.
What I think I'll do is shift the important information from the email to the last page of the booking.
Thanks again,
Jake