Plan an SMS integration

Turn one useful notification into a deployable plan: choose the route, size the message, handle replies and budget for the complete journey.

A reminder becomes a conversation.

Give customers the details they need at the right moment. Give your team a way to understand what happened next.

Worked scenario: Studio visit · FN–1042. The following is an illustrative application workflow, not a live result.

1. Prepare. Alex has a studio visit tomorrow. Your application prepares a reminder with the time and booking reference. Observable state: Reminder prepared.
2. Deliver. The same reminder arrives on Alex’s phone. A delivery event tells your application what the carrier reported. Observable state: Delivery reported.
3. Hear back. With a supported two-way number, Alex can reply without looking for another way to contact you. Observable state: Reply received.
4. Keep context. Your application matches the reply to the visit, so the team can pick up the conversation with context. Observable state: Reply linked to FN–1042.

What this changes

• For your customer: Useful details, without searching for the original booking.
• For your team: A delivery issue or reply you can follow up with context.
• For your next move: Add email confirmations or WhatsApp service around the same visit.

Explore the illustrative example ↗

Before you call it complete

Confirm each observable state in your own integration. The application must establish the business outcome separately from a successful API request or delivery event. Exercise the relevant unsuccessful case in the product’s working example and follow its technical references.

Start with tomorrow’s visit.

Fictional plan: Fieldnotes sends Alex a reminder for booking FN–1042, tomorrow at 14:00 in the studio’s local time. The booking application owns the appointment, permitted contact and reminder deadline. This example assumes a US recipient and an eligible dedicated US long code because Alex must be able to reply. It is a planning exercise; no number is allocated and no message is sent.

1. Destination: confirm the recipient’s E.164 number and enable the US destination in the workspace. The destination allowlist and sender registration are separate gates.
2. Sender: select an owned, reply-capable number. Complete the applicable US brand and campaign registration before application traffic; owning the number alone is insufficient. Use 10DLC registration and current country requirements.
3. Purpose and permission: classify this booking reminder as transactional. Record why this customer may receive it and respect their preferences. A booking record or category label does not itself establish messaging permission.
4. Timing: the application schedules work and rechecks that the visit still exists before submission. Stop generating the reminder after its useful deadline; do not assume SMS scheduling or validity fields are supported.

A one-way branded alert is a different decision: an alphanumeric sender cannot receive replies and is not supported for this US example. In an eligible market it needs its own registration and a usable support/opt-out path. Do not carry the two-way design into that route unchanged.

Approve the final body, then count it.

Fieldnotes: Your studio visit is tomorrow at 14:00. Booking FN-1042. Reply HELP for help or STOP to opt out.

This exact illustrative body uses 108 GSM-7 units and fits one segment. Keep the time zone clear in the booking experience. Test the longest real substitution, translated copy and required program wording before release. Appending a space and 🎨 changes the whole body to Unicode: 111 UTF-16 units, or two multipart segments at 67 units each. That single creative change doubles this example’s outbound segment count.

The browser calculator is an estimate; whole-character packing can differ from server-side billing arithmetic. Use the SMS composer to inspect copy, then confirm the resolved encoding and segments in the returned message. Extension-table characters count twice; a visible emoji can contain several code points. Smart encoding changes selected characters and needs copy approval. The character-limit guide owns current limits and counting rules.

Close the loop without duplicating contact.

1. Give the reminder one application send record tied to FN–1042. Submit using the maintained sending guide, keep credentials server-side and store Bird’s message ID. An accepted response is queued work, not delivery.
2. Consume message events through the documented webhook verification flow. Deduplicate events and correlate them to that send record; record later carrier outcomes separately from the appointment.
3. Route an ordinary reply to the care team with the current booking context. A reply is a request, not authorization to change any booking. Verify identity and commit a requested change in the booking system before confirming it.
4. Check the number’s actual STOP/START/HELP rules. Coverage is country-specific. Bird’s suppression is scoped to a sender/subscriber pair; the application must honor the customer’s stated program preference without switching senders to evade it. Test an uncovered-country path before relying on automatic handling.

