Your automation does not know what time it is for the customer
Scheduling a campaign feels like a decision about your calendar. Tuesday morning, ten o'clock, when people are at their desks.
There is a rule in the US that reads the clock differently. 47 CFR 64.1200(c)(1) says: "No person or entity shall initiate any telephone solicitation to any residential telephone subscriber before the hour of 8 a.m. or after 9 p.m. (local time at the called party's location)."
The phrase that matters for anyone building automation is the one in brackets. Not your local time. Not the platform's. Theirs.
This is not legal advice, and the scope is narrower than it first looks — it covers telephone solicitation to residential subscribers, which is marketing rather than the confirmation of an appointment somebody just booked. But the underlying question applies to every business that sends automated messages: does your workflow know where the recipient is, and does it care what time it is there?
For most small businesses the honest answer is no on both counts. The workflow knows a phone number and a send time in the account's time zone. That is the whole model.
Why this is a data problem first
Compliance work usually gets imagined as a policy: we will not message people early. Then it turns out the system cannot express the policy, because the information is missing.
The account time zone is the only one in the room. Set once, at setup, probably by whoever created the account. Every schedule you write is implicitly in it.
Nothing records where the customer is. A phone number is a weak hint at best, and it stops being one the moment somebody keeps a number after moving. An address, if you have one, is better — but it is often the billing address, which is not where the person is standing.
Delays make the send time drift. A campaign that starts at nine and works through a queue for two hours ends at eleven for the last recipient, and a retry after a failed send can land somewhere else entirely.
Nobody logs the local time of delivery. So even after the fact, you cannot answer the question "what time was it for them?" — which is the only version of the question that matters.
What to do without turning it into a project
Decide which of your messages are marketing. Promotions and offers sit on one side; the receipt, the appointment confirmation, the delivery notification sit on the other. Different rules and different urgency, so they should not share a schedule or, ideally, a sending account.
Store a location or a time zone against the contact. One field, filled at signup where you can, defaulted where you cannot. Everything else here depends on having it.
Put a floor and a ceiling on the sender. No marketing message leaves the system before 8am or after 9pm local to the recipient, enforced in the workflow rather than remembered by the person scheduling it. Where you do not know the recipient's zone, the safe default is your narrowest reasonable window rather than your own working day.
Queue rather than drop. A message that would land at 6am waits until the window opens. This is a small piece of logic and it removes the entire category of accidental early sends, including the ones caused by retries.
Log the local delivery time. One extra column. It converts an argument into a record.
Check what your platform does on its own. Some sending tools have recipient-local scheduling built in, and it is often off by default. Knowing which of your tools can do this decides where the logic should live.
The wider version of the question
Rules about when you may contact someone vary by country and, in the US, by state — some are narrower than the federal window, and those specifics are worth checking properly rather than taking from an article.
What does not vary is the design flaw underneath. An automation that sends on your schedule, in your time zone, with no idea where the recipient is, will eventually message somebody at an hour they experience as rude and a regulator might experience as something worse. The same blind spot shows up in reminders that arrive at the wrong moment to be useful: a message that arrives at the wrong time does not just fail to work, it costs you the goodwill you were spending it on.
And when a message that should not have gone out does go out, the question of who is answerable for it is not softened by the fact that a workflow sent it — which is the whole argument of your automation told a customer something untrue.
If you want the sending paths in your own setup mapped, with the ones that cannot tell what time it is for the recipient marked, that is part of a process audit: $299, three business days.
The rule quoted here is one federal rule in one country, chosen because it states the principle precisely; it is not a summary of your obligations, and nothing here is legal advice.
Related: automating appointment reminders: the settings that cut no-shows covers the timing question from the effectiveness side.