Why do users reply to messages clearly marked as do not reply

Question

In a web app, we generate a lot of emails including reminders, requests for approvals, login details etc. They all come from a real email address to help with deliverability etc and they all quite clearly state:

*** This is an automatically generated email, please do not reply to this message ***

For clarity here is an example of an email as there seems to be some confusion on the type of message being sent and the suitability of "no reply" emails especially as all the requests require the user to login, check the item and then action something:

John,

Michelle has created a new requisition for 6 widgets which needs your approval - please login and process this requisition

https://www.domain.com/app/requisitions/123/process

    *** This is an automatically generated email, please do not reply to this message ***

And an example of the messages we get back:

Michelle,

Why have you ordered 6 widgets? I thought you only wanted 4?

John

The message is in plain text rather than HTML (again to aid deliverability etc) so there is no other easy way to highlight the line - the emails typically only contain three or four lines and this one is at the bottom with white space above and below so it is not lost in amongst lots of other lines.

Despite this, we get numerous people replying to the emails either saying things like "approved" rather than logging in and actually approving the request or they ask questions etc - these all come to us, of course, but they are actually intended for the person who generated the message in the application so each time we have to find that address manually and forward it on.

Why do users ignore this and reply to an automated message? What clever ways are there which we could use to overcome this?

Edit I have no idea why everyone is assuming this comes from a no-reply@ email address - this is a proper email address with a mail account etc

Answer 1

The best solution would be to handle those emails automatically and forward them to the appropriate recipient.

For emails that can't be auto-forwarded, you can simply write an automatic email back reading something like: "Sorry, you can't reply to our automatic emails. Please login and do your action online (example.com/do/action). If you have any questions contact our support at [email protected]."

Answer 2

I think the problem that you are describing is not a problem with do-not-reply emails but with the lack of support for email interaction with your system.

Many systems (like bug reporting Sifter, Trello, Basecamp and others) let people respond to issues sent to them by email (a response needs to be included above a certain point in the email) and after a person responds - the response is included in the original issue/conversation or a thread by the system. This enables a very easy and quick way to respond and get on with your other tasks without having to login to the system.

Do-not-reply "attitude" simply rudely cuts off a possibility of that dialogue continuing and introduces extra steps for the user to complete their tasks.

If you really need to use "do not reply" (like in the case of password changes etc) consider giving it a bit of personality - maybe a friendly name like "[email protected]" with a matching autoresponder should someone ignore your please not to respond .

Answer 3

I had to add my 2 cents for the sake of the necessity of no-reply accounts, as well as what we do to mitigate the issue of replies to no-reply.

For starters, there are several systems that can generate emails without being tied into an actual email messaging system. For instance, it seems as though the example "generated message" above is from some online retail store, and the back end can generate and send messages; but it knows very little about messaging, as the designer didn't know much about messaging. Like, if I send out an alert from a management platform, why would anyone expect that to be a 2 way street? There's a surprising amount of this type of communication on the internet, and there is a perfectly good reason for almost all of it. Some companies, to avoid this issue altogether, will change the "reply to" address to the user's prefered address, so any reply to the automated message goes somewhere else than where it was sent from. That's not always possible, and not every system is intelligently designed to allow this.

So, rather than trying to tell OP that the issue is "no-replies are impersonal and email is 2 way communication, etc etc" I hope to propose some actual useful advice. What we've done for systems with the described limitations is create specific no-replies for each of them. So, we have [email protected] instead of [email protected]. We have a service mailbox established for each of these accounts in our actual mail system. From there, we go one of two ways: our most common setup is a transport rule that delivers an NDR if someone tried to respond to the message. You can create specific NDR messages, and in this case, it could be "Order Confirmation messages are informational only. For any additional information, contact the user directly or follow the instruction provided in the message." The only issue (benefit?) to this method is no one ever receives the reply. I prefer this method because it forces users to re-read the original message, helping them to learn or do something on their own. Alternatively, you can generate an Out of Office response on those service mailboxes. What's elegant about this solution is that someone can still get the messages and handle them individually while you generate a message back to the sender right away, telling them, more or less, the same as above. Some OOF responses support HTML, so you can even get some good formating to convey your point about the inbox.

Finally, I do believe it helps to have the "automation notification" at the top. We try and put all our notifications for automated messages at the top, so they are less likely to be skipped. This is not meant to be super personal, and a little less worry over not providing every single nicety to the user can go along way. Most users, from my experience, do not expect much in the way of niceties from no-reply addresses anyway. Straight and to the point usually does it for us, and we save our politeness for actual personal interaction. If someone's getting something from a robot or automated account, I think they would rather it be brief and to the point. I liked the comment about [email protected], and that would be fun and semi-personal way to let the user know that it's not a valid account to respond to. It may not have to be named robot, but the message string could facilitate the establishment of that precedence.

