From ‘do not reply’ to ‘do reply’

It’s 2023 and we keep seeing ‘do-not-reply’ email addresses being used to reach out to a company’s users, ourselves included. This is a CX shot in the foot. In this article we’re going to explain why a “do-not-reply” address is a bad idea on this day and age, and present solutions so that our readers who choose to do so can finally follow the path of the do-reply.

What is a do-not-reply email address?

We dare say that no one — and we mean no one — enjoys bumping into a “no reply” experience.

You know what I’m talking about, certainly. That experience where you receive an email notification from a brand or service you use, hit reply and send… Only to receive an error email directly from their server, saying the address does not exist.

Or a company statement informing that that is not the right communication channel, while also asking you to go and submit your problem to them elsewhere.

Or nothing at all. Just total silence.

Not fun.

Not useful.

Always frustrating.

Examples of no-reply experiences

Please note, while we’re not here to shame anyone, if those in charge of the business, its customer experience and/or support strategy choose to have things this way (no matter the reason), we can use their example and criticize constructively.

The following examples were gathered kind of from personal communications (ours, familty and friends who shared theirs). We’ll use them just to illustrate this dreadful experience that we believe organizations should avoid.

These no-reply “strategies” also demonstrate that even especially large companies – with the means to have customer experience and success teams to do great things – completely neglect this support journey.

The good (“always here to help”)

These are the honorable few who do pay attention.

Businesses who send notifications from actionable email addresses.

Or those who still use a “do-not-reply” address but have the real support address as a reply-to, just in case someone does respond.

Some just send their emails from a friendly address like hello@… and want to be there for their customers, no matter how long the ticket queue may be.

We just couldn’t find them so far – we hope to update this article with positive examples, at some point!

The ugly (“we care… kind of”)

These are the cases where they did automate a reply, but do not address the message. Most of them also ask the user to submit their request again via the “proper” channel(s).

These cases show a somewhat thought-out user journey, although they end up not accepting the message, anyway.

They usually ask users to visit their help center or submit a request, and here’s where we get a bit itchy: most of them do not share a direct link to the request form (🏆 honorable mentions: Atida and Continente).

Our comments for businesses that have this kind of experience:

• Firstly, if the user is replying to your do-not-reply email, they already submitted a request, technically speaking. Why clutter your support queues with yet another unnecessary ticket?
• Secondly, you’re outright assuming they haven’t checked the docs you linked.
• Third, even if they didn’t feel like checking the docs, the necessity to write to you is there already, and it has been fulfilled by the user. Why would you deflect their need for support?
• Lastly, your support tool should have a way to configure an automated reply that already suggests possible articles related to the message received! A general link to your help center is nice but it probably belongs in the email footer.

The bad: (“who are you, and why are you writing to us?”)

Those cases where we get an email reply from the mail server saying the address doesn’t even exist or that we “don’t have permission” to use it (when they chose it as a reply-to address in the first place).

Those who really don’t care at all. Those who have decided any customer support must be through their app, or only after you sign in at their website (which means you need to register an account first), and so on.

🏆 Honorable mentions 🏆

• Vodafone Portugal takes the tragicomedy prize: their no-reply address is actually “apoiocliente”… Which literally means “customersupport“! You can’t make this 💩 up
• VivaWallet informs your email couldn’t be delivered… But if you are facing issues, write to their support email address. Why not just accept the reply and get on with it?
• Renault informs that our message “Obrigado” (“‘thank you‘”) is too large!

The wrong kind of effortless

True CX is all about making it effortless, only most businesses got it wrong with this… It’s not supposed to be effortless for you. It must be effortless for users. Making it effortless for you is not CXellent 👎

Here is some food for thought:

• It can happen that at some point one of your valuable customers might need to reply directly to your no-reply email containing their latest invoice. Does this help you promote customer success?
• Do you personally like this? That is, replying to a business whose service you pay for, and get a do-not-reply?
• Is this what you call an “effortless” user journey?
• If only ten user responses are relevant out of one hundred replies to your do-not-reply email, isn’t the channel already worth the “sacrifice”?
• Better yet: if only one in a hundred is a valid reply, is it still worth it? Cost-driven minds will probably answer differently than customer-centric, of course.

