When an automation email doesn't send — Help

An automation that says it is running, an empty Sending soon queue, and nothing in the client's inbox. It is the single most unsettling thing an automation can do, because a correct skip and a broken rule look exactly the same from the outside.

This article covers why a client email might not have gone out, what 1pm now tells you when it cannot send one, and the button that lets you send it by hand when the schedule has already sailed past.

First, the boring explanations

Most of the time the automation is fine and one of these is the answer:

It is still in the review queue. Every client email on a date based automation waits 24 hours in Sending soon before it goes. If it is listed there, it is going. That queue is on the Automations page.
The automation is switched off. New automations start off. So does anything you paused. The list shows an On or Off badge on every rule.
The booking is not confirmed. Date based automations only ever run against committed bookings. An event still sitting at Enquiry or Tentative is skipped, on purpose, because a pencilled date is not something to email a client about.
The lead type filter does not match. If the automation is scoped with Only for this lead type, an event whose original enquiry came in on a different form is skipped.
Someone cancelled it. A queued email that was cancelled from Sending soon will not be retried for that event.
It sent, and the client never saw it. A different problem with the same symptom. The Emails page shows whether it was delivered, bounced or refused before it ever reached the provider.

After-event automations now run on completed bookings

Marking a finished event Completed is the obvious thing to do to a finished event. Until recently it also silently killed every automation attached to it, because date based rules required a status of Confirmed and Completed is not Confirmed. Thank-yous, feedback requests and rebooking nudges all stopped, and nothing told anyone, because from the sweep's point of view the event had simply stopped existing.

It bit hardest on the best after-event automation there is. "A year on, shall we do it again?" can only ever run against an event long finished, and therefore almost certainly marked Completed, so that one could never have fired at all.

The rule is now split by direction:

X days after the event runs against Confirmed or Completed bookings. An event being done is not a reason to stop the follow-up. It is the reason there is one.
X days before the event still requires Confirmed only. An event already marked done has no future left to count down to.

The check 24 hours later, when a queued email actually sends, accepts either status too, so tidying up an event the morning after no longer turns your own queued thank-you into a failed run. It still catches a genuine cancellation, which is what that check was written for.

If you have been marking events Completed as you go, it is worth opening your after-event automations and checking they say what you still want them to say. They will start running again.

When there is nobody to email

A client email needs a client. If an event has no Client contact set, or that contact has no email address, there is nothing 1pm can do with the email, and the right behaviour is to skip it.

What was wrong was doing that silently. So now, when the sweep hits an event it cannot email:

It writes a failed row in Recent activity, at the foot of the Automations page, naming the reason rather than claiming it "emailed the client". The two reasons you will see are "This event has no client contact set, so there was nobody to email" and "The client contact on this event has no email address".
It rings the bell once, with a link straight to the event, because Recent activity is a page nobody opens unless they already suspect something is wrong. See notifications and the bell.

You do not get an email about it. The gap is worth knowing about, not worth an inbox interruption.

The fix is to set the Client contact on the event, or add an email address to the contact you already picked. That does not re-arm the automation for that event, because each rule fires once per event and the failed row counts as that one firing. Send it by hand instead, which is the next section.

Crew emails skip differently, and more quietly

Everything above is about the client rail: an event date, a client contact, a queued email you can see in Sending soon. The other half of Automations, the rules that email crew off a request (someone finished their requests, self-registered, had an upload rejected, has a certificate about to lapse), has its own set of reasons for not sending, and its own badge for them.

Three checks run before that kind of email is composed:

The crew member has no email address on their contact record.
You are over the daily email ceiling.
You are over the monthly allowance.

Failing one writes a Skipped row in Recent activity, naming the reason in place of the recipient. Unlike the client rail there is no bell, because these are usually a batch rather than a one-off: an allowance that ran out mid-run skips everyone left, and twenty notifications would be worse than one honest list.

Skipped is deliberately not Failed, and the difference matters. A skip does not use up that crew member's one firing, so fixing the address, or waiting for the allowance to reset, leaves the rule able to send to them next time it is triggered, replacing the skipped row. A failed run is a real attempt and stands as one.

