You set up a reminder, a birthday note, a win-back message. Months later you find it has never sent once, and nothing ever told you. Here is how to tell a live automation from a dead one, and the one number that settles it in thirty seconds.

Somebody set up an automatic message. A booking reminder the day before. A note on a guest's birthday. A "we have not seen you in a while" to lapsed regulars.

It went live. Everyone moved on.

⚠️ Months later somebody checks, and it has sent nothing. Not one message. And at no point did anything say so — because an automation that does nothing produces exactly the same silence as an automation that has nothing to do.

The short version

A dead automation and an idle one look identical from the outside
"It is switched on" is not evidence that it has ever run
The settling question is: how many has it sent, ever?
If the answer is zero, find out whether that is correct zero or broken zero
Automations that touch guests deserve a monthly count, not a yearly audit

Why nobody notices

What you would notice	What you do not notice
A message going to the wrong person	No message going at all
A message with the wrong name in it	Silence
A guest complaining	A guest who simply never heard from you

⚠️ Every failure mode that involves sending something gets noticed. The failure mode that involves sending nothing is invisible by construction.

One: the two kinds of zero

This is the whole diagnosis, and it takes thirty seconds.

Correct zero   the automation ran, found nobody who qualified, sent nothing
Broken zero    the automation did not run, or ran and could not send

Both produce "0 messages sent." They mean opposite things.

How to tell them apart

Ask: has it EVER sent one?

⇒ If the lifetime count is zero and the automation has been on for months, that is almost never a correct zero. Over three months, somebody had a birthday.

Two: the count nobody has

Most venues cannot answer "how many has it sent" because nothing keeps the count.

⚠️ A message that is sent and not recorded is indistinguishable from one that was never sent. The record is not bureaucracy — it is the only thing that makes the automation checkable.

What a useful record looks like

When it ran
Who it looked at
Who it decided to send to
Whether the send succeeded

⇒ The third and fourth lines are separate on purpose. "Decided to send" and "sent" fail in different places, and knowing which one broke tells you where to look.

Our own example

We run an automatic message for venues on a free trial — one note before the trial ends, asking if anything is getting in the way.

It was live. It was wired in correctly. It ran on a schedule.

Messages actually sent, lifetime  0
Attempts recorded, lifetime       0

⚠️ Zero attempts, not zero sends. It had never even got as far as deciding. We only found it because somebody asked "will it fire tomorrow?" — and the honest way to answer that was to go and count.

⇒ Nobody had done anything wrong. It was on. It was correct. It simply had never had a day where its conditions lined up, and no part of the system was in a position to notice that.

Three: the conditions nobody re-reads

Most dead automations are killed by a condition that was reasonable when written.

"Send the day before the trial ends"
"Send on the guest's birthday"
"Send if they have not visited in 90 days"

⚠️ Each of those looks simple and each hides an assumption.

Where they break

Dates      time zones - "the day before" can land on the wrong day
Fields     birthday is blank for most guests, so nobody qualifies
Thresholds "90 days" measured from a field nobody fills in

⇒ In our case the date logic was off by a day, because the clock used to decide "which day is it" was not in the same time zone as the people who wrote the rule. The rule said one day before. It behaved as same-day.

The check

Take the condition. Work out who qualifies TODAY.
Then ask the system who it thinks qualifies today.

If those two lists differ, you have found it.

Four: automations that touch guests need a tighter leash

Not all automations carry the same weight.

Internal    a report that fails to generate - annoying
Guest-facing a message that fails to send - a relationship, quietly not maintained
Money       a charge or a refund that fails - the worst kind

⚠️ Guest-facing ones are the middle case and the most commonly broken, because their failure produces no complaint from anybody.

⇒ On the broader habit of testing the check rather than the thing: the check that quietly stopped.

Five: the opposite failure — it sends and you did not know

Worth naming, because it is the same blind spot from the other side.

An automation can also keep sending after you have decided to stop. Somebody agrees "we will not contact that guest again," and the automatic reminder goes out the next morning regardless, because the decision lived in a conversation and the automation lived in the system.

