“Our SMS OTP Costs Doubled”: Is That an RCS Project or a Routing Complaint?
Separate an SMS authentication cost complaint from a scopeable RCS business-messaging project by checking the job, markets, current route, agent requirements and migration decision.
Signals to watch
- Authentication and conversational messaging jobs are separated
- Countries, networks and current route are stated
- An RCS agent, verification need or dated migration decision is named
An SMS one-time-password cost spike is first an SMS routing and pricing problem, not automatically an RCS project. RCS for Business becomes a separate discovery track only when the sender names an interactive or branded conversation, target markets, reach and fallback requirements, an agent or verification need, and a dated provider decision.
This distinction matters to a business-messaging sales lead watching authorized telecom-reseller, mobile-growth and authentication Telegram groups. The lead is trying to find a messaging project, not merely a complaint. A one-day delay can lose a place in the carrier or aggregator shortlist, but sending an RCS pitch into an unresolved OTP delivery incident can lose credibility just as quickly.
Definition: SMS OTP and RCS for Business solve different jobs
OTP means one-time password: a short-lived code used as one factor in an authentication or transaction flow. SMS is the text-message transport commonly used to deliver it.
RCS means Rich Communication Services. The GSMA Universal Profile supplies a common service and technical basis for RCS interoperability. RCS for Business is the business-to-consumer use of RCS, generally through a business agent that can support branded, richer and interactive conversations where the service is available.
Those definitions do not prove that RCS is an appropriate authentication channel for a specific app, country or risk model. They show why “SMS got expensive” and “we want an RCS agent” are different commercial statements.
Step 1: write down the actual complaint
Do not start with the proposed replacement. Start with the observed change:
- price per message or total invoice;
- delivery rate, latency or failed verification sessions;
- countries and mobile networks affected;
- current supplier and route type, if the poster may disclose them;
- date the change began; and
- whether volume or traffic mix also changed.
“Costs doubled” has no denominator. It may mean the unit rate changed, more messages were sent, retries rose, a destination mix shifted or a contractual discount ended. Possible explanations are not findings. Ask for the comparable billing periods and message counts before treating the statement as a market fact.
Step 2: separate authentication from conversation
Ask what the sender wants the user to do.
If the only job is “receive a code and enter it,” the immediate review belongs to authentication architecture and SMS delivery. If the desired job includes a verified brand identity, suggested actions, rich cards, two-way support or a continuing customer conversation, RCS discovery may be relevant.
The distinction is not cosmetic. Authentication teams care about threat models, code expiry, delivery, fallback and account recovery. Customer-engagement teams may care about branded interaction, response paths, content and campaign measurement. One provider may serve both, but the buying owners and acceptance tests can differ.
Step 3: map countries, networks, devices and fallback
Never write “RCS is supported” as a global fact. Record reach for the exact sender, market, mobile network, device and provider combination. Also ask what happens when the recipient cannot receive the intended RCS experience.
A fallback design may return the user to SMS, another channel or a manual recovery step. The right path depends on the authentication and product requirements. Current public information is not sufficient to confirm any poster’s device reach, network availability, consent basis, pricing or account eligibility.
The useful output is a market table:
| Market | Current OTP route | Observed problem | RCS availability checked? | Required fallback |
|---|---|---|---|---|
| Country/network named by poster | supplier or unknown | price, delivery or both | yes / no / unknown | stated requirement or unknown |
Do not fill a blank cell with a regional average.
Step 4: check whether an RCS business agent is part of the request
Google’s RCS for Business documentation organizes business messaging around an agent, the business identity and conversational endpoint presented to users. Public launch documentation also includes verification and launch steps. That makes four questions commercially useful:
- Is there an existing agent or is a new one required?
- Which brand and legal organization will own it?
- Who supplies the messaging connection and handles launch?
- Which markets and networks are included in the first release?
“Can you give us RCS rates?” does not answer any of them. “We need a verified agent for a support flow in two named markets before our September app release” is closer to a scopeable discovery call, although provider availability and approval still require confirmation.
Step 5: route the message to one of four outcomes
Use the evidence, not the acronym:
- SMS investigation: the job remains OTP delivery and the issue is rate, route, latency or failure.
- RCS discovery: the sender describes a business conversation, target markets, agent ownership, fallback and a decision date.
- Hybrid review: the customer wants RCS for supported users while maintaining an explicit authentication or fallback path elsewhere.
- Watchlist: the post contains a cost complaint but no market, job, owner or date.
This routing prevents two common errors: treating RCS as a universal SMS replacement and dismissing a genuine richer-messaging project because it began with a cost complaint.
Example: one message, two potential workstreams
The following is an illustrative composite, not a real customer or commercial result:
“Our SMS OTP bill doubled in July. Looking at RCS before the app relaunch on 15 September. Traffic is mostly Brazil and Mexico. Need vendor options this week.”
Known from the message:
- claimed problem: July SMS OTP bill;
- possible project: RCS exploration;
- markets: Brazil and Mexico;
- decision window: vendor options this week;
- product event: 15 September relaunch.
Unknown:
- comparable message volumes and unit prices;
- networks, delivery performance and current route;
- whether RCS is intended for OTP, support or another journey;
- device and network reach;
- agent owner, verification status, consent and fallback;
- who has buying authority.
The correct next action is not a quote. Split the thread into an SMS cost review and an RCS journey discovery. Ask for the July and June volume/rate basis, then ask which user action RCS is expected to support.
Completion standard for a scopeable RCS lead
A human reviewer should be able to see:
- the messaging job and current pain;
- target markets and networks;
- current route and baseline period;
- intended RCS experience and agent owner;
- fallback and security owner; and
- the next provider, launch or procurement decision with a date.
Missing fields stay marked Unknown. A commercial score can change review order, but it cannot certify reach, price or suitability.
Use monitoring to find the thread, then verify outside it
TOP Prospect can filter, deduplicate, classify and rank messages from Telegram groups the user intentionally connected and is authorized to access. It preserves the original text, source, time, AI summary and reasoning, and can surface the candidate in a Signal Console, Bot alert or digest.
It cannot read private chats or unauthorized groups, obtain a carrier quote, verify an RCS agent, confirm sender consent or contact the poster. Those steps belong to the sales, product, security, provider and carrier teams.
Use B2B lead-intent stages to separate complaint from provider evaluation, competitor-switching Signals for the evidence needed before inferring a switch, and the Telegram business Signal workflow to route the candidate to a person.
Frequently asked questions
Does a rise in SMS OTP cost create an RCS project?
Not by itself. It first creates an SMS cost-and-routing investigation. RCS discovery becomes relevant only if the sender also wants a supported RCS user journey, markets and networks are checked, fallback is planned and an agent or provider decision is scheduled.
Can RCS replace every OTP message?
No general replacement claim is safe. Reach, device and carrier support, user consent, authentication design, fallback, security requirements and local rules must be verified for the actual markets and account.
What should sales ask first?
Ask which countries and networks changed, whether the complaint is price or delivery related, and whether the desired job is one-time-code delivery or an interactive verified-brand conversation.
Can TOP Prospect determine message pricing or carrier reach?
No. It can organize authorized group discussions and rank a candidate with its source evidence. Current pricing, network availability, agent eligibility and technical design require confirmation from the relevant providers and carriers.
