4 ms·

From someone who's done a fair amount of SMS sending here are some things to think about. - You'll need TCPA compliant opt-ins for US sending. There's a cottag

by twunde 5y ago

From someone who's done a fair amount of SMS sending here are some things to think about. - You'll need TCPA compliant opt-ins for US sending. There's a cottage industry of people who look for vendors that aren't compliant and sue them. The fines range from $500-1500 a SMS or call. Sounds like you've already gotten that covered, but definitely go over the requirements with a lawyer that specializes in it. - SMS is throttled per a phone number. This is throttled at both the provider and the carrier. That means that even if Twilio sends something at 10am it might not be sent by Verizon until 11am. This absolutely impacts off-hour SMS sending. - SMS is pricier than email and even at the highest volumes has a relatively high floor per a text. I think the floor might be $0.004X-$0.005. This is offset by having better response rates that email. And as others have mentioned the providers will give you better pricing as your volumes go up, but you'll need to talk to account reps about that. - At a certain size (1M+/month?), you can also consider integrating directly with the carriers, although that's a longer process to get set up. - You'll need to manage SMS bounce/spam rates like you would for email bounce spam rates. You'll end up maintaining a block list of known bad phone numbers Edited for formatting

ShrigmaMale 5y ago
Thanks. I understand limits these days are based on 10DLC trust? Do those throttling still apply even with staying under those limits? I think the floor is 0.0025 to 0.003 based on network access fees and depending on carrier. With margin I suppose yes I won't get much cheaper. If I scale to that level I will look at direct integration, thanks. Do I still need blacklist if I have double opt in and users can opt out? Requiring confirmation would remove the need for that?
- twunde 5y ago
  Yes, you'll still encounter throttling even with 10DLC trust, it will just be less. If I remember correctly 10DLC is supposed to have a send rate of 15 text message segments per a second, although you can get that bumped up after vetting. But for example if you try to send 250K SMS at 10:05 am EST, those messages will be queued up and will be received by clients at varying times. This is something you'll want to monitor. If I remember correctly Twilio (and presumably other vendors) will show the actual sent time, so you'll be able to compare when you triggered a send with the actual send date. Unfortunately I don't think you'll see when clients actually receive the SMS unless you've got a personal phone number on your send list that you use to monitor. There are also daily send limits, which again can be increased after vetting. From a software engineering perspective SMS sending is really a series of queues. Twilio has its own queue per a number and a queue per a carrier. Each carrier maintains their own sending queues. As such, you'll want to monitor SMS sending the same way you'd monitor a queue ie by measuring throughput, and number of items in the queue. Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. The companies I worked at, did tests and found that emojis didn't really impact response rates, although its worth testing your specific use-case. With the double opt in, you probably don't need a blacklist, although you may want one for customers that reply with expletives, etc (assuming you're supporting 2-way).
  - to11mtm 5y ago
    > Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive Technically it's more than just emojis, anything outside of GSM-7 [0] will result in fallback to UCS-2 and you get about half the number of characters per segment. FWIW Twilio does allow status callbacks so you can see that twilio sent the messaage and when(/if, sometimes they don't) carrier acknowledged delivery success/failure. [0] https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_alphabet_and_extension_table_of_3GPP_TS_23.038_.2F_GSM_03.38 https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_al...
  - toast0 5y ago
    > Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. This might happen, but it really shouldn't. Sending emoji as utf-16 surrogate pairs in a message marked as UCS-2 generally works, even if it's technically invalid. Of course, using UCS-2 means 70 symbols? max, instead of the 160 you get from a 7-bit GSM encoding (or 140 with an 8-bit encoding, if there's a useful one). Emoji that are one unicode code point will take up two symbols if they need to be sent as surrogage pairs, and if you use any of the combining character based emoji, that's going to use your message length budget real quick. Pushing you into multiple messages or MMS, both of which are expensive.
Teknoman117 5y ago
That throttling bit me hard last week. DHL's delivery message didn't come until hours after a package was delivered and by the time I got it the message the package was already stolen. Doesn't help that DHL didn't forward my delivery instructions to whatever third party last mile service they used (GSL US). Doesn't help that GSL didn't even make it to my address and dumped it behind the mailbox 2.5 miles from my house on a public road even though there is a secure drop box at the actual house address/location. Yesterday told me they'd pay out the claim, today they're fighting me over it. I guess it'll be another month before I can get another PineNote developer kit delivered to me (between CNY and international shipping). :( Jokes on whoever stole it. It's a paperweight unless you know what to do with it. A pawn shop wouldn't give them anything for it.
tylerrobinson 5y ago
> even if Twilio sends something at 10am it might not be sent by Verizon until 11am. This absolutely impacts off-hour SMS sending. Suppose my business is software for restaurants to notify customers their table is ready via text. How would I mitigate this?
- ShrigmaMale 5y ago
  Yeah same type problem here, notification is time sensitive and I haven't figured out how to make sure delivery is fast.
  - twunde 5y ago
    For time-sensitive SMS, one solution is to have basically a fast queue and a normal speed queue. Essentially have a phone number (or numbers) that are reserved for the fast SMS and only use it for time-sensitive requests like OTP. Everything else goes through a normal speed phone number. Alternatively, if all your SMS messages are time-sensitive, you'll likely want to use several phone numbers and try to load balance requests so that the queue size for each phone number is always small/at or near 0. There's also an outside chance that your SMS provider may have an option to pay for faster delivery like email providers do. I don't recall seeing that option, but I have to imagine that at least one provider has this.
- trcarney 5y ago
  Just browsing through AWS documentation, it looks like you can set the SMSType to Transactional for critical messages that support customer transactions. I'm not sure if other providers have this option but looking for an SMS Type you can set may be a good place to start. The link to where I found the information is below. They don't talk too much about it. They use the example of an OTP so that should work for your use case as well. https://docs.aws.amazon.com/sns/latest/dg/sms_publish-to-phone.html https://docs.aws.amazon.com/sns/latest/dg/sms_publish-to-pho...
- electroly 5y ago
  Make a mobile app so you can send push notifications to most customers instead. It seems like this is the way most businesses go, the massive proliferation of one-off apps on customer phones notwithstanding.
teeray 5y ago
This throttling burned me today. Capital One’s mandatory SMS 2FA didn’t deliver codes for 2-3 hours after they were requested. Needless to say I grabbed my AMEX instead. Repeat: SMS is a trash 2FA system
- toomuchtodo 5y ago
  I am always surprised when a financial services firm doesn't support 2FA using their app versus SMS, or support fallback to a voice call to a phone number registered to your account.

by twunde 5y ago

ShrigmaMale 5y ago

Thanks. I understand limits these days are based on 10DLC trust? Do those throttling still apply even with staying under those limits? I think the floor is 0.0025 to 0.003 based on network access fees and depending on carrier. With margin I suppose yes I won't get much cheaper. If I scale to that level I will look at direct integration, thanks. Do I still need blacklist if I have double opt in and users can opt out? Requiring confirmation would remove the need for that?

twunde 5y ago
Yes, you'll still encounter throttling even with 10DLC trust, it will just be less. If I remember correctly 10DLC is supposed to have a send rate of 15 text message segments per a second, although you can get that bumped up after vetting. But for example if you try to send 250K SMS at 10:05 am EST, those messages will be queued up and will be received by clients at varying times. This is something you'll want to monitor. If I remember correctly Twilio (and presumably other vendors) will show the actual sent time, so you'll be able to compare when you triggered a send with the actual send date. Unfortunately I don't think you'll see when clients actually receive the SMS unless you've got a personal phone number on your send list that you use to monitor. There are also daily send limits, which again can be increased after vetting. From a software engineering perspective SMS sending is really a series of queues. Twilio has its own queue per a number and a queue per a carrier. Each carrier maintains their own sending queues. As such, you'll want to monitor SMS sending the same way you'd monitor a queue ie by measuring throughput, and number of items in the queue. Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. The companies I worked at, did tests and found that emojis didn't really impact response rates, although its worth testing your specific use-case. With the double opt in, you probably don't need a blacklist, although you may want one for customers that reply with expletives, etc (assuming you're supporting 2-way).
- to11mtm 5y ago
  > Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive Technically it's more than just emojis, anything outside of GSM-7 [0] will result in fallback to UCS-2 and you get about half the number of characters per segment. FWIW Twilio does allow status callbacks so you can see that twilio sent the messaage and when(/if, sometimes they don't) carrier acknowledged delivery success/failure. [0] https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_alphabet_and_extension_table_of_3GPP_TS_23.038_.2F_GSM_03.38 https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_al...
- toast0 5y ago
  > Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. This might happen, but it really shouldn't. Sending emoji as utf-16 surrogate pairs in a message marked as UCS-2 generally works, even if it's technically invalid. Of course, using UCS-2 means 70 symbols? max, instead of the 160 you get from a 7-bit GSM encoding (or 140 with an 8-bit encoding, if there's a useful one). Emoji that are one unicode code point will take up two symbols if they need to be sent as surrogage pairs, and if you use any of the combining character based emoji, that's going to use your message length budget real quick. Pushing you into multiple messages or MMS, both of which are expensive.

Teknoman117 5y ago

That throttling bit me hard last week. DHL's delivery message didn't come until hours after a package was delivered and by the time I got it the message the package was already stolen. Doesn't help that DHL didn't forward my delivery instructions to whatever third party last mile service they used (GSL US). Doesn't help that GSL didn't even make it to my address and dumped it behind the mailbox 2.5 miles from my house on a public road even though there is a secure drop box at the actual house address/location. Yesterday told me they'd pay out the claim, today they're fighting me over it. I guess it'll be another month before I can get another PineNote developer kit delivered to me (between CNY and international shipping). :( Jokes on whoever stole it. It's a paperweight unless you know what to do with it. A pawn shop wouldn't give them anything for it.

tylerrobinson 5y ago

> even if Twilio sends something at 10am it might not be sent by Verizon until 11am. This absolutely impacts off-hour SMS sending. Suppose my business is software for restaurants to notify customers their table is ready via text. How would I mitigate this?

ShrigmaMale 5y ago
Yeah same type problem here, notification is time sensitive and I haven't figured out how to make sure delivery is fast.
- twunde 5y ago
  For time-sensitive SMS, one solution is to have basically a fast queue and a normal speed queue. Essentially have a phone number (or numbers) that are reserved for the fast SMS and only use it for time-sensitive requests like OTP. Everything else goes through a normal speed phone number. Alternatively, if all your SMS messages are time-sensitive, you'll likely want to use several phone numbers and try to load balance requests so that the queue size for each phone number is always small/at or near 0. There's also an outside chance that your SMS provider may have an option to pay for faster delivery like email providers do. I don't recall seeing that option, but I have to imagine that at least one provider has this.
trcarney 5y ago
Just browsing through AWS documentation, it looks like you can set the SMSType to Transactional for critical messages that support customer transactions. I'm not sure if other providers have this option but looking for an SMS Type you can set may be a good place to start. The link to where I found the information is below. They don't talk too much about it. They use the example of an OTP so that should work for your use case as well. https://docs.aws.amazon.com/sns/latest/dg/sms_publish-to-phone.html https://docs.aws.amazon.com/sns/latest/dg/sms_publish-to-pho...
electroly 5y ago
Make a mobile app so you can send push notifications to most customers instead. It seems like this is the way most businesses go, the massive proliferation of one-off apps on customer phones notwithstanding.

teeray 5y ago

This throttling burned me today. Capital One’s mandatory SMS 2FA didn’t deliver codes for 2-3 hours after they were requested. Needless to say I grabbed my AMEX instead. Repeat: SMS is a trash 2FA system

toomuchtodo 5y ago
I am always surprised when a financial services firm doesn't support 2FA using their app versus SMS, or support fallback to a voice call to a phone number registered to your account.