Slack to SMS and Teams to SMS: alerting and messaging from chat tools

Your team already works in Slack or Microsoft Teams. The problem is everyone who isn't in the channel: the technician in the van, the manager who muted the workspace at 6 PM, the customer waiting on an answer. A text reaches them. A chat notification usually doesn't.

This post covers how to wire chat tools to SMS: the three integration patterns that work, which alerts belong on a text and which don't, what it costs per message, and how consent differs when the recipient is your own employee versus your customer. We make Ready, so the code examples use our API. The patterns work with any SMS API.

The honest starting point: there's no magic "Slack to SMS" button

Ready connects to Slack, not Teams. Connect Slack under Settings, Integrations, Apps and pick a channel, and Ready posts each inbound reply and opt-out there. An automation can also post to a channel or message the contact's assigned teammate. Sending a text from Slack, and everything on Teams, still takes one of these setups:

1. Chat triggers your code, your code sends the text. A slash command, a Slack Workflow step or a Teams Power Automate flow makes an HTTP call to a small service you control. That service calls the SMS API.
2. The source system sends to both. Your monitoring tool, CRM or order system posts to the channel and sends the SMS at the same time. Chat isn't in the delivery path.
3. SMS replies flow back into chat. Inbound texts hit your webhook and get posted to a channel or thread so the team can see them.

You'll probably end up using two of the three. Here's how they compare:

Pattern 1: a slash command or workflow that sends a text

The simplest build. Someone types /text-tech +12125550199 Gate code changed to 4471 in Slack. Or a Teams user fills in a Power Automate form. Either way, the request goes to your service, and your service makes one call:

POST https://api.tryready.com/v1/messages
X-API-Key: <your key>
Idempotency-Key: 6f1c2a9e-3b7d-4e1a-9c55-0d2f8b7e4a10
Content-Type: application/json

{"to": "+12125550199", "body": "Gate code at the Elm St job changed to 4471. Reply here with questions.", "consent_attested": true}

Three details are worth getting right.

Always send the Idempotency-Key. Slack retries slash-command requests that don't get a fast response, and Power Automate retries failed HTTP actions. Without an idempotency key, a slow response can send the same text twice. Generate one UUID per chat action and reuse it on retries.

Don't let users type raw phone numbers if you can avoid it. Map Slack user IDs or a /text-tech @jordan mention to a number stored in your own directory. You'll avoid typos and keep the numbers out of chat history.

Respond to chat right away, send in the background. Acknowledge the command instantly ("Sending to Jordan...") and post the result when the API returns. Opt-outs and numbers on your Ban list are refused up front and not charged, so surface that refusal in the channel instead of failing silently.

For a group, such as "text everyone on the Saturday crew," use the bulk endpoint. It takes up to 100 recipients per call, so split larger lists into batches. The request shapes are in the messages docs and bulk docs.

Pattern 2: alerts that go to the channel and the phone

For automated alerts, keep chat out of the delivery path. If your system detects the condition, it should post to Slack and send the SMS itself. Don't post to Slack and then have a bot relay the message to SMS. Every relay step adds another point of failure.

Alerts that belong on SMS

• Business-hours operational alerts: a payment processor outage, a failed overnight import someone has to fix before customers notice, a stockout on a top-selling item.
• Field and frontline coordination: schedule changes, job reassignments, "the client moved the appointment to 2 PM."
• High-value customer events routed to an owner: a large order, an enterprise trial signup, a churn-risk flag on a key account. The account owner gets a text, and the channel gets the detail.
• Escalations a human chose to make: "nobody in #support has picked this up in 20 minutes, text the lead."

Alerts that don't

3 AM wake-up paging. Ready enforces quiet hours by default. A text sent during the recipient's quiet hours is held and delivered later, and it's charged only when it sends. That's the right behavior for customer messages, and it's why SMS through a marketing-grade platform is the wrong tool for waking an engineer at 3 AM. Use a dedicated on-call paging tool for that. It's built to escalate and ignore quiet hours, and it calls the phone. Use SMS for the daytime and evening alerts around it. 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 with 409 QUIET_HOURS_BLOCK and must be resent; a one-to-one reply to someone who texted you in the last 24 hours goes out at any hour.

Anything noisy. If a channel fires 40 times a day, piping it to SMS trains people to ignore their phone. Only send to SMS when a human needs to act, and keep the rest in chat.

Pattern 3: getting replies back into chat

