When you think about it, sending automated email to your customers from a “Do Not Reply” email address is a really odd thing to do, yet most online business do it. Why?
At first glance, it seems like a very cheap way to solve a very visible problem — allowing replies would mean someone has to read all that email and deal with it. If you’re the person dealing with all that email, or paying the team that does, your natural bias would be to treat this email as a cost. With the mindset of reducing costs, “Do Not Reply” is pretty appealing:
- it’s cheap — a few hours to configure the email server and change the “From” address in the template
- it’s effective — all that email will stop immediately
- it’s accepted — everyone does it, we’ve all seen it before, we’ve been trained that this is normal
Of course, thinking about the customer’s experience, there’s nothing appealing at all:
- it opens the conversation with a negative statement
- it rejects the idea that the customer may need to reply, or may have a question
- it creates a dead end, not a conversation, breaking the basic concept of email
- it requires the customer to start a new thread in a new email or support system if they need to continue the conversation
- it can only cause angst and frustration, rather than satisfaction and delight
It’s also important to realise that when we cut off all that noisy email, we also cut off the conversation with the customer — a valuable source of product feedback:
- was this email clear?
- was this email valuable?
- was this email missing important information?
- was this email timely?
- was this email solving a problem for our customers?
So, dealing with all that email is a bad idea, and cutting off the email with a “Do Not Reply” is a bad idea. When faced with this type of problem, look for the constraint that’s hiding the most detail. In this case “we don’t want to reject replies” seems pretty solid, while “we don’t want to deal with all that email” seems to have some wiggle room. Maybe we can get better at dealing with all that email.
If we allow replies, what kind of emails will we have to deal with? What smaller problems can we find to solve? When we break out these smaller problems, there’s a much higher chance we can find simple solutions that don’t suck for customers.
This isn’t an exhaustive list, but it’s a start:
- We’ll see a high number of “bounce” emails where the customer’s email address no longer exists, or their inbox is full.
- We’ll see a high number of automated replies from customers that are out of the office, on leave, etc.
- We’ll see some replies which are legitimate support questions highly relevant to the original email. A great example might be replying to an order confirmation email to check if it’s too late to cancel or modify the order.
- Some replies will be routed to product managers that are a little off topic (like replying to the shipping confirmation email to get help with recovering your password).
- Some customers will send new support emails to this address by mistake.
A lot of these can be solved with automated email filtering and redirecting rules on our mail server or within our support system. Here’s a start:
- We can set-up filters to detect most of the bounces, and improve them over time. We can simply delete these or file them away.
- We can do the same for the auto-replies.
- We can use the subject line (“Re: …”) or reply-to email address in the replies to detect the source of the original email and automatically redirect it to someone who can help — the relevant support department, or better still, the relevant product manager. By helping the customer directly, they’ll be motived to improve the experience in order to avoid dealing with similar email in the future.
- We can quickly read the off-topic replies and forward them into the regular support system. An pessimist would consider this a chore, an optimist would consider this an opportunity to learn more about what confuses their customers, or to develop further filtering rules for automation.
- We can easily detect emails sent to the wrong address because they’re not replies (they also don’t match any of the previous rules), so they can automatically be forward into the support system, where they belong.
At worst, this is a few conversations, a few hours of configuration, a few days of watching the inbox to set-up new rules, and a few hours a month to monitor and review. Speaking of review, there’s value in the data we collect from accepting these emails:
- We can monitor the bounces, feeding this data back into our product (marking accounts as abandoned or suspicious when it comes to fraud or spam, reminding customers to update their email address when they next login).
- We can see which emails and parts of our product are causing the most questions and confusion, and need the most attention.
Yes, all this is more effort than a simple “Do Not Reply” address, but it’s not an outrageous cost, and not unreasonable given the massive upside — engagement with customers, faster product improvements, deeper insights, actionable data, better alignment with tools & behaviour, and of course, an improved overall customer experience.
Nearly everything gets better when you insist on a better user experience.