The Automation That Texts Your Customer at 3 A.M.
David Selva · · 3 min read
Send Timing, Appliance Repair, Workflow Automation
A trigger fires on an event, and events do not observe business hours — which is how a review request lands while the customer is asleep.
Every automation you build will eventually try to text somebody at three in the morning. The only real question is whether you find out from a report or from the customer.
Here is how it happens. A trigger fires on an event — a form submitted, a job marked complete, a payment cleared. Events do not observe business hours. A tech closes out the last job of the day at 9:40pm, the completion triggers the review request, and it lands while the customer is asleep.
Why this hits repair businesses harder
Appliance work runs late. The dryer that stopped working is a today problem, so the schedule pushes, and a fair share of your jobs get closed out after dinner.
Emergency-adjacent trades also collect a lot of after-hours inbound. Somebody's freezer is failing at 11pm and they fill in your web form, which fires your instant response, which is correct — that one should go out immediately. Then the day-three follow-up in the same sequence counts forward from 11pm and arrives at 11pm on Thursday.
The instant response and the nurture message have opposite requirements, and they are usually sitting in the same automation with the same timing rules. That is the actual bug.
Three rules that cover most of it
- Quiet hours on anything that is not an immediate response. Nothing non-urgent sends between about 9pm and 8am. Messages that come due inside that window queue and go out in the morning.
- Branch on how the contact arrived. A person who just filled in your form at midnight is awake and waiting. A person you are following up with on day seven is not thinking about you. Same sequence, different timing rules.
- Decide about weekends deliberately. Saturday morning is fine for most repair customers. Sunday is not, in a lot of markets. This one is local and you should pick based on your customers rather than a default.
None of this is complicated to configure. It is just invisible until it goes wrong, because you are never awake to see your own automations misfire.
The exception, and why it needs a separate path
If you run genuine emergency service, some things must go out at 2am. A dispatch confirmation, an ETA, a tech-is-on-the-way message.
Those belong in their own automation with quiet hours off, and they should be short and purely factual. The mistake I see is running emergency messages through the same friendly template as everything else, so the 2am text opens with a line about how much you value their business. At 2am nobody values anything except the arrival time.
What a bad send costs
More than the one customer, usually. A middle-of-the-night text is the kind of thing that gets screenshotted, and it converts a neutral customer into somebody with a small story to tell about you.
It also does something quieter and worse inside the business. The owner sees the complaint, decides the automation is not trustworthy, and turns the whole sequence off. Now the follow-up that was working is gone too, because one message had no time-of-day rule on it.
I have switched more sequences back on than I have built from scratch, and the reason they were off was almost never that the content was wrong.
Where automation stops and a rule starts
A system will do exactly what you configured at exactly the moment the condition is met. It has no sense of whether now is a reasonable time to speak to a person. That judgment does not emerge from a better tool; somebody has to encode it once, deliberately.
Go into whatever you are running now and look at every message that is not an immediate response to an inbound. Check whether each one has a time window on it. The ones that do not are not broken yet — they are waiting for a tech to close a job late.