The decision   made by people, in words
The automation runs on conditions, in software

⚠️ They are not connected unless somebody connects them.

⇒ This is the same gap as a stop that only one person can pull — covered in who can say stop. A decision that lives only in a conversation cannot reach a schedule.

The question to ask after any "we won't contact them" decision

"Is there anything automatic that will message them anyway?"

⇒ We hit exactly this yesterday: a decision not to contact a customer, made in the afternoon, with an automatic message scheduled to reach them at 5:30 the next morning. Nobody was wrong. The two facts simply lived in different places.

Six: the thirty-second audit

For each automation you rely on, ask three questions.

One   How many has it sent, ever?
Two   When did it last send one?
Three If it sent nothing this month, is that correct?

⚠️ Question two is the sharpest. "Last sent: never" and "last sent: four months ago" both point at something worth looking into, and neither requires you to understand how it works.

If your system cannot answer

That is itself the finding.

Cannot answer "how many"  - there is no record, so nothing is checkable
Cannot answer "when last" - same

⇒ Ask your provider for the count. If there is not one, that is a reasonable thing to request — it is the difference between an automation you rely on and one you hope about.

Seven: what to do when you find a dead one

Resist the urge to rebuild it immediately.

One   Find out whether it ever worked (the count tells you)
Two   Work out who SHOULD have received it in the last month
Send  that list by hand, if it still makes sense
Then  fix the automation

⚠️ Step three is the one that recovers value. The automation being broken is yesterday's problem. The guests who did not hear from you are today's.

⇒ If the message would now be strange to receive — a birthday note three months late — do not send it. An automation catching up loudly is worse than one that was quietly absent.

Numbers worth keeping

One   For each automation: lifetime sends, and last send date
Two   How many automations you rely on that cannot answer question one
Three How many guest-facing automations you have (count them - it is usually more than you think)

⚠️ Two is the real number. An automation that cannot be counted is a belief, not a control.

⇒ On the general principle that a confirmation is not an outcome: the edit that said saved.

The card for the office

────────────────────────
  Is this automation alive?

  1. How many has it sent, ever?
  2. When did it last send one?
  3. If zero this month - is that correct?

  Zero sends and zero attempts
  is not an idle automation.
  It is one that has never run.
────────────────────────

Common objections

"It's switched on, so it's working"

⚠️ On means it will run when its conditions are met. It says nothing about whether those conditions have ever been met, or whether they can be.

"We'd have heard if guests weren't getting messages"

⇒ From whom? A guest who does not receive a reminder does not ring to report a missing message. They just do not turn up, and that looks like an ordinary quiet night.

"Our provider would tell us"

⚠️ Most providers report failures, not absences. A message that was never attempted generates no error to report.

"We checked it when we set it up"

⇒ Setting it up and watching a test message arrive proves the plumbing. It does not prove the condition ever selects anybody. Those are the two halves, and only the first gets tested.

"The screen would be slow to check anyway"

⇒ That is a real obstacle and worth naming rather than working around — a check that is painful to run stops being run, which is the shape described in the report that takes too long to open.

"This feels like a lot of checking"

⇒ Three questions per automation, once a month. For most venues that is four automations and about five minutes.

What to do this week

One   List every automatic message that can reach a guest.
Two   For each, get the lifetime count and the last send date.
Three Any showing zero - work out who should have qualified.
Four  Where the answer is "somebody should have", you found one.
Five  After any "we won't contact them" decision, ask what is scheduled.

Summary

A dead automation and an idle one look identical from outside
The settling question is "how many, ever?" — not "is it on?"
Zero attempts is different from zero sends, and far worse
Conditions break on dates, blank fields, and thresholds nobody re-reads
The reverse failure is real: automations keep sending after you decide to stop
An automation that cannot be counted is a belief, not a control

Nothing tells you when an automation does nothing. That is the entire problem, and the only cure is to go and count.

The Automatic Message That Never Sent