Summarize Content With:
On October 5, 2026, Famulor released SMS Conversations. An SMS-capable phone number can now become a managed conversation channel: inbound messages, AI replies, manual replies, delivery status, and charged credits appear together under History → SMS. A team member can reply directly, which s the AI for that conversation until it is resumed.
The development matters beyond adding another inbox. Voice AI is synchronous: both sides must be available at the same time. SMS is asynchronous, constrained, and persistent. It suits short questions, confirmations, and service continuations that do not justify another call. But it needs a different interaction design from phone, WhatsApp, or web chat.
Key takeaways
- One eligible number can serve voice and SMS in Famulor, with different assistants assigned to each channel.
- Automatic SMS replies are disabled immediately after setup.
- Teams can see messages, AI actions, analysis, delivery status, and credits in one SMS history.
- A manual reply s the AI for that specific conversation.
- Famulor keeps replies within one SMS segment: up to 160 GSM-7 units or 70 Unicode units.
- A shared phone number does not automatically create shared memory. Context, identity, and consent still require explicit design.
What shipped on October 5, 2026 #
According to the current Famulor changelog, teams can connect an SMS-capable platform number or eligible imported number under Settings → Channels → SMS. The SMS documentation describes four core configuration steps: choose the number, name the channel and assign an assistant, connect inbound SMS, then set reply delay, inactivity timeout, and an optional conversation-ended webhook.
The table separates confirmed behavior from product boundaries:
| Area | Confirmed behavior | Important boundary |
|---|---|---|
| Phone number | The same eligible number can handle voice and SMS | A SIP trunk alone does not provide SMS |
| Assistant | Voice and SMS may use different assistants | A shared number does not automatically mean shared conversation context |
| Automation | Inbound SMS is connected after saving | AI auto-replies start disabled |
| History | Messages, actions, analysis, delivery, and credits are visible | An unconfirmed delivery must be checked before retrying |
| Human takeover | A team member can reply inside History | The manual reply s AI until it is resumed |
| Content | Plain-text replies in one segment | No attachments and no RCS |
This is not a promise of universal availability. Number type, destination country, carrier registration, workspace access, and consent still determine whether a specific SMS workflow can run.
Why SMS needs a different AI design from a phone call #
A voice assistant can clarify immediately, reflect an ambiguous statement, and manage conversational rhythm. SMS lacks tone, instant repair, and certainty that the recipient is currently reading. In return, the message remains visible and can be answered later.
That changes the assistant's job:
- Each message should have one clear purpose. Confirm a time, provide a reference, or ask one question rather than open several branches.
- Identity cannot be assumed. A known phone number is a signal, not a universal identity check. Sensitive disclosures need an appropriate verification flow.
- Silence is not necessarily failure. No reply can mean delay, non-delivery, or a deliberate choice. Automated retries need explicit rules.
- Takeover must be observable. Once a human steps in, the AI should not answer in parallel. Famulor's manual-reply addresses that operational risk.
- Channel changes need context rules. Being able to call and text the same number does not automatically transfer content or consent between conversations.
SMS is therefore not a smaller chat app. It is a constrained, carrier-dependent format with its own delivery and consent model.
Official facts and community signals, kept separate #
The product facts above come from Famulor's changelog and documentation. Two Hacker News discussions offer useful but non-representative practitioner signals:
- In a Show HN post about Hail.so , a builder describes repeatedly wiring together phone, SMS, email, providers, and compliance logic. It is a low-engagement individual account, not market evidence. Still, it illustrates why teams value a shared operating layer for multiple communication channels.
- In an Ask HN discussion about AI customer support , commenters repeatedly object to loops with no effective route to a human. This is an opinion thread, not research. The product-design signal is nevertheless specific: automation needs an observable takeover path, not only better generated answers.
Famulor's SMS History addresses that operational layer. The team can inspect the conversation, reply manually, and stop AI participation in that thread. Service quality still depends on the prompt, knowledge base, ownership model, and ongoing review.
One SMS segment is a hard editorial boundary #
Famulor keeps channel replies within one segment: up to 160 GSM-7 units or 70 Unicode units. Some special characters consume more than one unit, while emojis generally take additional space in Unicode mode. Overlong AI drafts get one rewrite and are never silently truncated.
Twilio's official SMS length documentation explains the transport constraint. A GSM-7 message longer than 160 characters becomes multiple segments with smaller payloads. One unsupported character can switch encoding to Unicode and change the segment count. Concision is therefore a transport requirement as well as a writing preference.
A practical SMS prompt should include rules such as:
- Lead with the answer or the specific question.
- Use short, direct sentences.
- Ask no more than one follow-up question per message.
- Avoid tables, long lists, and lengthy URLs.
- Use emojis and typographic punctuation only deliberately.
- Escalate complex, sensitive, or disputed cases to a person.
Test those rules with real GSM-7 and Unicode examples. A German message containing diacritics may be counted differently from an English-only message; the composer displays the applicable limit.
Practical example: field-service appointment support #
A service company schedules maintenance visits by phone. Some customers later need only a short timing change. The SMS channel can handle that narrow follow-up without replacing the broader phone workflow.
A controlled rollout could work like this:
- The company connects an SMS-capable number and assigns an assistant with a narrowly defined SMS role.
- AI auto-replies stay disabled during setup.
- The team tests messages such as “Tuesday at 3 works,” “Please move it to Wednesday,” and “Call me.”
- The assistant asks only for the information needed to identify and check the appointment.
- Unclear identity, disputes, sensitive data, or exceptions route to a person.
- The person replies in History; AI s for that conversation.
- Automatic replies are enabled only after operational approval.
The SMS history does not prove that the appointment changed in the system of record. That requires an appropriate tool, automation, or manual confirmation. This scenario is a process design, not a measured customer outcome.
Delivery is a status, not a guarantee #
Famulor displays delivery status inside the conversation. Its documentation explicitly warns teams to investigate an unconfirmed delivery before retrying, which helps avoid duplicates caused by delayed status updates.
Twilio also treats delivery information asynchronously. Its Messaging Services documentation provides status changes through callbacks and notes that carrier networks may delay delivery after the platform has handed off the message.
An operating policy should therefore:
- define which status values permit a retry;
- avoid immediate duplication when delivery is uncertain;
- log manual replies and AI resumptions;
- separate technical delivery from business success;
- check carrier and destination-country requirements before rollout.
Consent, STOP, and human responsibility #
A technical connection does not create consent. Famulor states that inbound STOP messages suppress further sending and that resuming depends on the carrier's supported opt-in process.
For traffic sent through Twilio, the current Twilio Messaging Policy requires prior express consent under applicable rules, clear sender identification, and an accessible revocation path. Provider policies are not legal advice and do not replace an assessment of the organization, destination, or use case. Before launch, document:
- where SMS consent came from and which purpose it covers;
- which roles may view the history and reply manually;
- when AI s, when it resumes, and who decides;
- how STOP, failed delivery, and renewed consent are handled;
- which data must never be sent by SMS;
- which retention and deletion rules apply to the history.
Rollout checklist for SMS Conversations #
| Check | Expected result |
|---|---|
| Number | SMS-capable, destination supported, required registration resolved |
| Assistant | Narrow SMS role instead of a copied voice prompt |
| Automation | Off during setup; enabled only after testing and approval |
| Encoding | GSM-7 and Unicode cases stay within one segment |
| Identity | No sensitive disclosure based only on the sender number |
| Takeover | A person can take over; and resume rules are defined |
| Delivery | Unconfirmed states do not trigger blind retries |
| Consent | Purpose, evidence, STOP, and re-opt-in are documented |
| Measurement | Delivery, business outcome, takeover, and errors are evaluated separately |
Start with one narrow service case and a small internal test group. Expand only after encoding, delivery logic, takeover, and consent handling are reproducible.
Frequently asked questions #
Can one Famulor number handle both phone calls and SMS?
Yes, if the number is SMS-capable and eligible for the destination market. Voice and SMS can use different assistants.
Does the SMS assistant automatically inherit a phone call's context?
Not merely because the same number is used. Required context must be made available through the relevant workflow and handled with appropriate identity, consent, and data-minimization controls.
Does AI start replying immediately after setup?
No. Famulor's documentation says automatic replies begin disabled and must be enabled intentionally.
What happens when a team member replies manually?
AI s for that SMS conversation. It can be resumed later.
Does the channel support images or RCS?
No. The current documentation specifies plain text, no attachments, and no RCS.
Is a SIP trunk enough to enable SMS?
No. A SIP trunk alone does not provide SMS. The number needs supported messaging capability.
Conclusion: a channel switch is an operating process #
SMS Conversations adds more than text messaging to Famulor. It creates a controllable transition between AI and the team: visible in History, backed by delivery status, activated intentionally, and d when a person replies.
The central design rule is simple: Do not turn every call into a long text thread. Select the short asynchronous steps that work better by SMS. When segment limits, identity, delivery, consent, and human takeover are designed together, SMS can complement voice AI without copying the phone or chat experience.
About the author #
Sarah Müller writes about voice AI, safe automation, and practical workflows for service, sales, and operations teams.
Writer at Famulor