Ask HN: Twilio suspended account because someone sent us a fraud text
I'm curious to find out what other entrepreneurs think of this situation, where a partner, once trusted, and for which technical foundation has been built upon, now has shown to be acting in bad faith.
Every once in a while, some scammer will send a phishing text message to one of our phone numbers. Here is an example: """ Your Facebook account has been placed on hold for verification. To avoid account suspension, Please visit: https://opensopstat.com/ """
The message will be relayed to en employees cell phone as is what happens with all txt messages. Now Twilio thinks our account was hacked and someone is sending text phishing text messages from it.
The latest time this happened, the account was immediately suspended by an automated system. They did not communicate to us that this happened or why it happened. I had to fill out a support ticket and wait about 3 hours for a response before I even knew what the problem when was. This happened at night, so no one knew there was even a problem until the next morning when business operations resumed and the phones didn't work.
Its bad enough that they shut down the phone system for my entire company because of their mistake, but in order to get the system back online, I have to go through their ticketing process that is only through e-mail, where it takes hours or days to receive a response. If I want to speak with someone on the phone, which probably would have gotten the problem resolved more immediately, I have to pay $1,500 per month for their phone tech support. Obviously this is an unreasonable amount to pay. I don't need tech support, I just need someone to call, explain the situation to, and have them click a button.
We pay them about $600 a month and have been working with them for over 10 years. I understand their profit margins might be thin? But are they really that thin? And if so, there should be a more reasonable phone option. I don't need to speak with an engineer, I just need to speak with someone who can click a button and unblock the account.
Temporarily, I will re-program the system so that it does not forward text message content to my employees phone numbers. Which is fine. But my bigger problem is what do I do now? If they're willing to shut my system down without even giving me a number to call, what else are they going to do to me in the future?
The way in which they have been so cavalier with me is a red flag. And if I'm being honest, it does make me angry how they are willing to so readily damage my company in such a profound way AUTOMATICALLY without giving me a way to talk with them. I understand they may have a big phishing problem and will need to use automated software to help, but it is very reckless to not have this counter-balanced with a reasonable way for legitimate customers to even contact them after the suspension.
Are there other API-driven VOIP options that I should be considering bearing in mind that it would be expensive to re-write the software to work with another vendor? Or is there some way I should be looking to work things out with them?
What do you guys think?
206 comments
[ 3.2 ms ] story [ 235 ms ] threadI might be reading this wrong, but it sounds like you take inbound text messages to one number and then send outbound messages with the same content to employee phone numbers. Is that right? If so, that sounds like you're SENDING the spam messages in addition to receiving them. Regardless, it sounds like customer service needs to be improved, though.
I guess it's unlikely that one can make this consent clear to Twilio, though, and if the messages aren't distinguishable then they might still get seen and reported as spam by the employee, with all the bad reputation that can cause for all involved.
If twilio wants us to start filtering spam messages for these cases, they need to give us the API/tooling.
Or let us pre-register receiving numbers through an opt-in process.
I understand Twilio not wanting to be an open relay but the reported solution is not the way.
It's probably a good idea for twillio to be more reachable to any paying customer, at least until a human employee makes the determination if the customer is a spammer.
I also understand and agree with your argument about why they might have done what they did. But I still needed to counter with what I did in order to protect my business.
If they can’t update the integration with spam filtering, then it seems like they should be using COTS software.
Also, there are other ways to solve this specific problem given that they are intent on auto-suspending my account in this type of context. I could relay the messages using a different platform as an example.
Thats not really the point though. Me not paying for the spam API or not using it when I relay messages internally to employees is not a good reason to shut my whole business down and not give me a way to contact them. This should be obvious.
I guess if twilio has negative impacts as a result of the perceived spam then that's a separate issue.
On Slack, we have a paid account at the standard level, we've had that for years.
One note, both Google and Apple detect that our number is Twilio, and won't let us use it for 2FA, sadly (our original use case).
The business case of relaying inbound text messages to an employee's phone number should be a very common one and should not warrant an account suspension.
1) Spammer sends spam to customer's Twilio number. 2) Customer has this number set up to forward incoming texts to employees. 3) Customer has no available API to detect whether texts are spam. 4) Twilio apparently can detect that this message is spam, but rather than simply dropping it at step 1, they're blaming the customer.
Sorry, there is no scenario under which this is the customer's fault.
As opposed to just shutting down the customer because TWILIO forwarded the spam, that we already know that it can detect?
They're sending spam when the customer asks.
They're also deciding that that customer is a customer no longer because of the choices that customer made with regards to sending spam, not receiving spam.
These are pretty different things.
That doesn't excuse poor support, and the lack of resolution, but it changes a lot of the assumed processes.
It's an incredibly common use case to forward text messages from one incoming line to another number that is controlled by your company, and it's impossible to tell at the point of receipt (when it's still in Twilio's network) whether it's spam or not before forwarding it on.
It's the same exact thing that you might do if you have a support@example.com email address; it probably sends incoming emails to a number of different inboxes, even if those incoming emails are spam (and even if there actually is a spam system in place that might block some percentage of incoming messages, and Twilio doesn't even provide that.)
Why not open that capability to an API so that somebody who is operating some sort of forwarding service to run spam detection before forwarding?
And like you say, they do need to prevent their system being used for sending spam. But if they're not going to provide a way for honest parties to avoid sending spam, they need to be reasonable about how they react to spam reports.
I would think sending spam would be more if we allowed people to sign up for a our service and then people used it to send spam.
But these are all internal communications.
They already detect outgoing spam. Good customer service in this case would be to detect that a customer is attempting to send spam and blocking it and potentially notifying them about it.
Sending one and the system might not have detected the spam. It's not visiting the link. But send many at once the system gets curious.
That OP mentioning "reprogramming the system so it doesn't forward messages" makes me think that they are receiving the incoming messages programmatically via webhook and then using Twilio API to send a new message with same text to new number (their employee).
In such a case, they do have a point in the process where they can implement some kind of filtering or processing (maybe stripping or obfuscating URLs?)
No, no it is not. These are legitimate consentual messages, regardless of the content. Please stop applying mechanical interpretations of obtuse rules and pretending it's some profound wisdom. Twilio and the rest of Big Tech are already doing this enough, thank you.
Ultimately I think this problem is the end game of companies finding ways to absolve themselves of any liability through contracts of adhesion. When there is no downside to harming 1% of your customers besides losing 1% of revenue, biasing for egregious false positives makes financial sense. Same thing with terrible customer service policies crafted around keeping costs down, that prevent easily correcting these terrible automated decisions. About the only thing one can do is signal boost so others stay the fuck away from services built on broken assumptions, hopefully turning that 1% into maybe 10% where it starts to hurt them and they're once again encouraged to do competent system design.
What you might mean is that the carrier's draconian probabilistic anti-spam system incorrectly categorizes them as spam. And that this causes a practical problem for Twilio, which lacks any recourse against said carrier's incorrect classification. In other words, a similar problem to what OP is complaining about, one hop away.
You're doing nobody any favors by elevating technical details out of their narrow context and stating them as an unassailable description of high level behavior.
We're discussing a higher level behavior and what ought to be. And getting a critical service pulled out from under you based on overzealous unaccountable spam filtering is certainly not what ought to be.
Do we know this? I don't think OP has clarified - they just said it goes to an "employee's phone number", which makes me assume it goes out to their personal phone number which is probably not on Twilio. If that's the case I'm wondering if Twilio received some kind of complaint from the employee's carrier that they forwarded the message too, rather than detected it themselves.
I'm very curious. Is this a communication mistake? Like do you think I'm some big company that forwards text messages to random people?
Do you understand these are text messages being sent to one of like 3 employees at my small company? We are not generating outbound content or allowing anyone else to do so. Your question about GDPR requests makes me think maybe you have misunderstood the context.
If you have correctly understood the context, do you actually think I should have some kind of AI algorithm scanning these messages for Phishing?
I'm not sure I understand what your are suggesting or how you would have solved this problem? You would have just turned off the text message forwarding I guess?
Is that how you solve problems? You see a problem, then you destroy the thing that caused the problem, so problem solved? What do you do for a living with that type of cognitive approach? Are you an entrepreneur? Do you really run a business with that attitude? Are you en engineer? If so, when you are asked to make something work, do you just tell your boss "no" if you run into a problem that requires a creative solution? Are you a lawyer? Is your job to tell people what thing they cannot do, but not to help people do new things? That would kind of make sense...
Says the guy hung up on terms of service
> assuming
Says the guy accusing OP of malice
> irritable
Says the guy lashing-out
A+ projection all around. No notes.
The bit that you are missing is that this sort of thing is between Twilio and Twilio's carrier partners (sometimes mediated by third-party aggregators), and has nothing to do with you or your particular use case. Carriers have very low tolerance for third parties like Twilio sending spam to their customers. If carriers get pissed off at Twilio, they'll stop delivering messages coming from Twilio (or will impose other restrictions, like low rate limits, or perhaps charge more, etc.). Good carrier relationships keep Twilio running; bad carrier relationships cause all sorts of problems for Twilio and Twilio's customers.
The carriers do not know or care that the spam/fraud message you tried to send to your employee was just you forwarding along a message that some other random person sent to the Twilio number. All they would care about is that a spam/fraud message came from Twilio's platform.
Having said that, I too am disappointed in the policy of auto-suspension, and in how long it took for you to get the problem resolved, and that phone support is expensive to come by.. I think the right approach is to catch these things at send time and just refuse to send them. Sure, if some very high percentage of traffic is all spam, maybe an auto-suspension might be warranted, but I assume (hope) that's not the case for your account.
(Disclosure: I work at Twilio, though not on the messaging platform. My words & opinion here are my own, and don't reflect Twilio's stance on anything. Throwaway for obvious reasons; Twilio doesn't allow the rank-and-file to speak publicly about this sort of thing.)
They just need a phone number. I actually called sales hoping I could plead my case and get them to connect me with someone. But I couldn't get connected with sales. If this was due to omicron and sales would have helped me, then this is truly an edge case.
However, obviously allowing such sms forwarding have to be done with care.
I could be wrong, but I think they have a way for me to register my cell number so I could "spoof" messages sent from it. But I would first have to prove to them that I own the number.
This does seem like a very common use case that Twilio needs to not punish.
Same principal with money transfer. If you start accepting money from someone to transfer to another person that is MUCH MUCH higher risk - every bank / online payment player should be looking out for that and probably getting you into a different account type.
Twilio is clear, they are designed for systems where you message folks.
This is specifically covered in their ToS by the way.
"We never allow some types of content on our platform, even if our customers get consent from recipients for that content."
This is for the simple reason that a lot of folks are using Twilio for application to person / transaction messaging - and the key to delivery quality is to have no crap content going out.
If you operate an open relay for email - your IP address is going to be blacklisted very quickly. Same here, if twilio allows spam and fishing to go out, deliverability is going to go way down. Down the chain people don't know folks have "opted in" to the facebook phishing emails.
Sign up here for a code to win XXX. Then they send you the code (which is the twilio opt in code) and bam, you are in the spam list. All these things have happened on the email and other platforms side already.
This doesn't sound like an open relay (since the incoming message can't be forwarded to arbitrary destinations), this sounds like a mailing list. And if my mailing list was banned because someone else sent spam to it, I'd be upset too.
I'm more surprised that folks don't get that.
Twilio is clear. You are responsible for all messages you send using their platform. They are clear in their terms that this applies EVEN IF you allow others to use your service in ways that result in crap going out.
They DO NOT want spam or phishing messages going out from their numbers.
Everyone here saying this is "bad design", outrageous or whatever has not had to deal with spammers / scammers. This simple rule, you are responsible, full stop, for what you send using our API's, and if you send crap, we will suspend you - probably saves them from 90% of the abuse issues they would otherwise deal with.
Downstream, T-mobile, verizon etc - they don't care that the message was "consented" to by someones supposed "employees". When their customer reports spam coming from one of these numbers and if that number is verified -> game over for twilio
The whole point of an open mail relay is the 3rd party can send their crap through your servers to anyone they want to target. This scenario gives the spammer no control over who gets the message.
Twilio is being used as a message bus, and OP is simply trying to save the work of writing an app or a new UI on the employee’s phone to read a list of messages. It’s a pretty common use case.
To the degree twilio's business model depends on allowing its customers to send to whomever they want (which I assert it does), they CAN NOT let those customers send spam - full stop - end of discussion. If you don't understand why this is critical to twilio - I don't know what to say. MOST users do not want SMS spam.
Seriously, if you need to send SMS spam, use one of the "bulletproof" SMS spam players.
Even if we say customer is not a spammer, they are sending mail out to a wide variety of third party networks. In email land a closed SMTP server only forwards messages to an internal network or server under that admins control. As soon as you start blasting spam out to third party systems you are not a closed relay. That's literally how the verizon and other carrier systems will see this source of SMS spam and phishing.
The point about the reputation of IP or carrier / telephony origintion numbers / space remains. The use case here is prohibited by twilio's terms of service. Maybe just comply with those or find another provider.
And I don't need to send sms spam. If it was blocked on the way out, that'd be fine.
A lot of HN has turned into - X company MUST build me Y feature so I can do Z. Actually, if you read the docs, they provide clear guidance not to do Z (for whatever their reasons are). They have the same issues with reputation that someone running a mail server sending mail to users across multiple networks and third party email systems might have.
Twilio outbounds the SMS message over the carrier network. Part of that relationship is that Twilio has to prevent spam from entering the carrier network, or the carriers will ban the interconnect.
Here's the full workflow of this situation.
The inbound leg looks like this.
[Spammer] -SMS-> [Carrier] -SMS-> [Twilio] -HTTP-> [Customer]
The outbound leg looks like this (the customer initiates this in response to the HTTP request)
[Customer] -HTTP/TWIML-> [Twilio] -SMS (SPAM DETECTION HERE)-> [Carrier] -SMS-> [Employee]
All of these parties are separate entities, each enforcing spam blocking. Twilio is incentivized to not transit spam over the Carrier because the Carrier will get upset at Twilio. Twilio has no way to tell the Carrier "Oh, hey, this is spam, but the customer owns the number and they said they were cool with getting spam, please don't get angry"
Spam detection is not perfect. Users may want to process their own messages unmolested inbound.
Sorry, this is just bad design.
Re: > The customer may want to handle / filter the spam.
Then provide the customer with a "yes, send me all the spam" option.
Which do you suppose is the common case here?
1) Customer doesn't want spam.
2) Customer is doing a "study of spam"
3) Customer is running a spam filtering service.
Yeah, it's 1), dude, in a gigantic majority of the cases.
Fine to provide an option to filter it perhaps, requiring twilio to block what it THINKS is spam is a recipe for disaster, spam filters are no where near perfect.
Yet they are disabling the entire account when they think it has sent spam.
So many other options here
a) understand the market twilio is trying to serve
b) been in this market.
This guy probably is not checking is error codes. Twilio will always give you 30007 in these cases.
https://support.twilio.com/hc/en-us/articles/360008704834-Er...
Almost certainly this guy failed to follow their messaging guidelines. If you send (or forward) spam that includes links to third party websites or URL shorteners THEY TELL YOU that may trigger spam / blocking behavior.
And yes, this needs to be a zero tolerance game - with spammers the reasonable limits turn into 100 accounts being setup by folks in india for someone for 20 cents an account.
At least in use cases I was dealing with - we wanted zero filtering of inbound SMS because it was used as a control interface.
Spam didn't matter to us. Spammers had no idea how to format their messages etc. We also whitelisted inbound numbers.
The Twilio use case is not primarily for "mailing lists" and third party sms forwarding stuff.
And for a while SMS worked very well in certain IoT's contexts (SMS used to basically have its own channel that had surprisingly good deliverability for some reason).
Internationally in particular voice and data used to be potentially wildly expensive.
For sat backhaul, you could get 10 to 25 cents a message. A voice minute would be like $5 - $10. So this is a 100x difference potentially. Even data minutes were like $1-5/minute way back. The connection setup and teardown times were lower with SMS then doing a voice channel call etc. Pricing looks a lot better now, but still, messages are cheap (or free).
https://www.satphonestore.com/airtime/iridium-airtime.html
How does twilio even know that you will only forward messages they have scanned for spam? It seems like they MUST put the spam filter on the outbound leg.
I don't think anyone is arguing that Twilio was wrong to detect the message as spam. It's more that an unexpected side-effect of the customer's current implementation had outsized consequences. Similar unexpected friction with Twilio's anti-spam mechanisms are likely to occur again and they will cause outsized damage to this legitimate business or others if Twilio doesn't change their strategy.
This is a bizarre and almost intentionally obtuse interpretation of the ops problem (albeit literally correct).
If I have built an auto-forward between two endpoints that I control (or at least have permission or authority over) I am not a bad actor in any capacity.
A much more appropriate workflow here would be for Twilio to cross-check this "spam" with inbound spam into twilio itself for some other number his account controls.
Which is to say, if a Twilio account originates a suspect message, first check to see that suspect message was sent, inbound, to it before auto-DoSing an entire business. This shouldn't be too tough, especially since these events probably occur in step with each other.
I should have clarified that this is from Twilio's perspective. They don't know that the recipients actually want to receive these messages, which makes them (by definition) not actual spam.
I agree, though there are a few reasons why Twilio is sensitive to this.
I have almost a decade of experience in working with SMS and building apps for messaging, forwarding etc. In my case, I connected directly with SMS aggregators (who are the entities that actually connect carriers to each other), which is what Twilio does as well, so I've had to deal with many aspects of operating directly in this ecosystem.
For these messages that are being forwarded to other phone numbers, the messages are likely going through Twilio and out to the SMS network and physical carriers. I'm inferring this based on OPs comments which makes it sound like the forwarded messages are going to personal cell phone numbers. Even if there was a way to let Twilio know that those people want to receive those messages, there isn't a way to get the carriers on board with this.
In the US at least, the physical carriers have been standoffish with the virtual carriers like Twilio et. I have close to 10 years building similar things and in a company that connects directly to SMS aggregators just like Twilio does.
It's worth noting that long codes (i.e. traditional phone numbers) and short codes have entirely different cost structures. Since carriers get paid for messages on the latter, that's where they want automated messaging to originate. Since Twilio and others offer automation of long code messaging, they have to be very careful not to look like spam generation or consistently have too large an imbalance (i.e. one number generating far more messages than received). Carriers can and will block numbers (i.e. all SMS traffic from your number will be dropped) and, from my experience, they do it silently and with little recourse.
https://zulip.com/
I also have a #critical channel anything can post to that always has alerts enabled on my phone so I don't miss anything important.
It actually works pretty well and costs nothing.
By their own policy, Twilio's upstream should ban them for "forwarding spam".
I'm guessing they would not be happy if that policy were applied.
Very often people say things that I know are incorrect and actually sound quite stupid, but then I am unable to articulate why. I was very surprised at the number of incorrect negative responses from people to this post, who seemed to grab onto details and then use them to twist reality.
How did you learn to dissect these arguments and then clearly refute them?
Also, I have never heard "distinction without difference" before, but it is a common way that people twist reality. Did you study logical fallacies? Or read a good book on how to deal with them?
https://gdpr-info.eu/art-22-gdpr/
> The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.
Quote this and maybe it will get you escalated, but who knows? A lot of companies seem to just ignore GDPR entirely.
If you send abusive texts through Twilio, Twilio could lose it's contracts with carriers. I haven't read through the paperwork Twilio makes you sign, but I'm gonna guess the fact that this could happen is in there. Also it sounds like the account wasn't banned, it's ability to send messages was suspended. Because it was being used to send spam text messages. I'm pretty thankful Twilio has automated systems for that
I agree with the other comments that relaying phishing to internal users is probably what they dislike. There, of course, isn't a good solution beyond using some open platform. Your self-hosted IRC server isn't going to cancel your account because someone sent a phishing link, for example. But, nobody will know how to connect to it anyway. Sigh!
The thing is, I actually had this when I first started with them. They were so small at the time, that I had one of the founders on the phone once and he told me all about how he studied cloud computing at MIT. But this was over 10 years ago. After that, they had phone support for a long time.
Last few years they changed over to this way where there is no path to resolving a problem like this, which should be easy to solve, in an appropriate amount of time.
HN crowd looks down on sales reps. But a good sales rep will 1) understand your business 2) will look for ways to match your needs to solutions they offer 3) will be your point of contact when things go wrong.
Sales reps are human beings, treat them well, thank them for their time if you don't buy the fancy/expensive enterprise plan.They'll understand. Most reps are young college grads that are building a network for life.
You could be a solo SaaS creator and cheap because it is a side gig and your don't have the money. But still make an effort to nurture those little young reps. One day they'll make the phone call to somebody that will remove that account suspension. That will save your business.
Amazon EC2 is not.
Also Google treats businesses like this if they have profiles on their maps. A business might rely on their google maps profile for 100k+ in revenue, but they can't get someone from google on the phone to help deal with it. I had someone steal my google maps listing from me and they got away with it because google would not connect with me about it. It was horrible and it was wrong.
For a "few" dollars a month, maybe not.
But here the OP said it was around $600/month, so that's a fairly substantial chunk of ongoing spend, just to have zero way to contact someone on the phone on a showstopper problem that needs fixing ASAP.
Contrast with more traditional businesses like PG&E or Comcast. Both hated companies for reasons, but even so they are heads and shoulders above these cloud provider companies (google/twilio/etc) in terms of customer support.
I spend way less than $600 with each (around $100 for my small office) and yet I can immediately reach a human on the phone if there's any problem with my electric or internet service.
Although this particular thing may have happened because they got backed into a corner by the carriers. They might have been forced to scramble and suspend a bunch of accounts in order to protect themselves from being suspended. It's possible this might not have been a gambit to save money, but something they were almost forced to do without time to properly prepare. I'm just speculating, guessing.
Many of us use twilio and an account suspension is an undesirable scenario.
“Forward unless spam/problematic” would be very nice.
I can confirm that my system did forward the message without any modifications at all. (my employee knew what it was because he knows all text messages from that number are forwards)
These are all internal messages. Someone cannot use our system to text random people. It's literally one person seeing them. We're a local service company. We're not SAAS or something like that. It's just people messaging us "Hey can you guys come Thursday?"
This would be like if you signed up for a VOIP provider for your business phones and they suspended your account because someone sent you a phishing text message.
From the employee's carrier perspective those are external messages originating from you.
All that Verizon/T-Mobile/at&t see is spam coming from you, they don't know about the employer/employee relation. So when those carries complain to your carrier, your carrier has little options but to lock you.
I would understand if this was an edge case, but my understanding is this is a quite common and a core use case. I'm pretty sure this exact use case is in their basic tutorial.
If there is any possibility that those messages could be interpreted as spam, that doesn't seem to be a valid use case for Twilio (any more). You could forward the message over some channel other than SMS to the employee (like email, or a custom solution).
Also, I was looking into the pricing a few months ago and its kind of expensive because I'm actually paying for two text messages: One for the incoming one, and one for the forwarded one.
The code has been working this way since maybe 2015, possibly before (its been so long, I can't remember). I've been using Twilio since I think 2010. I started out just doing call forwarding and later on added text messaging when customers started to expect to be able to text message us.
At the time, it was a core use case. There was a tutorial and everything "Forward text messages to your phone in a few lines of code".
It's getting pretty rediculous
But seriously, it can't take a thread on HN to get a way to get support for a paying customer. There needs to be an 800 number they can call which is staffed with humans empowered to fix problems.
While I have no connection to this thread, I am also using Twilio in production and finding out here that if we ever have a problem there will be nobody answering the phone makes me reconsider what we should be doing to keep our business uptime.
What you are describing is tech support.
No that is customer support - big difference.
Well, maybe next time you get somebody that implements a standard.
With that kind of behavior (not letting you speak to anybody, the blocking is understandable), it's clear you shouldn't keep their services. So, you have now an opportunity to do it right, and make the next move cheaper.
But then, if they were only sending texts, migrating wouldn't be expensive.
There isn't really a standard for the interactive voice processing, SIP is a standard, but it's not quite simple to use it compared to Twilio or similar APIs.
However, most of the providers in this space have fairly simple APIs, so it's like 30 minutes of work to do the integration, maybe a little more if you're also receiving SMS or if URLs are particularly hard to use in your language of choice; if you're adding yet another SMPP vendor, that's faster, if you're adding yet another GSMA SOAP vendor, it's probably longer because you'll have to figure out why your XML doesn't work even though it should. Plus whatever it takes to get the account setup. Plus however long to build a way to choose from multiple providers (this part may be a lot of work!), and however long you want to run with limited traffic to see if the new provider does better/worse/same as the old provider.
Unfortunate outcome though. Automated banning is always frustrating.
Slack is probably a good idea.
Of course we have an internal database and he can look at text messages through our web application too. But these are not push notifications to his phone.
0 - The handler doesn't send out via Pushover any message that contains words we're unlikely to use; Facebook is one, for example. If a message isn't forwarded via push notification, it is emailed to the sysadmin list for one of us to manually look at during daytime hours.
I like the Apple Watch integration as I can interact with urgent notifications just on my watch without my phone handy.
If the first Twilio should fix this bug in their system, if the second then they should maybe have some process of setting up employee phone numbers in their system so the shut down process does not happen. At any rate both scenarios should be common enough that they should have a process to handle that.
Support with them is significantly better but if I remember correctly pricing is around $1k/mo minimum (which was more than worth it in our case).
Best of luck to you.
DISCLAIMER: I do work for TWLO, but on a completely unrelated division. My opinion and this message does not represent my employer in anyway. I'm just shooting the breeze here.
It's like if you had a restaurant and you wanted to use Twilio. You might forward text messages sent to the restaurant number hosted on Twilio to your personal cell phone number.
The retail wireless carriers are really driving a lot of this with recent 10DLC A2P changes. In particular, T-Mobile is waving around threats of $10k fines per message for messages they deem to be in violation of their content rules. (Which obviously prohibit fraud and such, but also somewhat-arbitrarily anything relating to marijuana.) The way it's written T-Mobile will fine Twilio, who is supposed to pass it on, but knows they'll struggle to collect that.
Meanwhile, on my personal cell phone AT&T can't even seem to figure out that when they get a message from a Nexmo number that starts with "ATT Free Msg" that they didn't send, maybe they shouldn't deliver it. As a consumer I'm glad someone is trying to squash these scams, but they're breaking more than a few eggs in the process.
I'd echo the advice to get off the SMS channel for notifications if at all possible, unless you're sending enough and spending enough to have named support contacts. The rules are being written for people sending thousands of messages per day. We serve small businesses who send maybe 100 messages per month, and it's been a mess trying to get carriers to recognize that these businesses exist and need a solution that works for them too.
"You package (#US853121) containing the following products: 1. iPhone 13. Cannot be delivered until outstanding duties have been paid. Current outstanding balance: $1.68. More info <sketchiest website ever>"
I get about 20 of these a day. I've lodged multiple complaints. Like, why can't AT&T solve this problem that AOL solved in 1994?
As another small biz, I've had very good experience with Phone.com over the past several years. Prompt and solid tech support the few times I need it (mostly for configuration and 'is there a way to do this peculiar thing?' questions), and mostly just works.
Otherwise, you are contributing to a pattern where HN becomes de facto Tier 1 Customer Service, similar to how Twitter was a few years ago. This is already the case for various Google services [1], but I would hope that we don't want to normalize it for every service.
----------------------------------------
[1] A familiar pattern to most of us – Ask HN: Google suspended my account without warning; Googler escalates internally; problem is solved
I posted to HackerNews because I suspected my issue would be seen and taken seriously if I did that. I could tell the ticketing system people were overlooked and only looking at my issue in a very shallow way.
If this had not worked, I would have started using my Stack-overflow account then Reddit. If that didn't work, I found an address of a lady how works for Twilio nearby, I was going to go knock on her door and see if she could put me in touch with someone.
Luckily I was able to get the problem resolved without those additional steps.
I would like to point out that Twilio's ticketing system works well for complex problems that are not time-sensitive. I had an issue a few months back that I think was probably quite complicated involving bureaucracy and multiple carriers and it was resolved in a few days via their ticketing system which was very cool.
IMO now that Twilio is a public company, they should be investing in better customer service. I am simply encouraging them to solve the actual problem in addition to unblocking you; hence the "also commit to...", not "instead commit to..."
I hope my comment is not used as justification to not solve your problem. That would be the very last thing I want.
Thanks for taking the time to respond. The fact that you responded to this message at all resolves my initial concern, which had more to do with if I needed to change providers because of a cultural shift within your company. I understand that you are dealing with a very large and complex system that is changing quickly and will have problems, sometimes serious problems sometimes. Customer communication specifically is a very difficult and complex problem to solve at scale.
I actually spoke with one of the founders of Twilio when I first signed up. Evan maybe? He told me about how he studied cloud computing at MIT. This was a very long time ago.
Gregg was able to get the problem resolved within about 30 minutes once I reached out to him. He also provided me with a few solutions to prevent the problem in the future.
I understand the complicated problem that that led to this mistake and I think it is reasonable to make mistakes like this sometimes, especially if you're providers are threatening to suspend you.
The main problem that I would like you to solve is the lack of phone number. There needs to be a way for people to contact the company if there is an account administration emergency like this. Even chat would have been fine.
That being said, I did call sales and could not reach someone. If this is due to covid omicron and if normally I had called sales and would have been able to plead my case and gotten them to connect me with someone, I think that would have been fine and this truly is an edge case.