Lastly, here’s a free CX hot take:

Providing low-quality service to non-paying users means we’re creating barriers for them to ever become paying customers.

The case for no-reply?

Some could argue that no-reply email addresses can be useful in certain situations: those email notifications are automated messages that should not require a response.

Additionally, there is already an official contact form, email address, etc., that customers should be using and should know about. Therefore, allowing replies to this email could potentially lead to inbox clutter, increasing triage efforts, etc.

From the business perspective, we can agree that a given email notification’s content is, in general terms, something that doesn’t require a response. In the eyes of whoever decided to use a no-reply address, it’s just a notification: it doesn’t need a comment, confirmation or whatnot from the recipient. So why accept it?

This perspective way of seeing is a business choice, sure… But a very lazy one.

• What if the link behind your CTA is broken?
• What if your Instagram user changed and no one forgot to update the email footer links?
• What if the customer has some other request?
• Etc.

In the end, we go back to the same core experience, and it’s very simple: if a user replies to us but we don’t, we’re ignoring them, period.

The way of the Do-Reply

We hope the following are compelling enough arguments to convince anyone to drop their do-not-reply address and user experience.

No-reply = no analysis

Another thing that gets us kind of itchy here at Opservator: do-not-reply experiences are not measurable. How can anyone at these companies analyze anything around this experience? Do you have a reply rate for these cases? If you’re in the last group (“the bad”), likely not.

Let’s assume, for the sake of the argument, that using a no-reply address is a positive strategy (assuming it’s a ‘strategy’!).

• In what way does it create a positive experience for users?
• And can you control what you can’t measure? (Peter Drucker says no)

The ‘lesser evil’ argument

A rather silly and unnecessary argument but let’s put it on the table, nonetheless.

Let’s say we make the transition. Suddenly, a lot of people start replying to those emails we used to send from our do-not-reply address. We set up our automated responses:

• A ‘message received’ notification where we inform that someone will attend to their request/issue as soon as possible
• However, we also state that this specific channel typically implies greater waiting times
• Lastly, we inform that we usually prioritize requests received via [link to support ticket form]. Hopefully, they will use that channel next time. And if not, that’s fine, too – it’s up to them!

🔥 Now, suppose we never follow up on this. That our support team never gets back to the user. That is a bad experience, of course… But is it worse than the do-not-reply examples we shared above? No, because at least we let them write to us!

Multichannel, omnichannel… Noreplychannel?

Let’s address the multichannel or omnichannel strategies most companies have implemented and some like to boast about.

Businesses love to be everywhere for their users: Facebook, Twitter, Instagram, Tik Tok, AI-powered (or not) chat widgets embedded on their websites, WhatsApp, Telegram, etc., and email… Except the no-reply notifications! Businesses don’t want to be there for the customer in the case of do-not-replies. All other email exchanges are OK but not this one. Integrating Twitter so that Twitter likes are created as tickets makes sense, but allowing people to respond to that particular email? Never!

Makes total sense, doesn’t it?

Perhaps companies do this because triaging is a pain… Granted. But no one said life was easy! If you’re going to be doing the talking, you better be prepared to do the walking, too. So if you state you’re an example of effortless experiences, there are still these user experiences you are not measuring and handling.

Ultimately, it’s just plain bad CX.

What are companies so afraid of, really? That recipients will respond en masse to their emails? Just because someone decided it didn’t make sense for customers to reply to a given email communication, it does not mean customers shouldn’t be able to have that choice.

Summing up, the do-reply approach:

• Is always measurable and actionable
• Is aligned with a basic principle of being available for customers
• Is effortless for the user, something the do-not-reply is not
• Is a small sacrifice for a positive impact on brand and service perception
• Is not bad CX

And when you have the opportunity to do CX magic tricks, why waste it?

There is the good way, the bad way, and the ugly way. Then there is the ✨CXellent Way✨

