Same-day cutoff: automating the 2pm rule
A cutoff promise your automation does not know about is a promise your team breaks after 2pm.
A cutoff is a time after which today stops being an option. Order before 2pm and it ships today; after that it ships tomorrow. Simple to say, and the place where automated ordering most often promises something the warehouse cannot deliver.
The builder handles this directly, which saves you from the branching logic people usually reach for.
The setting that does the work
When a question asks the customer for a date, it can be told how to treat today:
| Setting | Behaviour | Use for |
|---|---|---|
| Offer today | Today is always available | No cutoff at all |
| Never offer today | Earliest is tomorrow | Anything needing a day's preparation |
| Drop today after a cutoff time | Today disappears once the time passes | The 2pm rule |
The third is the one this page is about. Set the cutoff time, and the question offers today before it and stops offering today after it — with no separate branch to maintain and no chance of the two drifting apart.
Why not just build the branch yourself
You can — a time check followed by two versions of the question — and it works until somebody changes the cutoff in one place and not the other. The built-in setting keeps the rule in one location, which is the whole argument.
The manual version is still right when the cutoff differs by product, by city or by day of the week, because then there genuinely are several rules. One rule, one setting.
When the answer should change what happens next
Sometimes a same-day order needs different handling: a different courier, an alert to the packing team, a surcharge. The date question can branch on whether the customer picked today, tomorrow or a later date, so those cases get their own path.
Same-day gets its own treatment
Keep the shared steps on the main path and treat the same-day port as a detour that rejoins it. Moving the whole flow onto the day branch is the mistake that doubles the number of steps you have to maintain.
Cutoffs and business hours are different questions
Worth separating, because they are frequently conflated:
- Business hours decide whether a person is available to reply.
- A cutoff decides whether an operational promise still holds.
They often differ. A store open until 8pm can have a 2pm dispatch cutoff, because the courier collects at 3. Automating one and not the other produces the classic failure: a cheerful confirmation at 7pm for a parcel that will not move until tomorrow. The hours side is in business hours and after-hours automation.
Say the rule out loud
The flow should state the cutoff rather than silently applying it. "Order in the next 40 minutes and it goes today" is useful information and a genuine reason to decide now. Removing today from a list with no explanation just looks like your system is broken.
It also protects you. A customer who was told the cutoff and ordered after it has no expectation to disappoint.
Time zones, briefly
A cutoff is a wall-clock time, and wall clocks differ. If you sell across time zones, be explicit about which one the cutoff refers to — in the message, not only in your settings.
The same applies to weekends and public holidays. A 2pm Friday cutoff means Monday, and saying so is better than letting the customer work it out from a dispatch email that does not arrive.
A short checklist before you publish
- Test before the cutoff and confirm today is offered.
- Test after it and confirm today is gone.
- Test on a Saturday if your cutoff behaves differently at weekends.
- Confirm the packing alert actually reaches a phone — it needs an approved template, per Meta's template documentation, because your colleague has no open conversation window with your business number under Meta's sending messages documentation.
- Have someone from operations read the confirmation wording.
Step five catches the promises the flow makes that the business cannot keep, which is the actual risk here.
Frequently asked
Can the cutoff differ by day?
The single setting is one time. For genuinely different rules by day, use a time check and separate paths.
Does it handle holidays?
Not by itself. Turning the flow off, or adding a temporary message, is the practical route for a known closure.
What if the customer picks a date far ahead?
That is the ordinary reply path. Only same-day and next-day need special handling; everything else is one shared route.
Should the confirmation repeat the date?
Always. It is the cheapest way to catch a misunderstanding while the customer is still in the conversation, and it costs nothing under Meta's pricing documentation while the window is open.
Getting the cutoff right in the first place
Before automating it, check that the time you advertise is the time your operation actually keeps. A great many stores publish a cutoff that was true when the courier collected at 4pm and has not been revisited since.
Three questions for whoever packs the orders:
- When does the last collection actually happen? Not when it is scheduled — when it happens.
- How long does packing take at your busiest? A cutoff that works on a Tuesday and fails on a Saturday is not a cutoff.
- What happens to an order that just misses? If somebody routinely rescues it, your real cutoff is later than the published one, and your automation should say so.
Automating an inaccurate promise makes it worse, because now it is made consistently, at scale, without anyone in the loop to catch the exception.
Where the cutoff shows up elsewhere
| Place | What it should say |
|---|---|
| The date question | Today disappears after the cutoff, automatically |
| The confirmation message | The dispatch day, spelled out |
| The after-hours auto-reply | When the next dispatch is, not just when you reopen |
| The packing alert | Whether this one is same-day |
Four places, one rule. Keeping them consistent is mostly a matter of writing the rule down once and referring back to it, rather than re-deciding it each time somebody edits a message.
The countdown, used carefully
"Order in the next 40 minutes for dispatch today" is genuinely useful information and it is also, obviously, a nudge. The line to hold is that it must be true — a countdown that resets, or that appears at 9pm, is the kind of thing customers notice once and remember.
Used honestly it is one of the few urgency messages that does not damage trust, because the deadline is real and the customer can verify it by ordering after it and seeing what happens.
What to do after the cutoff has passed
Not silence. The customer who arrives at 4pm is still a customer, and the message that serves them is the one that says clearly what they will get: dispatch tomorrow, arriving on such a day.
Some stores add an option here — hold for a specific day, or upgrade to a courier with a later collection. Both work, and both are worth building only if the operation genuinely supports them. The alerting side, so the packing team knows which orders are which, is in internal notes and team alerts from a flow, and the date-question mechanics sit alongside the other question types in asking customers questions with buttons and lists.
Testing it without waiting for 2pm
The awkward part of testing a cutoff is that you can only see one side of it at a time. Two practical approaches:
- Move the cutoff temporarily. Set it a few minutes ahead, watch today disappear, then set it back. Quickest way to prove the behaviour.
- Test on an unpublished draft so nothing customer-facing changes while you experiment.
Either way, do it before publishing rather than discovering at 2:01pm that the setting was on the wrong option. The general protocol is in testing an automation safely.
The failure this prevents
Worth being concrete about what goes wrong without it. A customer orders at 4pm, the flow offers today, they choose it, and they are told their parcel ships today. It does not. They message the next afternoon asking where it is, your team apologises, and the customer's experience of your store is now defined by a promise a form made.
One setting removes that entirely — and it removes it consistently, which matters more than any single conversation. A rule applied by software does not have a bad day.
The short version
Check the cutoff you advertise is the one your operation keeps, set it once in the date question, say it out loud in the message, and give the same-day orders their own alert so the packing team sees them first.
Everything else follows from that. The confirmation repeats the dispatch day, the after-hours reply names the next dispatch rather than the next opening time, and anybody who arrives after the cutoff is told plainly what they will get instead of being quietly given a date the warehouse never agreed to.