Automations fail quietly, and the quiet is the problem.
A sequence runs. Five hundred people enter it. The dashboard says five hundred messages sent. A hundred and twenty arrived. Nobody notices, because nothing errored: every message was handed to a platform that accepted it, and acceptance was recorded as success.
Skipped is an outcome, and it needs a name
There are three things that can happen to a message an automation tries to send, and most tools only model two.
- Sent, and delivered. The good case.
- Failed. Something errored. Usually visible, usually investigated.
- Skipped. The system decided, correctly, that this message could not or should not be sent to this person right now.
The third is the common one, and the one that gets folded into the first. It is not a failure and it is not a success, and forcing it into either produces a number nobody can act on.
The reasons are mundane and mostly knowable before sending:
- The messaging window with that contact has closed, so only a pre-approved template would get through
- The contact never consented to marketing on that channel
- The channel is not connected for that workspace
- The template exists but cannot be sent in its current shape
- The contact has already received this message
Every one of those is a legitimate reason not to send. Every one of them is also a fact the business should be able to see, because most of them are fixable and none of them fix themselves.
Decide before, not after
The design decision underneath all of this is when the check happens.
If the automation sends first and interprets the result afterwards, the failure is invisible: many messaging platforms accept a message they will later drop, and the acceptance is what gets recorded. The rejection arrives minutes later on a webhook that nothing was listening for.
If the automation checks first, it knows before sending that this message cannot arrive, and it can record that with the reason. The customer's experience is identical. The business's is completely different: instead of a green number, they have a list that says two hundred and eighty contacts were skipped because the messaging window had closed, which is an actionable sentence.
A number that only ever goes up is not a metric. It is decoration that happens to be numeric.
What honest reporting looks like
It is not complicated, and it is mostly a matter of refusing to round in your own favour:
| What happened | What it should say |
|---|---|
| Platform accepted, delivery confirmed | Delivered |
| Platform accepted, delivery never confirmed | Sent, not confirmed |
| Not attempted, reason known | Skipped, with the reason |
| Attempted, rejected | Failed, with the code |
Four states instead of one, and each of them is a different decision for whoever reads it. "Skipped: outside the messaging window" tells a marketing team to change when the sequence runs. "Failed: template rejected" tells them to fix a template. "Sent, not confirmed" tells an engineer that nothing is listening to the delivery webhook.
Collapsing all four into "sent" tells them nothing, and worse, tells them nothing while looking like it told them something.
The cultural half
There is a version of this that is not a technical problem. Reporting the truth means reporting worse numbers than the competitor whose dashboard counts acceptances, and that is a genuinely uncomfortable position for a product to take.
It is still the right one, and the reason is practical rather than moral: a business that cannot see its skipped messages cannot fix the reasons for them, so its real delivery rate stays where it is forever. The flattering number is the thing standing between it and a better one.
Summary
- Skipped is a third outcome and needs its own count and reason.
- Check before sending. After the fact, the failure is invisible.
- Four states, not one: delivered, sent-unconfirmed, skipped, failed.
- The uncomfortable number is the one you can act on.
