Integrations

Twilio SMS Integration

SMS is the channel most dental patients actually answer, and Twilio Programmable Messaging is the infrastructure most healthcare messaging runs on. Using it well for intake is less about sending messages than about handling replies: an intake conversation is two-way by definition, and the difference between a reminder system and an intake system is whether anything happens when the patient writes back.

Why SMS outperforms email and forms for intake

The comparison is not really about the medium, it is about response latency and the cost of a second attempt. An emailed form link is a single event: it lands, and it is either completed or it is not. Following up means sending the same link again, which patients read as nagging.

A text conversation can be resumed. A patient who answers three questions on the bus and stops can be asked the fourth that evening without the whole thing restarting. That resumability is what raises completion on the fields patients cannot answer immediately, the group number on a card in a drawer at home is the canonical example.

Setup steps

Most of the work in a Twilio messaging setup is regulatory rather than technical. In the US, application-to-person messaging on standard ten-digit numbers requires A2P 10DLC registration, and skipping it results in filtered or blocked messages rather than an error you notice immediately.

Create or identify the Twilio account and confirm who owns the billing relationship, the practice or the vendor. This matters for number portability later.
Register the business entity with The Campaign Registry through Twilio. This requires legal business name, EIN, and address, and takes days rather than minutes.
Register the campaign describing the use case (patient intake and appointment-related messaging) with sample message content.
Provision a number and attach it to a Messaging Service. Use a Messaging Service rather than a bare number so sender pools and compliance features are available.
Configure the inbound webhook so replies reach the intake logic rather than disappearing.
Verify STOP, HELP, and opt-out handling. Twilio handles the standard keywords, but the practice's own records must reflect an opt-out or the patient gets messaged from another system next month.
Test the full round trip on a real handset before any patient sees it, including a reply arriving hours after the initial message.

Workflow example: a two-day intake conversation

Day one, mid-morning: the patient receives an introduction identifying the practice by name and asking to confirm their date of birth and address. They reply within a few minutes.

Day one, continued: insurance questions. The patient supplies the carrier and their member ID from memory, and says they will have to check the group number. Rather than treating the conversation as failed, the flow records what was captured, notes the gap, and schedules a follow-up.

Day one, evening: a short follow-up asks only for the outstanding field. The patient, now at home with the card, replies.

Day two: health history questions in a small number of short messages rather than one long block. A 'yes' on the medications question triggers a follow-up asking which ones, which a static form could not do.

Throughout: each answer is written back to the patient record, so the coordinator sees a chart filling in rather than a message thread to read.

What SMS is not the right channel for

Being specific about the limits prevents the common mistake of forcing everything through one channel. SMS is poor for anything that needs a long explanation, anything genuinely urgent, and anything where the patient's tone matters, a patient who is anxious about cost or in pain should reach a person.

It is also not the right channel for every patient. Some patients do not text, and a practice that routes all intake through SMS will systematically under-serve them. The design intent is that the channel follows the patient's stated preference, with voice as a first-class alternative rather than a fallback for failures.

Compliance considerations

Two separate regimes apply and practices sometimes only think about one. Telecom rules (10DLC registration, opt-out handling, consent to be messaged) govern whether messages get delivered at all. Health information rules govern what may be sent and how it is retained.

The practical implication is that message content should be minimal: identify the practice, ask the question, and keep clinical detail in the record rather than in the thread. Any deployment handling patient information should have the specific configuration reviewed against your practice's compliance requirements before going live, rather than after.

Frequently asked questions

Do we need our own Twilio account?

It depends on how you want number ownership and billing handled. Practices that want to keep the number if they change vendors generally prefer owning the account; practices that want one less thing to administer generally do not. Decide before registration, because moving a registered campaign afterwards is more work than setting it up correctly.

How long does A2P 10DLC registration take?

Days, sometimes longer if the business details submitted do not match registry records exactly. It is the single most common cause of a delayed launch in SMS projects, so it is worth starting before the rest of the rollout is scheduled.

What happens if a patient replies STOP?

Messaging to that number stops immediately at the carrier level, and the opt-out must also be recorded in the practice's own records so other systems do not message them. Patients who opt out of SMS should be routed to voice rather than dropped from intake entirely.

Can patients send photos of their insurance card?

MMS makes it technically possible, and it removes transcription errors on member IDs. Whether to enable it is a data-handling decision, an image of an insurance card is patient information and needs to be treated with the same care as the fields it contains.

Planning SMS intake? Book a call and we will walk through 10DLC registration and the channel-preference logic before you provision anything.

Book Call