A give-up rule that never measured its wait closed a live thread at 3h50m

“No follow-up if the patient doesn’t show. Everything depends on the front desk.” A clinic owner said that to me, and it describes how many small businesses handle a missed appointment. The no-show happens, nobody is assigned to it, and the day moves on. The slot is empty, and the patient who skipped it has no reason to think anyone noticed.

I want to use that sentence to explain one mechanism: a rule that names a duration but never measures it. I have watched it fail in one of our own systems, and the same failure fits a no-show process exactly.

The rule that closed a live conversation

The rule read: “two messages and no reply.” After two outbound messages with no answer, the conversation was marked closed. The intent was reasonable. Nobody wants a system that messages a silent person forever.

The flaw was in the order of the checks. The rule counted messages and replies, and it ran before any check of the clock. It named a wait (“no reply” implies some time in which a reply could have come) but nothing in the code measured that wait. So it needed zero elapsed time to fire. Two messages out and nothing back yet was enough.

Four conversations were closed permanently that way. Three were closed fifteen hours after the person was messaged. One was closed three hours and fifty minutes after, and that one belonged to somebody who had replied three times, most recently that same morning. The rule saw two outbound messages and no reply to the latest one, and it ended a thread with an active, responsive person in it.

None of this produced an error. The rule ran as written, the log showed a closed conversation, and the state change was clean. Nothing marked the closure as wrong, because as far as the system could tell, nothing was.

Why the quiet version is the dangerous one

A crash gets noticed. Someone sees the traceback or the alert, and the repair starts. A rule that fires early and cleanly leaves no trace of having been wrong. The closed conversations sat in the data looking like ordinary dead leads, which is what a correct version of the same rule would also have left behind. From the outside, premature closure and justified closure look identical.

That is the property I care about: a clean record carries no information about whether the work happened. The absence of an error tells you the code ran. It does not tell you the code did what its description claimed.

The closure was also permanent. A rule that fires too early is a nuisance when the result can be undone. When the state is final, the early firing is a loss, and nothing downstream gets a chance to catch it.

The same shape in a no-show process

Now put the clinic owner’s sentence next to that rule.

Suppose a clinic sets a policy of following up on a no-show within 24 hours. There are three ways that policy can fail without a single error message:

1. Nothing measures the 24 hours. The policy exists in a handbook or a head. When the front desk is busy, the clock is whatever anyone remembers, and a busy day has no spare memory.
2. The condition is checked without the time. An automated check asks “did this patient rebook?” and, on seeing no, marks the case closed or moves on. It never asks whether the window it promised has actually elapsed. This is the exact flaw in my two-messages rule, transplanted.
3. The hold is a human habit. A safeguard that depends on somebody remembering is a deadline nobody set. It will sit there, apparently in place, until the day nobody remembers.

In each case the schedule shows no alarm. The patient who missed the slot simply never appears again, and the record looks the same as a patient who was contacted and declined. A missed follow-up and a declined rebooking are indistinguishable in the data, so the clinic cannot even see how often one is standing in for the other.

What a rule has to do if it names a duration

My position is simple. If a rule’s description contains a length of time, the code behind it must read a clock and compare against that length. A rule that names a duration must be made to measure it. Counting events is not a substitute, because events can arrive early, late, or in a different order than you pictured when you wrote the rule.

Applied to no-shows, that means a few concrete things.

Stamp the event with a time, then act on the stamp. When the no-show is recorded, write the timestamp. The follow-up logic reads that timestamp and compares it to the current time. It does not infer elapsed time from the fact that other things have or have not happened.

Give the follow-up its own deadline. For example, set a 24-hour time-to-live on the rebooking attempt. If no rebooking is confirmed inside that window, the system takes the next step: an SMS or email offering to reschedule, or a task pushed to the front desk naming the patient and the reason. The deadline is stored in the task, so it does not rely on anyone’s recollection.

Make “waiting” a visible state. A no-show that is inside its window should show as waiting, not as closed. Closed should mean something happened: the patient rebooked, the patient declined, or the follow-up window ran out after the attempts were made. If waiting and closed look the same, you have rebuilt the original problem.

Keep the final state for final facts. My rule made a state irreversible and then applied it on a guess. If a patient asks not to be contacted, that is a final fact and permanent closure fits. “We have not heard back yet” is not final, and it should never be able to reach the same state.

Checking your own version

You can test this without any software. Take the last ten no-shows your clinic had. For each one, find the answer to two questions: was there a recorded time at which the follow-up became due, and what record shows that someone acted on it after that time? If the answer to the second question is “the absence of a complaint,” the follow-up is resting on the front desk’s memory, exactly as the owner described.

Then read the rules your own systems use to give up on someone. A rule that stops chasing a no-show after a set number of attempts, or after “a few days,” needs the same inspection I gave my two-messages rule. Find the line that measures the days. If you cannot find it, the rule is counting something else and calling it time.

Practical steps

• Audit the no-show path. Map what happens from the moment an appointment is missed, and mark every step that depends on someone remembering.
• Look for silent outcomes. Check whether anything reports when a follow-up did not happen. If the only signal is silence, add one.
• Measure durations in code. Any rule that says “within 24 hours” or “after two days” should read a timestamp and compare it with the clock.
• Automate the first touch. Send an SMS or email inside a defined window after a no-show, with a clear way to rebook.
• Create time-bound tasks for people. Where a person needs to call, the system should hand them a task with a due time, not rely on them to recall it.

The question I would leave you with is the one my own rule failed: does your give-up rule measure the duration it names?

If this is happening in your business, book a free 30-minute call and we will find where it leaks → https://aethonautomation.com/book?utm_source=blog&utm_medium=organic&utm_campaign=leak-t6