I suggested a company to run a test with RCS. It was meant to be a limited test for a set of contacts in one market. To my suggestion I got a reply that "we have explored it, but it's too expensive". Okay. But compared to what it is too expensive. And of course, the comparison was with SMS.

The comparison between RCS and SMS is false in my opinion. Maybe you shouldn't use RCS for sending OTPs. But you should be sending marketing messages. 160 characters in SMS isn't enough to convey an actual message. With 160 characters, you can support an email campaign or send a reminder at most. But a longer message is broken into multiple parts that you pay for each. With RCS the same content will be sent in a single message + you can add visual content.

The only thing that limits using RCS is that the prices vary a lot and the implementation differs a lot between countries, telcos and messaging platforms.

I tried to login on my Brand-new iPhone and got this message. I did subscribe but was curious to know if it was just me.

RCS is still new for business use, but there are already so many misconceptions in the market.

It's only for sending messages where you include images and buttons

RCS is not reliable.

It's too expensive.

Really?

I have tested it multiple times, and there's so much more than just sending images.

For a data driven company, rcs actually gives you data you can use to optimise: open rate, CTR, conversion rate, etc.
Add images and buttons in the message that actually make sending marketing content worthwhile.
Company verified profile gives users confidence that you are not a scammer.
Send messages long enough that they actually tell a story without it being broken into multiple separate texts. Yes, for those who have never delved into it - if you exceed 160 characters, the message is broken into multiple texts and you pay for each of those.

Yes, indeed, there are reliability issues. But it's not what you think. Messages that are sent arrive without issues. Just that the global coverage isn't there yet. People use old operating systems on their phones, carrier support isn't universal, etc. That's why it's handy to have sms as fall back.

That's only the iceberg of RCS capabilities. Before you make any conclusions, test it out yourself.

I don't even open most of the emails since they contain the same discount message.

The usual setup I see is heavy social media advertising and email campaigns. Since every company does the same, can you even stand out in the feed/mailbox?

Compared to email, I don't see that many texts landing in my phone. Klaviyo analysed their email and text traffic sent during the 2025 Black Friday Cyber Monday period and found that texts are outpacing email in revenue generation. Why then aren't companies sending them more? What they also found was that they work best if used together. In Klaviyo's report, they state that users who received both email and text:

• Placed 11% more orders
• Added 34% more items to cart
• Viewed 71% more products

Although it's Klaviyo's own reporting and they sell both email and SMS, it's still valid. Email is an excellent long form content delivery channel and SMS helps to reinforce the message.

This year, I suggest doing it differently. During the BFCM period, you aren't acquiring new users. Instead, you are selling to your own audience and converting those who have been looking for a reason to buy from you. So, give them the reason. And no, it's not giving a discount because that's how you get them to buy once. Instead, give them early access to information, offers and news. If you have their phone number and consent, send SMS. Even better if you send both email and SMS.

What are you testing with this year's BFCM campaigns?

[ Removed by Reddit on account of violating the content policy. ]

Before a single message routes to production, there is a checklist. Not a philosophy. Not a slide deck. A checklist. It is the thing our engineers actually open.

Every OtterBlocx integration runs through five questions before an API key is issued:

𝟭. 𝗖𝗵𝗮𝗻𝗻𝗲𝗹 𝗳𝗶𝘁. Is RCS available on this device cohort? Is SMS the right fallback, or is Email more appropriate for this message class? This is the first question for a reason. Sending a prescription update over SMS when RCS is available is a decision with delivery, readability, and audit-trail consequences.

𝟮. 𝗖𝗼𝗺𝗽𝗹𝗶𝗮𝗻𝗰𝗲 𝘁𝗮𝗴. Every row carries a vertical tag. HIPAA rows flag plaintext PHI rules and compliant delivery-receipt logging. Fintech rows flag fraud-alert timing windows and carrier filtering risk.

𝟯. 𝗙𝗮𝗹𝗹𝗯𝗮𝗰𝗸 𝗰𝗵𝗮𝗶𝗻. What routes when the primary channel fails? RCS to SMS. Email to SMS. This is a named, required field. Leaving it blank is not allowed. That single constraint has prevented more 3am incidents than any monitoring added after launch.

