I'm writing a school administration software package, but it strikes me that many developers will face this same issue: when communicating with users, should you use email or SMS or try to combine them?
A previous version of this question was closed for being too subjective. The answers will be somewhat subjective but I do think this is a good question, topical and not yet debated widely. I'll try to narrow it down as much as I can:
Is it feasible to give users the choice of email versus SMS, and have the same business logic apply to both, with the help of a long form and short form message template?
Do users get annoyed when receiving the same message over SMS and email?
Is it common to present administrators with a single report listing message delivery failures combining both SMS and email?
Are there significant numbers of users who prefer to be contacted via facebook rather than SMS or email?
Is there a best practice for all this stuff?
Is there a place on the web where this stuff has been debated?
Are there any reputable commentators who have made predictions about the future of all this stuff?
I'm particularly interested in hearing from developers who have already grappled with these questions.
Is it feasible to give users the choice of email versus SMS, and have the same business logic apply to both, with the help of a long form and short form message template?
Yes, you can implement logic for the user to select which methods of communication he would like to use
Do users get annoyed when receiving the same message over SMS and email?
ABSOLUTELY! Unless the user has set up to receive messages in both the formats
Is it common to present administrators with a single report listing message delivery failures combining both SMS and email?
Yes
Are there significant numbers of users who prefer to be contacted via facebook rather than SMS or email?
Cannot comment on this, YMMV depending on the usage of the site, the target user group etc. You site stats & trends over a period of time will help fine-tune this aspect.
Is there a best practice for all this stuff?
Sure, see a lot of sites which give opt-in/opt-out options for getting communications from the sites. The tendency to spam/flood inboxes with a lot of email should be avoided & the user should be able to set how little/much data should be sent to him & in what format. Google is your friend here, there are tons of articles out there on different aspects.
Is there a place on the web where this stuff has been debated?
I am sure you will find all sorts of legal & other details around this aspect, google is your friend on this item
Related
I came from a similar state in this question.
My objective is to reply to interested customers via whatsapp messages. I'll use a very special setup, so I'll be using the API.
Reasons:
With not to pay anyone other than container hosts
Solution with custom API
Customer doesn't like any extra costs
Just like user noboundaries, I see the numbers, but I cant get the certificate
User Navjot Singh has explained I need to create a "business api account"
I tried just that, put out all my contacts and stuff, in this site.
They did respond yes, but only with pointless instructions, since I wish not to contract any messaging providers. I had taken a look at it, but they charge a very expensive price beyond the $0.005 whatsapp will charge. Also, the solution I'm creating requires messages to be sent programatically, and the partners don't seem to provide the correct solution.
So, I wish to skip into using the api. I followed the appropriate guides:
Getting started
Phone Number
I already got some things done:
two phone numbers (one of them for testing) with whatsapp business;
company has been verified, with domain
have business management account
local environment with docker
I can access the local environment and I have set an user account and the admin acount. I can log into those via the API, since postman can ignore certificates, but in order to proceed I really feel like I need that certificate.
So to sim up I guess I need help creating the whatsapp business account for my customer. Any advice?
Also i'd appreciate any other helpful insight or feedback. I really feel lost and I don't see a place where I can talk to people trying to do the same thing, or doing this is much of a madness after all?
thanks for getting to read until here, and I apologize for my non natural, almost broken English.
Hi I wanted to start big in stackOverflow but I fell flat.
About the subject at hand, westerday I dwelt deep into the rabbit hole.
For most companies, you actually are forced to work with a provider, such as twllio or messagebird. They act as intermediary between the facebook business and the whatsapp business api.
Some of they offer messaging separated from whatsapp api setup I still need to take a look into it, but for those who are trying to set up whatsapp business api on their one, it seems as of november 2020 it's not possible.
please check out:
respond.io's guide
blog post from take.net PT-BR (google translate didn't like me trying to translate this to English)
Does SendGrid support double opt-in to Lists as a feature or is that something we will have to implement for ourselves?
https://sendgrid.api-docs.io/v3.0/contacts-api-recipients/add-recipients
It doesn't appear to me to be anywhere in the docs, but I thought I'd ask in case I missed it.
Not as of the current date; I asked their support staff and received the following answer:
Double opt-in needs to be implemented by you in the form/page you're subscribing your recipients. The confirmation email can be sent through SendGrid.
For Marketing Campaigns we have the SendGrid’s WordPress Subscription Widget that makes it easy for people visiting your WordPress site to subscribe to your marketing emails;
or Building a SendGrid Subscription Widget.
I got this answer from their support. It turns out we have to implement it by ourselves.
The double opt-in functionality is not something SendGrid provides as
we expect our customers to handle any opt-in practices on their side.
We apologize for any inconvenience.
SendGrid will be GDPR compliant by May, 25, 2018. Please note that
SendGrid does not – and does not currently have plans to – use servers
or data centers in the European Union to process email. Thus, SendGrid
cannot restrict data to the EU. However, neither current EU law nor
the GDPR require this. Instead, what is required is that SendGrid must
provide "appropriate safeguards" for data that it hosts and processes
on its US servers (see Art 46 of the GDPR here). SendGrid offers a
Data Processing Addendum (DPA) to provide such adequate safeguards,
which includes provisions for when GDPR goes into effect.
More info on GDPR can be found here. Our DPA can be reviewed and
signed by filling out the information here.
They do not support it. I asked support many times, which is a strange as it would seem a company of that size could spare the dev resources to build a feature that literally all of their customers need.
However, https://sgwidget.com is a third party product that provides double opt in functionality for Sendgrid accounts.
Full Disclosure: I am a developer at SG Widget.
No, indeed still today, they do not. Not in their forms, nor in their API is there simple, flip-switchable support for double opt-in. But, with email automation fairly recently implemented in their marketing services ("free" and "advanced" plans, not "essential") you can send an automated email directly upon sign-up.
My solution is to have 2 lists for new contacts, where one is a "pre-confirmation" list and the other being the "real" list. Here´s a way to use automation:
Create initial signup form, either via their sparse Web forms or via your own, using HTML/JS/PHP and API endpoint:
Create 2 separate lists, one for "pre-confirmation" emails and the other for people who confirm their addresses.
Make the form sign up new contacts to the first list, "pre-confirmation".
Create a marketing automation flow that triggers upon new signups to the "pre-confirmation" list. Make the automation trigger an email that contains a button or a link with the following link structure:
https://yoursite.com?email=user#email.com&passphrase=[phrase-you-set-manually]
where ?email= is your user´s email, substitute this in the email template/design by {{ Sender_Email }}
where &passphrase= is a phrase long enough to not be guessed. Since you only have one single email design here, and you can only enter one single phrase, unless you make a script or a hash, you make it difficult enough for people to think it was generated by a server :).
On your server/application, yoursite.com, use $_POST['email'] and $_POST['passphrase'], or whatever you name them, to validate the email clicks from your list and then enter all validated emails to the correct list using the PUT
/marketing/contacts endpoint.
you may also have to delete the user from the previous list, using DELETE
/marketing/lists/{id}/contacts, but I do think that the PUT /marketing/contacts takes care of placing the contact in only the lists specified in the list_ids field.
once the contact has been entered into the correct list, you can also have a marketing automation set up for that list, which sends him/her a welcome message.
This method takes care of double opt-in for SendGrid without using one single email credit from the Email API (transactional plan). The only catch is that we utilize one initial and one second/final list to achieve it.
Note: the initial sign-up message that here acts as the "confirm your email" message, will be tied to the first list and will require a marketing unsubscribe link in the footer. Make it clear in the bottom of the email that it is a temporary list, to not get any spam complaints. But it will not be an issue, as we wont be sending to anyone in that list except for this initial time. Unless you have a user who enters his/her email twice, after some time of inactivity when they forgot they already signed up. That could happen. But it´s a separate issue.
I think this is possible by switching the flow of a typical email subscriber. When the user clicks your subscribe button, instead of calling the sendgrid members/contact PUT api to add to your list, send an email with a link to a URL of yours that will then trigger the members/contact PUT api call.
Not sure what stack you are using but I was able to build something like this with next.js utilizing their api routes
For example Groupon and Facebook seem to use these.
Groupon <reply-fec4e341ec32311-125727_HTML-677829183-96988-0#e.groupon.com>
Reply to Comment <g+41wq2z1j00000000u2kx002eqs1u620s0037hlmwm4621up33#groups.facebook.com>
In the facebook example - it makes sense that I could be replying to a particular comment thread and this is a unique hash that lets me do so from within an e-mail.
As for the groupon example, I am not aware of the purpose.
If I had to guess, I'd say Groupon does it so they can tie replies/complaints to a specific campaign. They must send out many millions of mails a day, and probably have many hundreds of campaigns running at the same time. Being able to automatically link feedback to a campaign is probably a huge time saver, and provides useful KPI stats.
Jeff Lindsay, who coined the term 'webhook', said that the difference between webhook and http callback is that webhooks are user-defined. I think I understand what he meant, but I was thinking about it and I asked myself, can webhooks be effectively used by regular users (I mean: non-developers)?
Usually people don't have a clue how the internet works, they don't know what http is, terms like URL, callback, or request-response don't say anything to them. I've heard that many people do not know the difference between a web browser and a web site, they think that internet really starts at google.com and they type in all urls in the google search box... I mean, what's the use of webhooks when you're not a developer?
Do you think services like AlertGrid make sense? It's a webhook consumer that you can configure to dispatch alerts (SMS, phone, email) either when the callback is NOT received in x amount of time, or when the received data meets user-defined condition, plus it does some data visualization. We wanted it to make webhooks usable for non-developers. But still it requires an initial integration by someone who at least knows how to configure the source to send the webhook events. In many cases it only takes pasting an url to a textbox, but it seems to be beyond the skills of a typical user.
So, are the webhook doomed to be used by software developers only, or is there a chance that millions of Facebook or Twitter users will start making use of them somehow?
I think that something implemented using Webhooks can be made very user friendly.
Suppose Stack Exchange allowed users to define a webhook that would be notified whenever you earned a badge. You could supply a custom URL, or there could be simple buttons to click that would set it up for your Facebook or Twitter account. It could be as simple as the Facebook Like button.
YES I think this is a great idea. It's actually something I designed in my head a couple months ago and didn't think the product existed.
Webhooks are extremely powerful and having a 'service bus' aggregate/manage/dispatch these callbacks is extremely compelling to me.
I think that we are a long way from the general public consuming webhooks in any sort of meaningful way but I don't see why not. I remember when RSS was a 'developer' only technology.
Thanks for the link. I'll be digging in more this weekend.
If this question has already been asked, please comment so I can remove it.
I'm aware of the advantages of email verification, especially in regard to spamming (which could easily kill me since most of the functionality is in posting comments).
I'm contemplating the removal of email account verification for the application I'm currently building. This is for numerous reasons:
I've noticed other apps/websites
simply don't implement it.
It's far more user friendly then to
skew the user over to their email.
Since the application is moderate in scale and functionality, revisits are short-lived, some users may be inquisitive about it as to sign up, but some might feel it's an overkill to actually go through email verification.
App is not celebrated as to compel visitors to take effort, sign up and verify.
I know I'm getting into the gust of it, and while I'm writing this visitors could've verified their account for the gazillionth time; however, would you agree that for some moderately scaled applications an account verification might deter a casual visitor?
What measures do you personally prefer to undertake?
Why not use some form of federated ID like OpenID and such?
Verification is good if you plan to send email to them on a regular basis. Otherwise if it's just a casual site, you will probably need to offer something compelling to get them to register and provide you a valid email address.
Do you have something compelling?