A text that says "Reply here with questions" needs somewhere for the reply to land. Inbound messages show up in Ready's Inbox. You can also have them delivered to your webhook and post them into a Slack or Teams thread. On Slack you can skip the webhook: the Slack connection posts replies to your channel for you. The webhook setup and event formats are in the webhooks docs. We won't guess at field names here, so build from the docs.

The design decision that matters is threading. Key each conversation on the contact's phone number. Store the Slack thread timestamp or Teams conversation ID next to it, and post every reply into the same thread. If you skip this, replies scatter across the channel with no context.

Replies are billed like sent texts, at the per-segment rate plus the carrier fee. Budget for both directions on any two-way flow.

If your team works in an AI assistant instead of a chat app, the same idea applies through our MCP server. An agent connected to it can send texts and read conversations, with OAuth or API-key auth.

What it costs: a worked example

Assumptions for this example: a 25-person operations team sends about 800 alert and coordination texts a month. It gets about 200 replies. Every message stays under 160 plain GSM characters, so each one is 1 segment.

On Standard, every segment, sent or received, costs $0.0075 plus a $0.0045 carrier fee:

• Segments: 800 sent + 200 received = 1,000
• Rate: 1,000 × $0.0075 = $8
• Carrier fees: 1,000 × $0.0045, itemized separately on the bill

That all-in figure excludes the compliance surcharge. TCPA/DNC scrubbing and landline validation are each $0.003 extra per segment if you switch them on, and both are off by default. For an internal staff list you already verified, you probably don't need them.

The emoji tax

Teams love putting 🚨 at the front of alerts. One emoji switches the whole message to unicode, which caps a single segment at 70 characters and multipart segments at 67. A 150-character alert without the emoji is 1 segment. With the emoji, it's 3. That triples the cost of every alert. Put severity in words ("URGENT:") instead.

Fixed costs

You'll also pay registration, covered next: $25/mo for registration and $2 per number. Full fee breakdown is in 10DLC cost: every fee explained.

Consent: employees vs customers

This is where chat-to-SMS projects most often go wrong. Because the sender is "just internal tooling," teams assume the rules don't apply. They do. The rules differ by recipient, but they still apply.

Texting your own employees

• Get written consent at onboarding. Add an "I agree to receive work alerts by text at this number" line to your onboarding paperwork, and store it. A personal cell phone is still a personal cell phone.
• STOP still works. If an employee replies STOP, Ready honors it, and the opt-out applies across everything that account sends. Plan for it. Your Slack command should report "Jordan has opted out of texts" and suggest another channel. You can check the status ahead of time with GET /v1/opt-outs/:phone.
• Registration still applies. Carriers treat software-sent texts to employees as application-to-person traffic. An account can send up to 500 texts a month before registering. After that, it has to register. Pick the use case that matches what you actually send. Staff alerts aren't marketing, and choosing the wrong use case invites filtering. Our use-case picking guide walks through it.

Texting customers from chat

A Slack command that lets a sales rep text a customer is a customer messaging tool. Treat it like one.

• Only text people who opted in or texted you first. For cold outreach, use the phone or mail.
• consent_attested: true is your promise, not a record. Ready logs the sender's attestation for each send: who sent it, to how many people, and when. It doesn't store when or where the customer opted in. Your CRM or store has to keep that. If you're wiring chat into a CRM, see SMS integrations for CRMs. (A contact who signs up on a Ready-hosted opt-in page is the exception: Ready stores that sign-up, with the time, IP address and exact wording, and support@tryready.com can send you a copy.)
• Quiet hours protect you here. A text a rep sends from Slack at 10 PM is held only if the customer's permitted hours start within about 6 hours; otherwise the API answers 409 QUIET_HOURS_BLOCK and nothing is queued, so have your command post that refusal back to the channel and resend in the morning.
• Separate the use cases. If you text both staff and customers, register a campaign that matches each kind of traffic instead of putting everything under one.

Compliance is ultimately the sender's responsibility. These controls reduce risk. They don't make you lawsuit-proof.

Getting started

Here's the practical sequence. Pick one alert that genuinely needs a human to act. Send it from the source system directly, not through a chat relay. Add a slash command for human-initiated texts, with an idempotency key on every call. Keep alerts emoji-free and under 160 characters. Collect staff consent at onboarding, and keep customer consent in your own records.

If you want to test this, the first 20 one-to-one texts on Ready are free once a card is on file, so use them before you register. Registration costs $25 at submit for the first month, and most approvals take 2 to 7 days. You can sign up here, read the A2P SMS API overview, or check pricing first.