A patient gets your confirmation text. They mean to confirm, or they mean to cancel, or — most usefully — they want to move the appointment. And they reply the way humans actually reply: "cant make it thurs, can we do fri?" or "sorry running behind this week" or just "yeah."
If your reply flow only understands C, Y, 1, and STOP, every one of those messages falls into a no-response bucket. The patient thinks they told you. You marked them silent. Thursday's chair sits empty and nobody dialed them because, as far as the system knew, they never answered.
Full disclosure: I work for Ready, an SMS platform. This isn't a pitch for magic — reply parsing is genuinely hard and no system nails every message. But there's a wide gap between "match exact keywords" and "read what the patient meant," and most clinic setups live on the wrong side of it.
Keyword matching drops the messages that matter most
A strict keyword parser is a lookup table. It sees a reply, checks it against a short list, and if there's no exact hit it does nothing — or worse, files it as "no response" and triggers the no-show workflow.
Here's what a table like that actually catches versus what patients actually send:
| Patient sends | Keyword parser reads | What they meant |
|---|---|---|
C | Confirm | Confirm ✅ |
yeah | (no match) | Confirm ❌ |
see you then | (no match) | Confirm ❌ |
cant make it thurs | (no match) | Reschedule ❌ |
need to move to next week | (no match) | Reschedule ❌ |
cancel pls | (no match, unless "cancel" is listed) | Cancel ❌ |
STOP | Opt-out | Opt-out ✅ |
The confirm case gets a lot of attention — we wrote a whole post on why a patient replying 'Yeah' instead of 'C' books as a no-response. But the reschedule case is where the money leaks. A confirm that reads as silence is annoying. A reschedule that reads as silence is a chair you could have re-filled and didn't.
Intent parsing: read the meaning, not the string
The fix is to classify replies by intent instead of matching them by exact text. You're sorting each inbound message into a small set of buckets:
- Confirm — "yes," "yeah," "see you then," "confirmed," "👍,"
C,1 - Reschedule — "can't make it," "need to move," "different day," "reschedule," "can we do Friday"
- Cancel — "cancel," "not coming," "won't be there"
- Question — "do I need to fast," "where do I park," "how long does it take"
- Opt-out —
STOP,UNSUBSCRIBE, "quit," "stop texting me" - Unclear — anything the classifier isn't confident about
The reschedule bucket is the one worth engineering carefully, because a good reschedule response recovers revenue the same day. Instead of dumping the patient into a "call us back" dead end, you fire the slot-offer flow — the one where you offer three specific times by text and let them pick one. That flow fills the chair the no-show would have emptied, and it fires automatically because the intent was read correctly in the first place.
Ready's optional AI reply agent does this classification on inbound messages. It runs in three modes — off, suggest (drafts a reply for a staffer to approve), and auto (sends without a human in the loop). For a clinic, I'd start every intent except the simplest confirmations in suggest mode. More on why below.
Route to staff, don't auto-answer everything
Reading intent correctly is half the job. The other half is deciding what to do with it — and "auto-reply to everything" is the wrong default in healthcare.
A rough routing map that works:
- Confirm → auto-acknowledge ("Great, you're all set for Thurs 2pm — reply if anything changes"). Low risk, high volume, fine to automate.
- Reschedule → auto-fire the slot-offer flow, then route to staff if the patient doesn't pick a slot within a window.
- Cancel → auto-acknowledge and release the slot, then route to staff for recall follow-up.
- Question → route to a human. Clinical or logistics questions are where an over-eager bot embarrasses you or, worse, says something wrong about a procedure.
- Unclear → route to a human, always. If the classifier isn't confident, a person reads it.
The whole thing lands in Ready's two-way conversations inbox, and for clinics on GoHighLevel it syncs both directions into the location's inbox — so the front desk sees the thread whether they're working in Ready or in GHL, and each client location stays isolated. A staffer picking up an "unclear" reply has the full history in front of them, not a decontextualized fragment.
If you want the labor argument for why text-first triage beats calling everyone back, confirming by text ends in one reply where phone tag takes three voicemails lays out the math.
STOP always wins — intent parsing does not get a vote
Here's the rule that overrides everything above: opt-out handling is not an intent to be classified. It's a hard stop that runs first.
If a patient texts "STOP," the system does not get to decide the message "seems more like a reschedule." It honors the opt-out, full stop. In Ready, inbound STOP/UNSUBSCRIBE is handled automatically and the opt-out propagates — the contact can't be messaged again across campaigns, not just the one they replied to. That's a compliance floor, not a preference.
Why this matters for intent parsing specifically: a smart classifier is pattern-matching on meaning, and you never want that logic anywhere near opt-out. The order of operations has to be:
- Check for opt-out keywords first.
STOP,UNSUBSCRIBE,QUIT,CANCEL(as an opt-out),END. Honor it. Done. - Only then run intent classification on everything that isn't an opt-out.
Bury opt-out inside the AI classifier and eventually it mis-scores "stop texting me about the flu shot" as a reschedule question. That's a TCPA problem, and TCPA exposure runs $500–$1,500 per text. Keyword-based opt-out is the one place where dumb, literal matching is exactly right.
The same discipline applies to the consent side. A confirmation-flow opt-in doesn't automatically cover a wellness blast — a two-way confirm text and a broadcast recall sit on opposite sides of your consent wall, and reply parsing doesn't change that. Quiet-hours enforcement, DNC/litigator scrubbing, and consent attestation all still apply regardless of how clever your reply reading is.
Start in suggest mode, measure, then loosen
Don't flip the AI reply agent to full auto on day one. Run it in suggest mode for a few weeks. Every inbound reply gets a drafted classification and response; a staffer approves or corrects. That does two things:
- You catch misclassifications before they reach a patient.
- You build a record of where the parser is reliable (confirms, clear reschedules) versus where it wobbles (clinical questions, ambiguous "hmm let me check").
Then move only the high-confidence, low-risk buckets to auto — confirmations, slot-offer fires — and keep questions and unclear replies routed to humans indefinitely. There's no prize for automating the message that needed a nurse.
Timing feeds into this too. A reply parser is only useful if the reminder went out early enough to act on the answer — a reminder 72 hours out gets rescheduled; one 2 hours out just gets a no-show. Parse a "can't make it" 72 hours ahead and you rebook the chair. Parse it two hours ahead and you're just documenting the loss.
The practical takeaway
Keyword-only parsing quietly files real answers as silence, and the most expensive one it drops is the reschedule. Move to intent classification, route questions and anything unclear to a human, and auto-handle only the confirms and slot-offers you'd trust a temp to run. And keep opt-out handling as a literal, first-in-line keyword check that no classifier gets to override.
If you're on GoHighLevel and want inbound replies to land in both inboxes with STOP, quiet-hours, and consent handling built in, that's what Ready's two-way messaging and optional AI reply agent are for — see how it's put together, or start with the 2,500 free credits and run the whole flow in suggest mode before you trust it with a patient: sign up here. The parser earns full auto by proving it deserves it, not before.