Failure rehearsal: a disabled destination is a configuration refusal: repair the allowlist and registration rather than retrying blindly. A suppressed recipient remains stopped. If acceptance is lost or the final receipt never arrives, retain an unknown result and inspect the SMS log. Follow the documented same-request retry window; do not submit a fresh reminder or contact through another channel merely because delivery is uncertain. If funding fails after acceptance, record the rejection and repair funding before considering a still-useful, permitted retry.

Budget the journey, including replies.

Planning workload: 1,000 one-segment reminders per month, 100 one-segment inbound replies and 40 one-segment automatic keyword replies. These are assumptions, not measured response rates. If every reminder adds the emoji above, outbound notification segments become 2,000.

Let O be the quoted outbound rate per segment, I the inbound rate and K the applicable automatic-reply rate. Base monthly transport budget = 1,000O + 100I + 40K. The emoji variant adds 1,000O. Add applicable carrier surcharges for each direction, sender rental, recurring registration costs and taxes; keep one-time setup costs separate. Confirm whether any component is included before adding it twice. Unknown prices stay blank, not zero.

Fill rates, currency, destination/carrier scope and quote date from current SMS pricing and your account terms. Use the sender guide for registration ownership and ask the account owner for program charges. Reconcile actual segments and priced cost components after the pilot; a null component is not evidence of a free service.

Build the complete path.

Copy this deployment checklist into the release record. Fill each evidence field before sending to customers; it is useful without signing up.

Use case / owner: FN-1042 reminder / booking team
Country / enabled-destination evidence / checked date:
Sender / ownership / reply capability / registration approval:
Purpose / permission record / preference owner:
Final body / longest variables / encoding / segments:
Application trigger / booking recheck / stop-after time:
Send record / Bird message ID / same-request retry policy:
Webhook verification / duplicate and missing-event evidence:
Reply assignment / identity check / booking confirmation:
STOP, START, HELP / coverage / suppression test evidence:
Budget: 1,000O + 100I + 40K + fees + rental + taxes
Rate source / currency / scope / date / cost owner:
Pilot: owned recipients; success, refusal, unknown and opt-out
Stop rule: incorrect content, lost context or preference bypass
Launch decision / evidence links / accountable owner:

Implement the single-send and status flow, then use Start now to prepare an SMS workspace. Destination, registration and account eligibility still need confirmation.

Connect the next step.

• SMS API: evaluate the integration boundary.
• Three-country SMS planning example: compare the dated sender decisions, then check current requirements.
• WhatsApp service workflow: plan a separate permitted conversation when the task needs it.
• SMS migration: preserve senders, preferences and event handling during a move.

Your application owns the customer relationship and business actions. Preserve the appropriate identity, consent, and outcome when you move between products.

Questions to resolve.

Does delivered mean Alex read it?

No. It reports a carrier outcome where available. A reply and a confirmed appointment change are separate evidence.

Can the same budget cover every country?

No. Split the workload by destination, sender and applicable rates. Recheck registration and reply support for each route.

Go deeper in the documentation.

• Sending SMS: current submission, retries and billing behavior.
• Sender IDs: country and program approval.
• Character limits: encoding and segments.
• Opt-outs and keywords: coverage, replies and suppression scope.
• SMS events: delivery and inbound evidence.
• SMS rates: current price owner.

Explore SMS and its interactive example ↗

Recheck each destination before release

The three-country planning example was sampled on 18 September 2026. It illustrates decisions to investigate; it is not a current permission or rate quote. Check the maintained United States, Netherlands, and United Kingdom requirements. Keep registration_mode separate from sender-ID behavior or replacement, destination enablement, ownership, reply support, and message category. A registered sender or an enabled destination alone does not establish sendability.

Record the country, carrier scope, category, sender and quote date next to each rate. Leave unknown rates blank. Recheck the current country planner and SMS rates before approving the release.