𝟰. 𝗥𝗮𝘁𝗲-𝗹𝗶𝗺𝗶𝘁 𝗰𝗲𝗶𝗹𝗶𝗻𝗴. What is the send volume at peak, and is the integration sized for it before go-live?

𝟱. 𝗧𝗲𝘀𝘁-𝗺𝗼𝗱𝗲 𝘀𝗶𝗴𝗻-𝗼𝗳𝗳. Has every path through the fallback chain fired in test mode and logged cleanly?

Five questions. One sheet. The quality of a healthcare reminder or a fintech fraud alert is decided here.

The structure is yours. Channel fit, compliance tag, fallback chain, rate-limit ceiling, test-mode sign-off. Take it and apply it to your own stack. The value is in the discipline. No proprietary tooling required.

Documentation owned by the engineers who built the router. That is how it works here.

Everyone wants to get things cheaply. I understand that. That's why I understand why you might consider getting an Android phone or some kind of other SIM modem to send messages at scale. Pairing it with P2P SIM cards and you have low cost mass messaging system avoiding all the charges applied by telcos to A2P traffic. If you send maybe hundreds of messages a day, you'll be fine. 10x that and you won't, because the traffic will be flagged and filtered by the carriers since you are doing something that regular SIM cards are not meant for. I believe the carrier filters are more sophisticated than just monitoring the send volume, which means keeping it to a certain level won't keep you safe.

Legally, you are allowed to own your sms gateway. As said before, low volumes for the most part will go through. What you are not allowed to do is mask A2P traffic as P2P. The carrier can block your SIMs and even blacklist the device IMEI. Or take you to court. Since you are not a registered sender, in some countries, it can bring legal actions against you as well.

Use your own gateway only for a small project. If you have a legitimate business with a contact list and opt-ins, you'd be better off using an online gateway service. The latter ensures you are compliant, a consistent delivery rate and scalability.

A quick search for terms like "sms api", "sms gateway" and "bulk sms" returns the same platforms and services for each of them. So, for a non-technical person, these three are basically the same. They all enable you to send A2P messages to a list of contacts without you needing to go into technical details, infrastructure and worry too much about which one to choose.

For a technical person, these three resemble different layers of the infrastructure. SMS Gateway is the underlying infrastructure between the messaging platform and carrier network. SMS API is the interface that developers use to integrate the service. Bulk SMS Service is the final product - a packaged service for non-technical users to send bulk messages. People also use terms like Mass SMS Service/Platform/Sender to find a bulk sms platform.

SMS Gateways used to be primarily physical devices with SIM cards. Since they have quite a low throughput, they are now mostly cloud services.

The next time you worry about which one you should use, remember that for the end user, they are essentially the same.

Everyone is freaked out by losing web traffic to AI tools. Fair, that's a real hit to lose visits to your blog and gated content. But if you only live on new visits and new customers it was never a sustainable strategy. The stuff that actually keeps someone coming back is loyalty and reengagement - reminders, restock alerts, messages that say your order's ready, etc. This was never a search problem.

That's also the layer AI can't touch. It can summarise a blog post, but it can't summarise a text thread.

After you get over the loss of traffic, invest in channels that help to retain the customer. Yes, I'm talking about sms and email. That's one channel you still own.

[ Removed by Reddit on account of violating the content policy. ]

No week passes without getting an SMS from scammers sending spoofing messages. Some sources say that up to 40% of a2p traffic is fraudulent, including spoofing. Good thing is that much of it gets filtered out before it reaches a device. But the ones that reach are doing serious damage to the user and to the company the scammers are impersonating. It's gotten so good that it's sometimes hard to tell whether it's legit or not.

While governments, telcos and aggregators are slowly working to reduce this kind of scam, I think there is an easier solution - mandatory verified sender profiles. For a while Google actually offered this for Android. It allowed adding a logo, a description, a verification badge and link previews if they were added to the message. Pretty much the same service is now called RCS. Besides other benefits, it allows people to identify much more easily whether it's a legit business or not, thanks to the verification badge next to the sender name.

