Why customers see 'cannot reply to this short code' and how to fix it

Your campaign goes out from a five- or six-digit short code. A customer has a question, hits reply, and their phone throws back something like "Message not sent," "Unable to send to this number," or a free carrier notice saying message blocking is active. Now they're annoyed. They might call your support line, or they might decide your brand is a spam operation. Either way, the program that was supposed to start a conversation has ended one.

There are only a handful of reasons this happens. Some are on your side: how the short code was provisioned, and what happens to replies once they arrive. Others are on the recipient's side: their carrier plan, their device settings, or where they're standing. This post covers each cause, how to tell which one you have, and when the right fix is to stop asking a short code to do a two-way job and move conversational traffic to a long code.

First, figure out which failure you actually have

"Customers can't reply" covers two different problems, and the fixes don't overlap:

1. The reply fails on the handset. The customer sees an error and the message never leaves their phone or carrier. This is usually a carrier or plan issue.
2. The reply sends, but nobody ever sees it. The customer's phone shows it as sent. On your end it goes to a keyword handler that only understands STOP, HELP and JOIN, or into a log nobody reads, or nowhere. From the customer's side this looks the same as being ignored.

Ask two or three of the complaining customers for a screenshot. An error banner points to the first problem. A sent reply with no answer points to the second.

Cause 1: the short code was provisioned one-way

Short codes are provisioned carrier by carrier, and a program can be set up mainly to push messages out. Many alert and marketing programs are built that way: the platform handles a fixed set of keywords (STOP, HELP, maybe a JOIN keyword) and drops any other free-text reply, or never routes it anywhere useful.

How to check:

• Ask your short code provider whether mobile-originated (MO) messages are enabled and routed to your account, and where they land: a webhook, an inbox, or nowhere.
• Text a non-keyword reply from your own phone ("what time do you close?") and see whether it appears anywhere in your system.
• Check HELP and STOP specifically. Carrier guidelines expect any short code program to answer HELP and honor STOP. If those fail too, you have a compliance problem as well as a customer-service one.

The fix is either to turn on and route MO properly (a provider ticket, sometimes a carrier re-provisioning), or to accept that the code is one-way. If you accept it, say so in the message ("This number doesn't accept replies. Questions? Call 555-0100.") so people aren't left texting into nothing.

Cause 2: the recipient's plan blocks short codes

This is the most common cause of handset errors, and you can't fix it from your side. Some prepaid plans, family plans with parental controls, business lines with restrictions, and accounts where someone once turned on "block premium messages" or "block short codes" will refuse to send to a short code. Some will refuse to receive from one as well. The customer may get your outbound text because of how the block is scoped and still be unable to reply, or the block may cover both directions.

The fix is on the recipient's account: they or the account holder lift the block through their carrier's app, website or support line. We wrote a separate walkthrough on this: why toll-free and short code texts are blocked and how recipients allow them. Link it in your support macros so agents don't have to improvise.

Cause 3: the code isn't live on that customer's carrier