Finally, I don't think it's as easy as one would think to automatically handle emails like this. It's easy to recommend it, but many systems make this extremely difficult, at best. It's usually impossible.

Answer 4

Why is not as simple as a user not reading the email. There are two likely scenarios:

1. The message contains no surprising information. The user reads all the way to the end and learns that they can't reply, or only reads far enough to confirm their expectations. They weren't going to reply anyway, so the warning was redundant. You'll never hear about these occurrences because success means nothing happens.

2. The message contains something surprising or "wrong" from the user's perspective. They read only as far as the perceived error (6 widgets in your example) and then anger, confusion, or frustration take over. They fall back on default assumptions about email, which means replying to them, and forget that this is a special case.

To fix #2 you either need to change human nature (a losing battle) or bend to meet expectations and allow them to reply. If they expect a reply to go to Michelle or the person who generated the message, consider using that email address instead of [email protected].

Answer 5

Why do users ignore this and reply to an automated message? What clever ways are there which we could use to overcome this?

The first step in making sure users do not reply to your emails is to make sure nobody ever reads the replies. This is where your problems are starting. You are trying to combine two things that cannot mix, namely use a "real life" account and treat it as a "do not reply" account. If you want users not to reply, just use an account for this purpose.

• Conceive (but do not make) two email addresses, one called something like "[email protected]" and a second one called something like "[email protected]"
• Change the template of the notification email you are sending so the headers have the "notification" address as the FROM, and the "mailbounce" address as the REPLY-TO. For more information on email headers check here.

Edit I have no idea why everyone is assuming this comes from a no-reply@ email address - this is a proper email address with a mail account etc

If you insist in using a "proper" mail account you need to have the discipline (and create credibility with your users) that these kinds of emails are not read. Never EVER read them. Eventually the users will learn. The reason I would use a bogus email and not a real email is because mail sent to a bogus email will typically immediately and automatically be refused by the server. This helps users learn faster. If you use a real account, and if you reply to a user reply with a message "no, don't reply to the notification" then the users know that a human is reading the mails and that the human (you) might help them. Users don't learn this way. My advice - let the server handle it, make sure the user gets an automated error message.

Answer 6

I can present as one example where I attempted to do so was with regard the US Government Healthcare Exchange website.

This site expects you to do certain things via logging in the site. It creates an account, associates it with the user's email. Warns the user NOT to make another account, then sends a confirmation mail that you need to click a link in.

Well, thanks to their fouled up system, the confirmation link never worked, so I was unable to login to the real account. Phone operators tried, but were unable to assist. As the deadline approached I signed up for insurance over the phone.

Periodic attempts to correct the login failed later. The email that was sent contained a dead link. One I tried many times, and phone support had no way to get another sent.

But the system did know my policy was associated with my email. And it sent me NO-REPLY emails telling me to login and do XYZ. (Tasks I eventually had to do via US Postal Service).

At wits end, I did several replies to a NO-REPLY email, in hopes that someone might be skimming replies looking for hints of unexpected problems (as the existence of this question shows can actually happen).

Never worked though.

The rest of the story was that eventually a customer service person suggested I ignore the instructions to not make another account and make one anyway. So I made one using the trick that GMail ignores added periods in inbound email addresses. That way mail associated with either account would come to the same GMail account.

I was able to get a account made, and associate it with my policy with the assistance of the customer service operators. Now I can log in.

And all it took me was hours and hours on the phone and days and days waiting for the US Mail.

Frustration like that leads people to reply to NO-REPLY emails.

and IMHO skimming the replies that do arrive is worthwhile to the company.

Answer 7

Unfortunately there is only one way to fix this issue and it's not a good one. People will always do this even if you include the warning in 48px blinking red type so you have to set the reply-to email as the one that should be getting replied to. Either that or live with people that can't be bothered to read the instructions.

You may consider putting the warning above and below the message. You will still get people doing it though.

Answer 8

A real life example why:

What if the message was sent to the wrong address, because someone signed up with an address he/she does not own. Then the login won't work and to add to that fustration, the email may be in a language that the email address's owner does not speak (and read on a device with no translation option e.g. a phone).

A possible solution:

All you need to do is add a reference ID to the emails you send and if someone replies, use the reference ID to route the email + send a confirmation email (did you send this email yes/no?) to the user to make sure that the email wasn't spoofed.

You should also support remove this address via this method (reply with remove me in the subject) with a confirmation mail.