– old Opservatorian saying

We shall now present multiple ways to make this change.

Implementing a ‘do-reply’ experience

There are many ways to accomplish this. We’ll go through each method in detail.

Setting up the email address(es)

Firstly, we need to define the email address(es) we’re going to be using instead of our soon-to-be deprecated no-reply address.

There are no rules here. This is where we decide whether we’ll use a global do-reply address or an email address per user journey, for example.

To sum up, we can use:

• A global [email protected]
• Multiple addresses, each one per former no-reply user journey. In practical terms, we would create billing@, newsletter@, orders@, @reminders, @account, etc.

The advantage here is this might facilitate triaging the support ticket, as we at least know the general category of the request. On the other hand, someone might reply to invoices@ wanting to change their account’s username, for example (which means the ticket may need some kind of reassignment). It all depends on your support operations environment and ticket analysis. Double-check with your team and any stakeholders before deciding!

Receiving the reply

This is where and when we decide what to do with the reply.

We should always send an automated ‘request received’ confirmation message, just like with any typical support ticket. This message will be slightly different than the usual notification, however.

Like we’ve seen in “the ugly” examples above, some businesses ask users to submit their request via some other channel. This is a completely unnecessary burden on the user and we are not following this path.

As we’ve previously summed up, our automated reply is set to accomplish the following:

• Acknowledge message reception
• Inform that requests received at this address typically experience longer waiting times
• In a friendly and concise way, educate about the best way(s) to obtain support
• Share important support-related links (to our contact form, knowledge base, etc.)
• Bonus: ask for their help to quickly self-triage and confirm the request category

Let’s review different ways on how to triage the user responses to our do-reply emails.

Triage methods

This is all about empowering users so that they can help us triage the ticket as effortlessly as possible.

We’ll share four methods as examples: manually, using AI, and self-triage by using a couple of methods: keywords and CTA (more complex automation, using Zendesk).

Manual triage

It’s rather obvious, we know, we just want to put it on the table. We’d basically create a specific queue for these tickets and a human agent would then proceed to review and reassign each case.

Although we usually switch it off, you can consider using basic features to set some priority on those tickets and improve the agent’s triage queue. Think Zendesk’s auto-tagging feature, for example.

AI-powered

If you have AI tools embedded in your customer support system, you probably don’t even need to be concerned about triaging the ticket in the first place.

Any AI tool will be able to detect sentiment and urgency, as well as reading the message and identifying its context, request type or category. Check out Zendesk’s intelligent triage, for example.

Self-triage: keywords

We can provide a few specific keywords the recipient can use to help us triage the request.

This approach makes it easier for the user to quickly scan through our most common topics and reply with the one that applies to their case. This reduces the amount of effort required from the user, while still allowing us to better triage their request efficiently.

There are no rules to come up with these keywords, of course, but here are a few rules to help us come up with good ones:

• Simplicity. The keyword should be easy to understand and type.
• Specific. They should be specific to a topic. For example, if you need to differentiate payment from refunds, use “payment” or “charge” for the former and “refund” or “return” for the latter.
• Easy to type. They should be short and easy to input. It’s also best to avoid using emoji or special characters.
• Objective, familiar language. Use words that your users are likely to be familiar with and that are also present in your contact form(s), public knowledge base, email and website copy, etc.

Hotels	Retail	Tech
Check-in: “checkin” Check-out: “checkout” Room service: “order” Housekeeping: “cleaning” Maintenance: “repair” Billing: “charge”	Order status: “status” Return or exchange: “returnex” Product information: “prodinfo” Customer service: “service” Loyalty program: “loypro”	Technical support: “tech” Product information: “prod” Billing: “bill” Sales inquiries: “sales” Account management: “account”

Lastly, we can always test our keywords. Before implementing the workflow, we can try the keywords with a small group of our customers, just to make sure they are useful (and to potentially get additional feedback regarding the whole process).

✨ Self-triage: CTA or button ✨

We’ll use a Zendesk-based example, and you must be able to create webhooks and edit your Guide theme in order to implement this.

