"If you want to continue with the subscription, reply with the word YES on a line by itself. You can put comments on other lines and we will read them."
do-not-reply@marketing.com is one of the stupid innovations by people who can't automate their email. Transactional email gets handled by robots and fed into a ticketing system when it goes awry.
Treat your customers like customers, not consumers.
Now you need to deal with « yes », « Yes », « YES. », HTML wrapping, user signatures, dangling spaces, etc.
I’ve worked with a system that let users order domain names by email and it was a nightmare to maintain. Don’t EVER build a system that relies on reading and parsing emails sent by users, it WILL fail horribly.
> Now you need to deal with « yes », « Yes », « YES. », HTML wrapping, user signatures, dangling spaces, etc.
Oh no, you need to find a line of text in a string that contains the word 'YES'. How incredibly difficult. Are you even a programmer? This is entirely trivial.
My point is you have to trust a user to input some raw text somewhat reliably. Have you dealt with users at scale? Whenever you provide a raw field in a form, the values are pathetic, tons of users can’t input things correct
Maybe they’ll write « yeah » or « YE » or « oui », because that’s what users do
If the user can't follow basic instructions then they'll have to try again.
Those users absolutely can write 'YES'. They're perfectly capable of doing so. They don't do so because they're lazy. We all know people that simply refuse to read any kind of instruction on a computer screen. They will skip past any and all prompts. Guess what? That's their problem, not yours.
Some businesses like to retain users, and not alienate them using obscure, hard-to use-user interfaces, and blaming the user when they get it wrong.
If you can't create a way to say "yes", which is at least as easy to use as checking a checkbox and clicking a button, why should I assume you're capable of, well, much of anything.
It's not that it looks unprofessional.
It looks either incompetent, or deliberately obtuse. In either case, I'll take my business elsewhere.
> Oh no, you need to find a line of text in a string that contains the word 'YES'. How incredibly difficult. Are you even a programmer? This is entirely trivial.
"Yes alright renew my subscription, just make it start in two weeks this time"
Your "solution" fails immediately here, because it gives people a false idea that they are in a dialogue with you whereas they are actually just expected to reply in a binary way.
Finding "a line of text in a string that contains the word 'YES'" is indeed trivial, however if that's all you can think of you should not be employed in any position of responsibility as it demonstrates a profound lack of judgement, understanding of how real people behave, and general business acumen.
How condescending can a single software system be..? A reality check might help. Most of us write applications used not by nerds, but ordinary human beings. They don’t want to perform weird ritualistic dances just so the computer does beep-bop - ”I understood what your intention was just fine, but do it right for me!“.
Have you ever worked with the general public? At least half of adults would fail at that basic task.
The point of a business is to make money. You make more money by making the experience for your customers as easy as possible. If you don't, another company will.
If someone wants to unsubscribe, that's probably because they don't want to be your customer any more anyway. Unsubscribing for a now-irrelevant-to-them e-mail list may be a problem for these ex-customers, but it isn't yours any more.
Transactional emails are things like reset password emails. You’re really going to build your reset password functionality by having people email their new password to you?
You can certainly put urls into a text/plain email. It helps if your urls aren't terribly long and don't have characters that are questionable in urls.
w3c suggests surrounding them with angle brackets [1], but I can't find a source that makes more than a suggestion. By reports, some mail user agents, and some users will include the trailing > in the url they provide to their web user-agent, so that's something to consider and make sure the destination of the link can handle.
Putting links on a line by themselves works well too.
If you don't know what a user prefers, it makes sense to send a text/plain with links as I've described, as well as a text/html with links in tags, because tagged links may be friendlier to some users and some mail user-agents are tragically bad at their job.
Yes, you can put them in there, but then you're relying on the recipient's client to turn that plaintext url into a link the recipient can actually click on, as opposed to having to copy and paste the url into their browser address bar.
All the mail clients I use support this, including URLs that wrap onto new lines. Yet I still receive some emails with broken links if they wrap onto new lines. Somewhere along the way, these break before getting to my mail client. I never experience this with HTML email.
If you send long URLs – for instance password reset links with tokens in them – then you need to send them with an HTML part if you want them to be as reliable as possible. Leaving long URLs at the mercy of not just mail clients but the entire mail transmission apparatus, cannot be relied upon.
Transactional mail typically requires some hyperlink for the average user.