I have set up a few twilio accounts like this where a business number blindly forwards to the business owner's personal cell, maybe some logic for business hours and holidays.
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.
Yes or they could have just blocked the messaged before it hit my system. They are the ones that originally allowed the message to get to me. Then when I process it, they suspend my account.
Perhaps your employee's cell carrier detected the message as spam and automatically complained to what it saw as the source (twillio). From twillio's point of view they absolutely and unequivocally need to keep the carriers happy. If Att or Vzw simply blocks all twillio then twillio is dead. When faced with the choice of losing the entire company or losing your $600 a month it's pretty obvious why twillio has in place the automated system you recently chafed under.
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'd be really curious to know if this is what happened. Whats more interesting is he lives in Spain and his cell phone is on a Spanish carrier.
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.
Yeah this sounds highly problematic. Maybe in the meantime you can text links to your own portal instead. I.e. "New SMS received from +123... . Read it at: https://your-internal-infrastructure.com/sms/[GUID]" (maybe with a simple login so Twilio auto-fetch, if any, gets a benign page). That way there is no spammer-controlled message content (apart from the phone #) in the message you send. Or convert them to jpeg and send as MMS hoping that Twilio won't OCR that :D
If someone has already written a custom integration, how hard can it be to wire it up to a spam detection API? It sounds like the integration was sending spam (not intentionally of course), which none the less is a TOS violation.
If they can’t update the integration with spam filtering, then it seems like they should be using COTS software.
Is sending an employee a message they've elected to receive ever spam in some sense? If the reflection were to an arbitrary number then I'd say so, but simply forwarding to a specific number you're working with seems... Fine. Maybe it's different too if it's a solution you're selling, but even then that's somewhat between you and the customer.
I guess if twilio has negative impacts as a result of the perceived spam then that's a separate issue.
I'm already using a spam detection API. But remember those things don't block all spam.
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.
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.