Note also that an unverified account email does not stop automations. It stops the sends you press a button for (a crew invite, a bulk invite, a rejection notice, a crew status update), because those check the signed-in user. A rule running unattended has no signed-in user to check, so it sends regardless.

Worth knowing if you have been running request automations for a while: none of that family appeared in Recent activity at all until August 2026. The runs were recorded, they simply were not shown, so the page will look thin for anything that fired before then and normal from there on.

Recent activity holds the last 25 runs

Worth knowing before you conclude a rule never fired: the table is capped at the 25 most recent runs across every automation on the account. On a busy week a run from a few days ago can have scrolled off it entirely. The Emails page keeps far more history and is the better place to answer "did this ever go out at all".

Sending an automation email by hand

Some emails can never arrive on schedule, however well the rule is written.

A "14 days before the event" automation matches one calendar date. A wedding booked seven days out has already missed it, and waiting does not help: that date is in the past and will not come round again. The same is true of any event that lands inside its own automation's lead time, which for most venues is a decent share of the corporate work.

So a client email from any date based automation can be sent by hand, for one booking, whenever you want it.

Where it lives. Open the contact in Contacts and go to their Bookings tab. Every booking they are attached to is listed. On the rows where that contact is the booking's client, there is a Send automation button.

It only appears on client rows on purpose. The tab also lists bookings the contact merely crews, and on those the client email would go to somebody else entirely, so offering it there would be actively misleading.

Step 1, pick the email. The dialog lists every client email you could send, one entry per email rather than per automation, so a two step drip offers both of its emails with Step 1 and Step 2 badges. Each row shows the automation's name, its subject, and a line reminding you what it normally fires on. Only automations that are switched on are listed: this is a shortcut for running a rule you already have, not a general compose window. Your seeded default automations are included.

Step 2, read it. The preview shows the actual merged email for this booking: recipient, subject, the body with every merge field filled in, and any attachments listed by name. This preview is the review step, which is why there is no 24 hour hold on the send. You just read the thing.

One detail: if the email uses the client's private link and this client does not have one yet, the preview says "Their private link is created when you send" rather than quietly creating one. Live links are counted as usage on your account, so previewing five automations and sending none should not cost you anything. Sending does create it, which is the whole convenience of the link.

Step 3, send. Send now sends it immediately, into the client's conversation in Leads, so their reply comes back where every other reply from them does. The button disables itself while it works, because unlike the scheduled path a hand send is allowed to happen twice, and a double click would be a second real email.

When the Send button is not offered

The dialog explains rather than failing, so you will get one of these instead of a Send button:

"This booking isn't confirmed yet." Client automations only send for confirmed or completed bookings. This is not just for consistency with the sweep. Sending against a pencilled booking would create the client conversation behind it and mark that lead converted, quietly moving it into the won column of your pipeline, which is not what pressing send on a reminder should do.
"This booking has no client contact set", or "the client contact no longer exists", or "[name] has no email address". The same three gates the sweep applies, checked here so the dialog can tell you the fix rather than offering a button that fails.
An attachment problem. If a file the automation attaches cannot be read, the send is blocked outright rather than emailing the client a pack with the file missing. The message names the file. This is the same rule everywhere in 1pm: an email that is supposed to carry an attachment is never sent without it.

You have no automations that email the client on a date before or after the booking means exactly what it says. Build one on the Automations page and it will appear here.

Telling a hand send apart afterwards

In Recent activity on the Automations page, an email sent this way carries a Sent by hand badge next to the automation's name. Without it, a "14 days before" automation showing a send from today would read as the schedule misfiring, when in fact somebody pressed a button.

Everything else about it is the same as a scheduled send. It threads into the client's conversation, it appears on the Emails page, and replies come back to Leads.

Automations covers the full trigger and action set, the review queue and Recent activity.
Chasing a lead that goes quiet covers the funnel stall chases, which run off leads rather than event dates.
When a quote runs out covers the quote validity chases.
Checking what emails went out is where to look when an email was sent but the client says it never arrived.
Notifications and the bell covers the bell an unsendable automation now rings.
Adding contacts covers the contact record whose Bookings tab holds the hand send button.
Event confirmations covers getting a booking to confirmed, the point at which date based automations start running against it.