Both complex in its configuration but simple for the end-user, here’s our wild Opservatorian self-triage in three clicks method. The process goes as follows:

• We send the do-reply notification
• The user decides to respond to the do-reply
• On our ‘request received’ notification email, we invite the user to confirm the topic in the last part of our email message in order to speed up our handling their request
• How? We add a CTA/button which leads to our New Request Page (/requests/new)
• The only thing the user sees on that page is a request category/type drop-down and the Submit button
• The user clicks the drop-down, selects an option » Clicks #1 and #2
• User submits » Click #3
• The user’s original ticket is updated with the drop-down value

⚠️ Pre-filled forms might not work if you’re using SSO, but here is a possible workaround.

👉 The second part of the ‘do-reply’ installments is live! For live demo and examples of these processes, check out The Way of the Do-Reply: self-triage methods with Zendesk.

What if users click the button again and re-submit? Well, we either allow it (and let the request type be updated), or don’t allow and add exclusions to prevent any further update.

Feedback on the do-reply

We presented the “do-reply” address on one of the CX-focused online communities and forums we’re a part of and I was happy to see that some companies already accept any incoming email.

Here’s feedback regarding the ‘do-reply’ and how they have things set up:

Thank you for the inspiration! All of our emails are configured so that a reply lands in the support inbox. I very much care to hear from our customers. But we do have an email alias from which we send password resets, team invites, etc from that is “supportnoreply”. I’ve just requested a change to “supportdoreply” with the hopes the subtle message there is “please reach out, we’re actually here to help and we care.”

– Sarah B.

Spot on! That’s the main objective.

Another one:

Even though we’ll do the lift to spin off a new case, it throws our resolution time for the OG case out the window. And we can’t see all the useful data that we would if they had contacted us via the preferred channel. However, I’m a strong proponent for doing a bit of extra lift on our side of things (within reason) to make the experience as effortless as possible for the customer. 

– D. Fernandez

And lastly:

I would be super delighted if I saw the “do reply” email from a team. I think a lot of companies do “do not replies” because they want to be able to track where conversations come from. So, forcing individuals to make a ticket in a contact form is much easier and low lift. As you note, though, it’s a really shitty customer experience.

I’d say take the energy that you’re using to build out a contact form, and instead structure automation when someone responds to what would have been a “do not reply.” That way, you’re tagging it appropriately and can understand the source of the conversation, but aren’t making your team do any extra work.

Honestly, so many tools are so powerful now, there’s really no reason not to.

I HATE a no reply, and if I get them from a company pre-purchase it makes me not want to do business with them.

– M. Smith

This feedback from other experts who work with customer experience just goes to show that the do-reply is more than a good thing to do for our brand, it shows our users and customers that we care and that there isn’t a communication channel where we are not there for them.

I also asked on another CX community’s Slack how many were still using no-replies. The results were positive! When this article was posted, ten out of fourteen businesses who responded were no longer using no-reply addresses.

Conclusion

Businesses should consider avoiding one-way communication channels at all costs, as these are frustrating for users and reflect poorly on brand perception.

By not allowing users to reply to a simple email, we’re essentially saying we’re just not interested. This can damage the relationship with customers and erode their trust over time.

“Do-not-reply” email processes can also make it harder to collect valuable, spontaneous feedback from customers, missing out on the opportunity to improve our products, services, or even the very same email we sent them (e.g. if a link is not working and they want to let us know).

No-replies may seem like a convenient way for companies to communicate with their customers, but they are not.

• 👎 They are effortless for the business, not for the customer
• 👎 It’s a customer journey that is difficult – when at all possible – to measure
• 👎 They are a one-way communication channel

No matter how you implement it, at Opservator we defend the “do-reply” is the way to go. It shows you care for the customer and that you really are present across all channels.

Thank you for reading.

Any thoughts or feedback? I wrote about this on LinkedIn a while back, in case you’d be kind enough to give it a boost, share your comments and/or experience. Thanks!

Featured image: Michael Dziedzic via Unsplash 🔗