Sources: 3 · Verified 2026-10-22
A clinic changes the reminder from 48 hours to 24 hours and sees fewer no-shows. The improvement may be real. It may also be a busier week, a different patient mix, or a seasonal change. A small local test can support a decision if it is designed before the change.
Workflow at a glance
| Factor | Details |
|---|---|
| Unit | Booked appointment |
| Intervention | One timing change at a time |
| Outcome | Attendance and reschedule |
| Limit | No broad causal claim |
Research question and scope
The question is whether a local reminder-timing test can support an operational decision without overstating causality. Scope covers a single clinic or provider group with a stable template and consent policy. The unit is a booked appointment. The test compares a baseline period with a test period and records delivery, response, cancellation, reschedule, and attendance. The scope also fixes what counts as delivery and what counts as response. Delivery means the message reached the contact channel the patient consented to use, not that the patient read it. Response means the patient replied, confirmed, cancelled, or rescheduled through a recorded path. Attendance means the patient was seen or the visit was completed under the clinic's definition. These are separate outcomes, and a test that reports only messages sent has not measured the thing it claims to improve. The design also states the inclusion rule for patients without a usable contact method, because excluding them can make delivery look better than the clinic's real reach. Consent and opt-out rules stay fixed during the test. If consent rules change, the comparison breaks. The test is local by design, so the report names the clinic, the period, and the population.
Required scheduling checkpoints
| Category | Specific Tasks | Planning Estimate / Note |
|---|---|---|
| Baseline |
| Before the test |
| Assign |
| Before the change |
| Run |
| Test period |
| Review |
| After the test |
- Category
- Baseline
- Specific Tasks
- Measure the current timing
- Record the outcome
- State the period
- Planning Estimate / Note
- Before the test
- Category
- Assign
- Specific Tasks
- Choose the comparison group
- Avoid mixing providers
- Record the rule
- Planning Estimate / Note
- Before the change
- Category
- Run
- Specific Tasks
- Apply one timing change
- Log delivery and response
- Keep other rules stable
- Planning Estimate / Note
- Test period
- Category
- Review
- Specific Tasks
- Compare outcomes
- State the limits
- Decide next step
- Planning Estimate / Note
- After the test
Evidence and decision controls
| Decision factor | Manual process | Documented workflow |
|---|---|---|
| Design | Before-and-after memory | Defined baseline and test |
| Changes | Several at once | One timing change |
| Outcome | Messages sent | Attendance and reschedule |
| Claim | Proves causation | Supports a local decision |
Design
- Manual process
- Before-and-after memory
- Documented workflow
- Defined baseline and test
Changes
- Manual process
- Several at once
- Documented workflow
- One timing change
Outcome
- Manual process
- Messages sent
- Documented workflow
- Attendance and reschedule
Claim
- Manual process
- Proves causation
- Documented workflow
- Supports a local decision
Why before-and-after is not enough
A before-and-after comparison without a baseline definition and a stable period invites confounders. A holiday week, a new provider, or a change in consent rules can move the outcome. The design does not need a randomized trial, but it does need a written baseline, one change, and a stated limit. A comparison group helps even without random assignment. One option is to alternate weeks between the current timing and the new timing, keeping the template and channel fixed. Another is to apply the change to one provider group or one visit type while a similar group continues unchanged. Neither design removes every difference, but both make the comparison visible. The team should record the number of appointments in each arm, the delivery failure rate, and the share of visits that were rescheduled rather than missed. If delivery failed for a large share, the timing question cannot be answered from that period. Seasonality, holidays, staffing, and weather are stated as limits rather than adjusted away. The report should say what result would lead the team to revert, and that rule should be written before the data arrive. This keeps the decision from being made by the most recent anecdote.
Reading the result
Compare the attendance and reschedule rates, the delivery failure rate, and the mix of visit types. If the test period had a different case mix, the comparison is weaker. Record the decision: keep, revert, or test a different window. Do not present a local result as a universal best practice. Before reading the rates, check that the two periods have a similar share of new and returning patients, visit types, and booking lead times. A change in lead time can matter because a reminder sent 24 hours before a visit booked months ahead reaches a different patient than one booked the day before. If the mix moved, report the stratified result as well as the overall figure. Look at the delivery failures first, then the reschedule and cancellation counts, then attendance. A rise in reschedules may be a better outcome than a no-show if the slot was recovered, so the categories should not be collapsed. Record the decision in one paragraph: keep the new timing, revert, or run a second period. Attach the definitions and the dates so a later reader can tell what was compared.
Quality controls
| Success Factor | How To Do It | Results You Get |
|---|---|---|
| Baseline | Measure before changing | A real comparison |
| One change | Keep templates and policy stable | The result is interpretable |
| Same period | Compare similar weeks | Less seasonal noise |
| Written limit | State what the test cannot show | Honest decision |
- Success Factor
- Baseline
- How To Do It
- Measure before changing
- Results You Get
- A real comparison
- Success Factor
- One change
- How To Do It
- Keep templates and policy stable
- Results You Get
- The result is interpretable
- Success Factor
- Same period
- How To Do It
- Compare similar weeks
- Results You Get
- Less seasonal noise
- Success Factor
- Written limit
- How To Do It
- State what the test cannot show
- Results You Get
- Honest decision
Limits of the evidence
The test cannot prove that timing caused the change for every patient. It cannot rule out seasonality or a simultaneous workflow change. It does not measure patient preference or satisfaction unless those are collected separately. It is a local decision aid, not a published benchmark. The test also cannot show which patients benefit. A change that helps one group may do nothing for another, and a single overall rate can hide that. The test does not measure whether a message was understood, whether the patient wanted a different channel, or whether the reminder arrived at a convenient time. Those questions need patient input collected separately and with consent. The design does not establish a best interval, and a local result should not be presented as a standard for other clinics. It also cannot separate the effect of timing from the effect of a new staff member answering replies. When several things change, the honest report says so and treats the result as a prompt for a cleaner test. A small difference should be described as a signal, not a proven effect.
What this means for a scheduling team
A small, honest test is better than a confident anecdote. The team can improve reminders while keeping consent, template, and policy stable. The result belongs in the clinic's own operating record, with the period and definitions attached. The team also owns the decision record. Writing down the baseline, the one change, the confounders, and the rule for reverting turns a reminder experiment into an operating asset that survives staff changes. It also keeps the team from repeating the same test every year without remembering what happened. Consent and contact preferences stay visible in the same record, so a timing change is not made at the expense of a patient who asked for a different channel. The result should be shared with the people who answer patient replies, because they see the failures the report counts. A short review with the front desk can explain a delivery failure or a wave of reschedules. The measure is modest by design, and that modesty is what makes it usable. That record also gives a new coordinator a starting point instead of a rumour.
Research methodology
This paper defines a local test design. It specifies a baseline period, one timing change, stable templates and consent rules, and outcome measures. It states the limits of a before-and-after comparison and does not claim a universal best reminder interval.
This is a local test design. It does not report a result, a benchmark, or a causal estimate.
Data sources and methodology
This brief reports published findings as stated by each source. It does not combine study populations into a new benchmark; local operators should treat the figures as context and measure their own workflow.
- AHRQ: Quality improvement: Test-of-change context
- FCC: Robocalls and texts: Contact consent context
- NIST Privacy Framework: Data handling
Related content
Frequently asked questions
How long should the test run?
Can we change the template and timing together?
What outcome should we measure?
Test reminder timing with a baseline
If the team wants to change reminder timing, measure the current state first and change one rule at a time.
Book a Free Consultation →



