The message was fine. The hour was not. Somewhere right now a very reasonable automation is thanking a customer for their business at 9:40 PM, because the technician closed out the job after dinner and the system delivered the follow-up the moment the trigger fired. The customer does not experience a clever automation. They experience your brand buzzing on their nightstand.
Three mechanics conspire, and none of them is a bug on its own. Event-triggered messages inherit the clock of the event: jobs get closed out, invoices get marked paid, and reviews get requested whenever a human happens to finish the task, including late. Scheduled jobs inherit the clock of the server, which is very often set to UTC, so a tidy midnight batch lands at 5 PM in San Diego or 8 PM in New York depending on the season. And when there is a timezone on file at all, it is usually the business's timezone, not the recipient's, which works right up until you serve customers one time zone over.
After-hours texts read as intrusions, and the metrics say so: opt-outs cluster in the evening, and the goodwill your message meant to build arrives as its opposite. For SMS in the United States the stakes are also regulatory. The TCPA's commonly cited window for contacting consumers is 8 AM to 9 PM in the recipient's local time, and neither carriers nor courts have shown much patience for the defense that the server did it.
You do not need to schedule every message. You need a send window, evaluated honestly. Define the hours your messages are welcome, say 9 AM to 8 PM. Evaluate that window in the recipient's timezone. And when a trigger fires outside it, do not drop the message and do not send it anyway: queue it, and flush the queue in order the next morning.
We shipped exactly this, and the details that separate a working version from a demo are worth stealing. Derive the recipient's timezone from the best evidence you have, which for field work is the job site's address, not your office. Do daylight saving with real timezone math, never a stored offset, because the offset you saved in January lies to you in July. Guard the settings form so a window whose start is not before its end cannot be saved, since one inverted dropdown silently holds every message forever. And flush the queue on a short cadence, so 9 AM means 9:00 and not 9:47.
Most marketing and field-service tools bury a quiet hours or send window setting, usually off by default and usually set to the account's timezone when on. The audit costs one evening: put your own cell number in as a customer, trigger your flows after 9 PM, and see what arrives. Whatever buzzes is what your customers have been getting.
9 AM to 8 PM in the recipient's local time is a comfortable default inside the commonly cited 8 AM to 9 PM TCPA window. Tighten it if your audience skews residential or older.
Not legally in the US, but practically yes: evening email fights worse attention and reads as automated. The window logic is already built, so reusing it for email costs nothing.
A reply inside an active conversation is service, not marketing; answering a 9:30 PM question at 9:31 is good business. Quiet hours are for messages the customer did not just ask for.
Everything we write about, we build. Thirty minutes maps it to your business.