Each carrier provisions a short code separately, so a code can work on the big three and still be missing or partly configured on a smaller carrier or an MVNO (the prepaid brands that run on another carrier's network). If every complaint comes from customers on one carrier, this is the likely cause.

Check your provider's carrier coverage report for the code and open a ticket for the missing carrier. Expect it to take a while, because carrier provisioning isn't fast.

Cause 4: travel, moved codes and old threads

A few edge cases produce the same complaint:

• Roaming or abroad. US short codes are US-only. A customer replying from another country's network usually can't reach the code at all.
• A retired or migrated code. If you moved programs or let a code lapse, customers replying to old threads are texting a dead number.
• Switched carriers or ported numbers. The customer may have carried a carrier-side block over to their new account without knowing it.

If you're seeing error codes in delivery receipts rather than handset complaints, the SMS error codes explainer maps the common ones to their causes.

When a short code is the wrong tool

Short codes are good at fast, high-volume, mostly one-directional traffic: OTP codes, fraud alerts, flash-sale notices to very large lists. They're slower and more expensive to stand up than other sender types. Provisioning typically takes weeks, and the lease is a real line item; see what a short code actually costs for the breakdown. They're also a poor fit for conversation. A five-digit sender doesn't look like a person, plan-level blocks hit short codes specifically, and many setups treat replies as keyword input rather than messages from a human.

If customers keep trying to reply, take that as a sign they want a conversation, not as an error to suppress.

For a longer comparison, including RCS, see 10DLC vs toll-free vs long code vs RCS.

The hybrid many teams land on

You don't have to give up the short code. A common split looks like this:

• Keep the short code for time-sensitive, high-volume one-way sends where throughput matters most.
• Send anything that invites a reply (appointment confirmations, order questions, "reply YES to reschedule") from a registered 10DLC long code that a person or team actually monitors.
• Make sure consent covers both senders. Your opt-in language should name the program and its message types, and opt-outs need to be honored across both.

What the switch looks like, in numbers

As an example, assume a 5,000-contact reminder campaign moves from a short code to a 10DLC long code. Each message is 140 plain characters with no emoji, which is 1 GSM-7 segment. Assume 10% of recipients reply with a one-segment message.

On Ready's Standard rate of $0.0075/segment plus a $0.0045 carrier fee per segment:

• Outbound: 5,000 × 1 segment × $0.0075 = $38 plus 5,000 × $0.0045 in carrier fees.
• Inbound replies: 500 × 1 segment × $0.0075 = $4 plus 500 × $0.0045 in carrier fees. Replies are billed like a sent text.
• Registration: $25 at submit (the first month: $25 for registration), then $25/mo for registration + $2 per number. Most approvals take 2 to 7 days.

Ready's all-in prices per segment include the carrier fee but not screening: Scrub lists and Number validation, the two switches in Settings under Compliance, each add $0.003 per segment when switched on, shown as screening on your bill, and both are off by default. Unless you turn the opt-out footer off, the first text to each contact, and one again from time to time, also gets "Reply STOP to opt out" and your business name if the message does not already have them, so a text close to the segment limit can bill one more segment.

Now the time cost. At an assumed 3 segments per second, 5,000 segments take about 28 minutes to go out (5,000 ÷ 3 ≈ 1,667 seconds). On the lowest T-Mobile trust tier, the daily brand cap is around 2,000 messages, so a 5,000-contact send to T-Mobile users at that tier spreads across days. If you need 50,000 OTP codes delivered in two minutes, a long code isn't the answer, and your short code is earning its lease. For reminders and anything conversational, half an hour is usually fine.

Watch your message length too. Add one emoji to that 140-character text and it becomes 3 segments, which triples the per-message cost.

Where Ready fits, and where it doesn't

We make Ready, so here is what it does and doesn't cover. Ready sends from registered 10DLC numbers (and from blue lines over iMessage), not short codes. If you need short code throughput, keep your short code provider. If you're moving conversational traffic off the short code, Ready includes:

• A two-way inbox. Replies land in the Inbox, and in GoHighLevel if you've connected it, so they reach a person instead of a keyword handler.
• Automatic STOP handling. An opt-out propagates so the contact can't be texted again on any campaign.
• Quiet-hours enforcement. Sends are held outside permitted local hours based on the recipient's area. Campaigns, drip campaigns and automations wait up to 24 hours for the window; a one-to-one or API text is held only if the window opens within 6 hours, otherwise it is refused and must be resent; a one-to-one reply to someone who texted you in the last 24 hours goes out at any hour.
• In-app registration. Brand and campaign registration happen inside the product, which matters because unregistered traffic gets carrier-filtered.
• Local presence. Sends go from your number closest to the contact's area code, and every number stays on your registered campaign.
• An API for platforms. Send with POST /v1/messages and pick the sender with the from field, so replies come back to a number your team watches:

POST https://api.tryready.com/v1/messages
X-API-Key: <key>
Idempotency-Key: <uuid>

{"to": "+12125550199", "from": "+13125550142", "body": "Reminder: your appointment is Thu at 2 PM. Reply C to confirm or R to reschedule.", "consent_attested": true}

Full details are in the messages API docs.

On price: raw CPaaS APIs and GoHighLevel's LC Phone cost less per segment. What Ready adds is the compliance stack and the inbox built in, plus self-serve registration.

The practical takeaway

When customers see "cannot reply" on your short code texts, work through it in order:

1. Get screenshots and separate handset errors from replies that go unanswered.
2. Check that MO is enabled and routed, and that HELP and STOP actually respond.
3. Look for a pattern by carrier, and send blocked customers the unblock steps.
4. If people keep trying to reply, move the reply-prone messages to a monitored 10DLC long code and keep the short code for high-volume one-way sends.

If you want to test the long-code side, sign up and use the first 20 free texts (one-to-one sends; a card on file is required) before you submit registration, since the free texts end once registration is paid for. Then compare reply handling against what your short code does today.