Key takeaways
- A form submitted at night was correctly detected as out of hours, correctly sent a polite email, and correctly handed off to the morning by adding a tag. The warning text still went out at 02:01 and the call dialled at 02:02.
- The workflow that tag triggers had no quiet hours set, and an unset field there does not mean use business hours. It means no restriction at all.
- Deferring by tag is not deferring. An after hours branch is only as safe as the schedule on whatever it hands off to.
- Every check passed. The workflows were valid, published and shaped correctly, and this is invisible in all of them.
- Copying the platform's own default hours is wrong for most trades in two separate ways, so we set ours per sequence rather than taking what was offered.
We were auditing a contractor CRM build before calling it finished. Not testing whether it worked, because it did. Reading every workflow that sends a message and asking a narrower question: under what conditions is this allowed to fire.
What came back was that every one of them was allowed to fire at any hour of any day. And the consequence was not theoretical.
The chain, and every link in it behaved
Here is what a night looked like. A homeowner fills in the form at two in the morning, because that is when people who cannot sleep think about their roof.
The intake function reads the time, correctly decides this is outside working hours, and tags the lead as an after hours enquiry. Right so far.
The after hours workflow picks that up and does the sensible thing. It sends an email saying we have your request, which is fine at any hour because email waits politely in an inbox. Then, to make sure this lead is not forgotten, it adds the tag that hands the enquiry to the morning.
Except that tag is the main speed to lead trigger. It is the one that exists to hit a fresh lead fast, and it had no schedule on it, so it ran the instant the tag landed. Warning text at 02:01. The urgent call tag at 02:02. The connect call dialling right behind it.
The branch built to prevent exactly this was the thing that caused it. Every individual step did the correct thing. The failure lived entirely in the seam between two of them.
A blank field is a decision somebody already made
The reason this hid is that nothing about it looks wrong. The schedule setting on these workflows defaults to empty, and empty reads to a human as not configured yet, or as fall back to something sensible. It does neither. Empty means no restriction, and no restriction means two in the morning is as valid a send time as two in the afternoon.
That is a category of bug worth naming, because it is not a mistake anybody made. Nobody set a bad value. The failure is in the gap between what a blank field looks like and what it means, and it only becomes visible when something fires at an hour that embarrasses you.
Once the window exists, the platform holds the action while the contact is outside it and releases it when the window opens. It does not skip the message. That is what makes handing off by tag safe again, and it is why the fix is a schedule rather than rebuilding the branch.
Do not copy the default hours you are offered
The platform's own scaffolder installs Monday to Friday, nine to five, on workflows it builds. For a home services trade that is wrong twice over.
It drops every Saturday enquiry until Monday morning, and weekends are when homeowners are home looking at the thing that needs fixing. And it cuts off at five, which is roughly the hour people finish work and start answering their phones.
So the hours got set per sequence rather than globally. Selling sequences run Monday to Saturday, eight in the morning to seven at night. Reactive ones run wider, seven to nine every day, because a text back after a missed call on a Sunday is welcome rather than intrusive. Anything asking a favour, like a review request, runs politely inside nine to six.
Email does not need a window at all. Texts and calls do, and the distinction is simply whether the message makes a noise in somebody's pocket.
Then check whether the fix travels
One more step, and it was worth doing. This build gets cloned for each new client, so a fix that lives only in the original is a fix that helps one business.
We restored the updated build into a throwaway account and read the schedule back off four of the restored workflows. All four arrived with theirs intact. That took a few minutes and the cost of assuming would have been every future client texting homeowners at two in the morning.
What this means for your business
Two things, and neither requires you to touch a workflow.
First, if any system sends on your behalf, find out what happens to a lead that arrives at three in the morning. Not what should happen, what does. Submit one and watch. Every automated system in the world looks correct in a diagram and the diagram is not where these bugs live.
Second, be suspicious of any handoff that works by flagging something for later. Later is doing a lot of work in that sentence, and it usually means immediately unless something downstream is stopping it. Any GHL consultant Bay Area side will tell you the same thing after enough builds: the settings that hurt you are almost never the ones you filled in wrong. They are the ones you left blank because blank looked safe.
Want this built for you
We build CRM automation that behaves at three in the morning, plus the websites and funnels feeding it. Start at optechsol.llc.