Sending Messages and What They Cost
Once an account is configured, sends come from several places and all land in the same log.
Where to find it
Architect Panel → Communication:
- Message Log — every message, its state, its segments and its cost
Architect Panel → Commercial:
- Campaign Manager — bulk sends to a selected audience
- Campaigns — the campaign records themselves
Architect Panel → Automation:
- Workflow Builder — send actions at a workflow stage
Where sends come from
- Workflows — a send action at a stage. This is how most operational messaging works: an appointment reminder, a status change, a code.
- Campaigns — a bulk send to a selected audience, from Campaign Manager.
- Platform paths — two-factor codes and password resets use the same accounts.
Segments, and why your bill is bigger than you expected
This is the single most useful thing to understand about SMS, and it surprises nearly everyone.
A text message is billed per segment, not per message. A message using the standard GSM-7 alphabet fits 160 characters in one segment. Exceed that and it is split, and concatenated messages carry overhead — so the second segment starts at around 153 characters, not 161.
Worse, a single character outside GSM-7 switches the whole message to a different encoding where a segment holds only 70 characters. The usual culprits are invisible:
- A curly apostrophe pasted from Word instead of a straight one.
- An en dash or em dash instead of a hyphen.
- An emoji.
- A non-breaking space.
One smart quote can therefore turn a one-segment message into a three-segment message and triple the cost of a campaign. The Message Log records the segment count, so check it on a test send before a bulk run.
Delivery is not immediate, and not guaranteed
A message is queued, dispatched, and then reported on by the provider. The states matter and are frequently conflated:
- Queued — accepted by the platform.
- Sent — handed to the provider.
- Delivered — the carrier says it reached the handset.
- Failed — it did not, with a reason.
None of these means read. Build any process depending on a message on the state you actually have — an appointment reminder is a courtesy, not service.
Writing the message
Keep it short, identify yourself, and say what you want. A message that does not say who it is from reads as spam and gets reported, which damages your sending reputation for everyone else on the number.
Include a way to stop. People expect it, the rules generally require it, and it is cheaper than a complaint.
Timing
Do not send outside reasonable hours. A two-factor code at 3am is fine because the user just asked for it. A reminder is arguable. A campaign is not — and where the send is scheduled rather than triggered, constrain the window explicitly rather than trusting whoever sets the schedule.
Worked example
A clinic sends appointment reminders 48 hours ahead from a workflow. The template was drafted in Word and contained a curly apostrophe in "we'll", making every message three segments. Replacing it with a straight apostrophe brought it to one and cut the monthly cost by two thirds, with no change to what the patient reads.
Recommendations
- Test one message and read the segment count before any bulk send.
- Compose templates in a plain editor, not a word processor.
- Never depend on "delivered" as proof anybody read it.
- Constrain sending hours on anything scheduled.