Welcome to the second TADSummit Online 2025 Conference Session. We plan to run these once per week, and as always delivering honest insight. No BS, it’s in our policies.

The presenter is Michael Lamb, President / Co-founder of nativeMsg. Michael and I got chatting over Linkedin, as we chatted I discovered someone focused on the truth of RCS. Enabling the core value of RCS, not another channel, rather the business value of a brand’s app on every phone. In the audience for this session includes: Paul Sweeney (potential nativeMsg customer), Mark Hay,  Noah Rafalko, and Johnny Tarone.

NativeMsg’s solutions simplify the creation, hosting, and connectivity required to enable RBM (RCS Business Messaging) globally. Whether you want to extend your e-commerce store or integrate your existing AI into this new channel, nativeMsg have the no-code and API solution to make it easy.

We overran on time, as you’ll hear, the conversations were intense, frank, and lifted the lid on the challenges facing RCS in achieving its potential through some of the existing channels. While Michael’s approach received the respect of the audience.

NativeMsg was founded around 2016 as 2 way SMS started to take off, and is purpose built for RBM (RCS Business Messaging). They just, announced on March 18, 2025, U.S. Patent No. 12,250,186, they now have 4 RCS patents. “Method And System For Providing Interoperability For Rich Communication Suite (RCS) Information Sharing Using Plural Channels.” Using plural channels, the technology ensures enhanced interoperability, improved user experiences, and greater flexibility for businesses and consumers alike. The innovation addresses critical challenges in RCS adoption, such as cross-platform compatibility and efficient data exchange.

The end of SMS has been forecast for many years, see diagram below, at least since 2005. Here we are in 2025, and it’s still going, despite the rampant fraud conducted over SMS (statement from Google). See last week’s TADSummit online Conference session on Google rejects SMS OTP for QR Codes.

CCMI (Cross-Carrier Messaging Initiative) drove the creation of nativeMsg. In October 2019, the four major U.S. carriers announced an agreement to form the Cross-Carrier Messaging Initiative (CCMI) to jointly implement RCS using a newly developed app.

This service was to be compatible with the Universal Profile. However, this carrier-made app never came to fruition. By 2021, both T-Mobile and AT&T signed deals with Google to adopt Google’s Messages app. In 2023, T-Mobile and AT&T agreed to use Google Jibe to implement RCS services, and in 2024 Verizon agreed to use Google Jibe. This masks so much, as there were many other vendors and deals announced over that time.

The current interest comes from Apple adding support for RCS in Messages with iOS 18 in September 2024. RCS is also accessible through desktops via the web client of Google Messages.

NativeMsg has certainly had a journey. BUT they are still standing with a platform that supports RBM, supporting both API and no-code. While many other vendors that began with RCS-e / Joyn (2012) have moved on.

The volume products are SMS and MMS, this is the legacy, which dominates the current mindset. The question Michael is often asked, “How much is a message?” Transporting 160 characters from point A to point B.

RCS is now on the hype cycle, and Michael is seeing demand emerge around the world. Its an interesting situation as RCS enables an approach separate from legacy approaches on price per message. And adds complexity on how long is a conversation? Is it one hour, one day, one month, or a lifetime? And most interestingly enables nativeMsg to approach the space without worrying about commoditizing the legacy SMS business.

Michael stated simply, RCS is not messaging, it’s about applications. It sits in the messaging app, but enables a completely different model.

At this point Johnny breaks in that pricing matters for the carriers and aggregators. Unless they let Google monetize everyone’s data. Michael responds that RBM enables an outcome driven model. Rather than the cost is 5c per message, the model could be, across your customer base RBM drives $X M revenue, for which we charge $X M / 100.

NativeMsg’s platform aggregates customer knowledge, which has immense value for carriers, aggregators, and brands. Johnny positioned nativeMsg as a mini-Google, while Michael dodged that with the flexibility they can support the whole ecosystem.

Noah joined the discussion on the unique situation RCS finds itself as an over the top service charged by the carriers. A federated version of WhatsApp, where each carrier takes a share. Transport is the legacy mindset, and dominates carriers’ thinking. Noah gave a warning that many in telecoms like to talk, and then copy.

Noah asked what Michael considers his USPs. The first is connectivity is an option, they prefer to stay focused on tools and solutions for RBM. And to the point Noah raised on people sucking out intelligence, that definitely happened over one year ago. The other USP is choice, there are lots of professional services, and nativeMsg enables those.

In the evolution of RBM, there’s SMS using RCS, then rich cards which could bring the end of MMS, and then the applications business. NativeMsg supports the basics, but also how businesses can support their ecommerce platform over RCS, how to integrate with their Zendesk instance, etc. There is an RCS Emulator for creating new/updated experiences, check out their Applications Docs to learn more.

Mark compliments Michael’s focus on RCS, as the legacy aggregators have to manage the transition in their business away from SMS. While for nativeMsg they can immediately jump to the end game, rather than incremental shifts in traffic to maintain transport revenues. Also the legacy transport model does not enable a price related to the value. Could nativeMsg be snapped up by one of the legacy aggregators, e.g. Sinch or Infobip?

Paul was brought into the discussion on how they are using RCS. He immediate highlighted if a customer asks about price per message, its starting at the wrong point. The current issue is pricing per session. Which is complex, there are several points of value before there, identity, reach, and simplicity. Knowing it’s the brand, reaching all addressable customers, and a simple workflow to resolution. In Paul’s customer conversations its, “Can I reach all my customers?” and if some do not respond, then what happens, and then what happens? It’s about having all the data to simplify communications. Strategically it’s about taking WhatsApp out of the equation, so they do not charge brands for accessing their customers.

Noah explained the shift happening is the outcome, that is where the value resides. For an enterprise showing a different outcome they value, and of course will pay for. Noah strongly recommended on nativeMsg’s USP, draw a line in the sand of not providing transport, help if the enterprise requires. As Paul highlighted having all the data to simplify communications is what matters. Michael supported that advice, its where their work to date is taking them. Enabling choice, and helping enterprises get to the end game, than sending more messages.

Johnny hijacked the podcast for a minute to ask Mark his view on RCS. Mark gave an example of how hype is clouding the reality on RBM. Which Johnny framed as the legacy providers are in a quandary. SMS is being beaten up on because of fraud, yet its their core business. So the industry becomes, “look at the shiny object” while keeping the core SMS business ticking over.

Mark thinks RCS will do better in the US than Europe, given the penetration of WhatsApp in Europe. It’s taken a long time to get to where we are in RCS, and still requires the industry to work together. Can telco federations outside of the PSTN work in the modern world.

Noah mentioned how the consumer tends to be treated as an element to be controlled, trapped in a fun silo as a donkey. The Financial Times article from Tim Berners-Lee on international coordination for a new standard that gives users control over their own data. Yes, TNID was there first. It is called Solid (for social linked data) and the technical details are controlled by W3C, the web standards consortium.

On other topics for the group to discuss:

• Map out how a nativeMsg enabled solution could work for Webio
• Add your topics you’d like discussed in the comments section.