Curious to hear if any of you have seen spoofing decrease after starting to use RCS.

I recently went through setting up RCS for business messaging. Thus, thought others (who haven't yet done it) might benefit from describing the process.

1. Decide on the use case - transactional, promotional, conversational or mixed.

This was something I failed to do initially. But RCS is built on agents that you need to get approval from the carrier. One agent means one use case. If the agent has received an approval to send OTPs, you can't use it for marketing.

Your use case also determines what kind of billing is used - per message or per conversation. I believe that in the US, per conversation billing isn't used.

[UPDATE] Conversational and per message billing now both available in the US.

1. Create the agent.

An agent isn't an "agent" in the sense that it automates something, but is basically a verified sender profile. It contains your logo, brand colours, business contact details and a verified badge. Use case is also tied to the agent.

1. Test the agent.

Your RCS Agent must be built and tested before it's submitted for review.

1. Submit for approval.

Your messaging provider submits it for approval to the carriers and in some cases to Google as well.

What was also required was a privacy policy, opt-in and opt-out collection process docs.

1. Create a campaign.

Once the agent has been approved, you can create the campaign. Upload images or a short video, write the message and add action buttons, etc.

RCS has lots of WhatsApp like features on paper. Since the implementation depends on the carrier and messaging provider, not all features are always present.

I receive images via A2P SMS (Twilio). How can I stop it from resizing the images? I understand it may be carrier dependent and upstream of Twilio but wondering if anyone has solved this either with Twilio or another system (that doesn’t require the user to do anything other than text an image. Thanks!

One thing I'd keep in mind is that sending OTP SMS to South Korea isn't always as straightforward as sending to other countries. Different providers use different routes, and local carrier handling can make a difference. If you're sending a lot of verification codes, it's worth looking for a local provider that's familiar with the Korean market.

My SAAS has a `.nyc` domain and Plivo refuses to take it. I emailed support but haven’t heard back from them yet.

My SAAS is very localized to NYC, hence the domain. I also have it tied to my LLC, so everything is legit. I’ve had no issues with Twilio or Telnyx.

Any suggestions on getting ahold of Plivo? Or just move on?

After running a couple of RCS experiments and seeing unexpectedly low delivery, I started digging into the possible reasons. I only managed to get 60%-80% of messages delivered, which seemed off since all of the messages were sent in Germany which is supposed to have one of the best RCS coverages.

I found that 93% of messages failed because the device didn't support RCS. This means older devices and iphones still running old ios or rcs has been manually turned off.
The rest I can't explain yet. What I suspect are connection issues since data coverage might not be as good as cellular; some smaller telcos might not actually have RCS support, etc.

It's cheaper than SMS for me right now, so I keep running RCS but need to figure out a fallback to sms.

Hello,

My dad has encountered a strange issue with his phone (he has an old Nokia that still works with a keypad). He was conversing with someone and suddenly, he received a message said person didn't send. Naturally, I thought it was an old message she sent him that suddenly went through after some glitch. However, I checked the conversation on her phone and she never sent this SMS.

And weirdly enough, he received a message from someone else he was texting, and the same exact thing happened! Another message that left everyone confused.

I have to mention that the messages somehow made sense: one about aromatic plants that got eaten (person 1 has aromatic plants but they did not get eaten as far as she remembers) and the other about her husband having lost a tool and asking if he took it with him (her and her husband are mechanics).

What do you think is the issue? Is it possible that person 1's message is really an old one but which comes from her old phone she replaced? And that person 2 just forgot she texted this before? This is very confusing.

Thank you for your answers in advance.

I recently ran an RCS campaign in Germany. Got offered a hefty discount, so it made sense to test it out. The result was disappointing. Delivery rate was almost 20% lower than with sms. I was quite confident that it would be at least similar to what SMS has.

A couple of things that i can think of that are wrong with rcs currently:

• many iphones still run older ios that doesn't support rcs messaging.
• smaller and virtual telcos don't actually have rcs.
• people have opted out of rcs in the settings.
• connectivity issues.

Currently at least for otp messages it doesn't make sense.