1,584 reminder texts are not 1,584 results
· Jack Jia · 4 min read
- xona
- dental
- reminders
- measurement
- build-log

We went looking for the next reminder-results post. The production database had enough volume to make the headline easy.
In the 90 days ending August 4, 2026, two clinic accounts produced 1,610 automatic reminder attempts. 1,584 were sent.
That is a real aggregate from a read-only production query. It is also not a result.
A send count answers one narrow question: did the reminder dispatcher create and send the message? It does not tell us whether the patient read it, replied, changed the schedule, or kept the appointment. Publishing “1,584 reminders” next to a revenue or no-show claim would invite the reader to supply a causal link the data does not yet preserve.
So this is the post we can support: where the measurement chain breaks, what has to change, and why we are not filling the gap with an estimate.
The tempting funnel
The same 90-day database window contained 1,288 inbound SMS rows. It would be easy to put that number under the send count and call it a reply rate.
We did not.
None of those inbound rows carries the reminder customer key or the immutable reminder-fire ID. Xona also handles ongoing patient questions, recall, recovery, booking requests, and staff replies over the same SMS infrastructure. Joining an inbound text to the nearest earlier reminder by phone and time would be a guess, especially when a patient already had an active conversation.
The database can prove that the inbound message arrived. It cannot yet prove which specific reminder prompted it.
What the current data can prove
As of the August 4 check:
| Measurement | What we can say |
|---|---|
| Automatic reminder attempts | 1,610 in the rolling 90-day window |
| Sent reminder rows | 1,584 across two clinic accounts |
| Outbound rows linked to the newer immutable fire ID | 66 |
| Reminder-specific inbound reply count | Not defensible from the historical rows |
| Reminder-attributed booking or no-show lift | Not defensible from the current chain |
The 66 fire-linked sends are progress. A recent schema change gives each new automatic attempt durable ownership by an immutable reminder fire. That makes retries, aborted batches, and settings changes easier to audit going forward.
It does not rewrite old rows, classify patient replies, or create a booking outcome retroactively.
The chain a results post needs
A defensible reminder cohort needs more than a start date and a pile of messages. Each row must preserve this chain:
- Cohort: which appointments were eligible, at which offsets, with which exclusions?
- Fire: which version of the clinic’s reminder strategy produced the attempt?
- Delivery: was the message sent, accepted, delivered, blocked, or failed?
- Reply: did the patient confirm, request a change, opt out, ask a question, or reply ambiguously?
- Action: did staff or Xona update the appointment, open a request, or leave work unresolved?
- Outcome: did the appointment remain, move, cancel early enough to refill, or become a no-show?
- Comparison: what baseline makes any change attributable rather than seasonal or operational noise?
If one link is inferred from timing, the result should say so. If the booking outcome is missing, the claim should stop before “lift.”
Why the reply classification matters
“Reply rate” is not one outcome.
A confirmation can protect a slot. An early reschedule request can create time to refill it. A STOP reply is a successful compliance event, not a failed campaign. An ambiguous “maybe” creates staff work. A question about pre-appointment instructions may be operationally useful without changing the booking at all.
Collapsing those states into “engagement” makes a good marketing chart and a poor front-desk metric.
The useful unit is the schedule decision created by the reply—and whether the team could see and act on it while time remained.
What we will claim now
We can describe the reminder mechanism: reviewable rows, clinic templates, skip controls, suppression at dispatch, delivery state, and two-way threads. That workflow is visible in the product and documented in Reminders aren’t text blasts. They’re front-desk control.
We can publish the verified send count with its window and denominator.
We cannot yet publish a reminder-attributed booking lift, no-show reduction, or revenue number. The missing link is not a reason to invent a conservative estimate. It is the next measurement job.
When that chain has run long enough to produce a clean cohort, the results post should be straightforward—and auditable. Until then, 1,584 sends are evidence of operation, not evidence of outcome.
To see the current workflow rather than a made-up lift chart, review the Xona workflow demos or run the free Dental Practice Health Snapshot.