Adding text to a support desk is easy. Running it well is harder. Most teams switch on a number, put it in the website footer, and within a month they have three problems. Customers text at 10 PM and expect an answer. Two agents reply to the same thread. And nobody can find the SMS conversation when the customer later emails about the same issue.
Texting works for support when you treat it as a channel with its own rules. You need a shared inbox with clear ownership, response targets that match what customers expect from a text, defined points where a thread moves to a call or a specialist, and a reliable link between each thread and a ticket. This guide covers all four, plus the cost math. On Ready, replies you receive are billed, not only the texts you send.
Get the number registered before you announce it
US carriers filter unregistered application-to-person traffic. That means your support line needs A2P 10DLC registration: a brand, plus a campaign whose use case matches what you send. For a support line that is usually customer care, not marketing. Registering the wrong use case is a common cause of throttling, and our use-case picking guide walks through the choice.
On Ready, registration is handled in-app with no setup fee:
- At submit: $25, which is the first month.
- Monthly after that: $25/mo for registration + $2 per number.
- Timing: most approvals take 2 to 7 days.
You don't have to wait idle while you're in review. The first 20 texts are free one-to-one sends, so use them for internal testing before you pay for registration, because the free texts end the moment a registration is paid for. An account can send up to 500 texts a month before registering, at its normal per-text rate. If you bought your number first, you send on our shared registration at the same rate while your own is in review. To send, you add a card and get a number, which is $2 a month with the first month charged when you get it.
Write your sample messages the way your agents actually write. "Hi Dana, this is Marcus from support. Your replacement shipped today, tracking is in your email" is a realistic customer-care sample. A sample full of promo language is how support campaigns get rejected.
Set up the shared inbox so ownership is obvious
A support text line is a shared inbox. Every agent can see every thread. That's the point, and it's also the risk.
Decide who owns a thread
Pick one rule and write it down:
- First responder owns it. The agent who sends the first reply keeps the thread until it's resolved or explicitly handed off. This is simple and works for small teams.
- Ticket assignee owns it. If your help desk assigns tickets, the SMS thread follows the ticket owner. This is better for teams of 8 or more, but it requires the ticket link described below.
- Queue by topic. Billing threads go to billing, technical threads go to tier 2. This only works if someone triages fast, so pair it with an auto-reply that asks one routing question.
Whatever the rule, agents need to see who touched a thread last before they type. Double replies feel sloppy on text in a way they don't on email, because the customer's phone buzzes twice with two different answers.
Work from a computer, not a phone
Agents should answer from a desktop inbox, not a shared handset. Ready's Inbox puts inbound replies in the app. For teams on GoHighLevel, the native integration syncs inbound and outbound messages both ways, so threads also land in GHL. If you're weighing options, how to text from a computer for business covers the tradeoffs.
Use auto-replies for coverage, not answers
An auto-reply on a support line should do three things: confirm receipt, set an expectation, and offer one alternate path. For example: "Got it, thanks. Our team replies 8 AM to 6 PM ET, usually within 15 minutes. For an outage, call 555-0100." There are more patterns in our auto-reply examples.
Ready's AI message writer can help draft and spam-check templates. On a new account a person still sends the replies. Ready no longer offers AI agents that answer inbound texts on their own.
Response-time targets that match the channel
We have no universal benchmark for SMS support response times, and we'd distrust anyone quoting a precise one. The practical reality: a customer who texts expects something closer to chat than to email. Here's a starting framework to adjust against your own data.
| Situation | Suggested first-response target | Why |
|---|---|---|
| Business hours, inbound question | 15 minutes | Feels conversational; longer and customers start calling |
| Business hours, follow-up in an open thread | 30 minutes | Context exists; slight delay is tolerated |
| After hours | Next business morning, with an auto-reply set that night | Holding a reply beats sending it at 11 PM |
| Order or account emergency | 5 minutes, or escalate to a call | Text is the wrong place to make someone wait |
Measure first response separately from resolution. A thread can take two days to resolve because you're waiting on a warehouse, and that's fine if the customer heard from you within 15 minutes and got an update each day.
Quiet hours affect your reply timing
Ready holds sends outside permitted local hours, based on the recipient's area. A reply to a customer who texted you in the last 24 hours goes out at any hour. Any other agent text sent in the recipient's quiet hours is held only if texting opens within about 6 hours; otherwise it is refused and has to be resent in the morning. Tell agents this up front so a refused text doesn't look like a delivery failure. For multi-timezone teams, our quiet-hours post explains the logic. Campaigns, drip campaigns and automations wait up to 24 hours for the window, and a held text is charged only when it actually sends.
Escalation: when a thread leaves text
Some conversations shouldn't stay in SMS. Define escalation triggers so agents don't improvise.
Move to a phone call when:
- The customer has sent three or more messages without the issue narrowing.
- Emotion is high: all caps, threats to cancel, repeated question marks.
- Identity verification or payment details are involved. Don't collect card numbers over SMS.
With the Ready Dialer, an agent can click-to-call from the dial pad in the dashboard (or in GoHighLevel). Calls can be recorded with consent and transcribed. It's billed at $0.025/min. Each started minute bills as a full minute, and only answered time bills, so a ring-out costs nothing. A 7-minute escalation call is 7 minutes × $0.025 = $0.18. A good handoff text before the call: "Easier to sort this by phone. Calling you from this number in 2 minutes, OK?"
Move to a specialist when the issue needs access or authority the first agent lacks. Have the specialist reply in the same thread, introducing themselves by name. Starting a new thread from a different number confuses customers.
Move to email when you need to send something long, such as a policy, a multi-step guide or an invoice. Text the summary and say the details are in their inbox.
Keep every thread tied to a ticket
This is where most SMS support setups break. Text threads are keyed by phone number. Tickets are keyed by issue. One customer can have three tickets over a year and one continuous text thread.
Rules that hold up
- One open ticket per phone number at a time. A new inbound text attaches to the open ticket if one exists.
- Reopen window. If a text arrives within, say, 7 days of a ticket closing, reopen it. After that, create a new ticket.
- Put the ticket number in the first reply. "Ticket #4821, we're on it." Now the customer can quote it on any channel.
- Log the outcome in the ticket, not only the thread. Agents searching the help desk shouldn't need to open the SMS inbox.
Wiring it up
If you run support out of GoHighLevel, the native integration keeps two-way threading intact per sub-account. Our native vs webhook sync post explains what a webhook-only setup loses.
If your help desk is something else, you'll connect it through the API. Inbound messages can be read with GET /v1/messages (paged with before_id), and webhook setup is in the webhooks docs. Sending a reply from your help desk looks like this:
POST https://api.tryready.com/v1/messages
X-API-Key: <key>
Idempotency-Key: 6f1c2e0a-8b3d-4c1e-9a7f-2d5b8e4c1a90
{"to": "+12125550199", "body": "Ticket #4821: replacement shipped today, tracking is in your email.", "consent_attested": true}Send a fresh Idempotency-Key per message, so a retry after a timeout never double-sends. consent_attested is your promise that the recipient agreed to receive texts. A customer who texted your support line started the conversation. Promotional texts to that number later are a separate consent question, and compliance stays the sender's responsibility. For the full build, see our SMS API integration guide and the quickstart.
An honest note: Ready is the texting layer, not a help desk. If you need SLA timers, skills-based routing and CSAT reporting, keep your help desk and connect texting to it.
What support texting costs: a worked example
On Ready, both sent and received texts are billed per segment at the Standard rate of $0.0075/segment plus a $0.0045 carrier fee.
Assumptions (illustrative, not a benchmark):
- 600 support conversations a month
- 4 outbound replies per conversation, averaging 200 GSM characters, which is 2 segments each (153 characters per multipart segment)
- 3 inbound customer texts per conversation at 1 segment each
Math:
- Outbound: 600 × 4 × 2 = 4,800 segments
- Inbound: 600 × 3 × 1 = 1,800 segments
- Total: 6,600 segments × $0.0075 = $50, plus 6,600 × $0.0045 in carrier fees
- Plus registration: $27/mo with one number
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.
Watch emoji in templates. One emoji in a 200-character reply drops the per-segment limit to 67 characters, which makes it 3 segments instead of 2. Across 2,400 replies, that's 2,400 extra segments, or 2,400 × $0.0075 = $18 more at the Standard rate before carrier fees.
For context, a raw CPaaS like Twilio runs around $0.0083 a segment. If you're building the integration yourself anyway and per-segment price is what matters most, that's a reasonable path. What you'd own in that case is registration, STOP handling, quiet hours and the inbox. Ready includes all of those.
The practical takeaway
The text line itself is the easy part. What makes it work is the operating model around it:
- Register the right use case before you announce the number.
- Set one ownership rule for threads.
- Publish response targets your team can actually hit.
- Agree on when a thread moves to a call or a specialist.
- Never let a thread exist without a ticket.
If you want to try it, sign up and use the 20 free one-to-one texts, sent from the inbox, to test your handoff wording before you register. Auto-replies are paid from the first text. Rates are on the pricing page.