Support office hours
The weekly schedule that turns "someone will reply here" into a time — where it lives, what a closed day means, how to split a day around lunch, which timezone to put in, and what happens when the schedule cannot be read.
Every handover the assistant writes ends with some version of "someone will reply here". At 09:00 on a Tuesday that sentence means twenty minutes. At 02:00 on a Sunday it means eleven hours, and the customer has no way to tell the two apart — so they wait, then chase, then open a second ticket, then conclude they were ignored.
Office hours are the fact that prevents all of that. They are a fact you already know and previously had nowhere to put.
What switching this on actually changes
It qualifies the sentence. Instead of "someone will reply here" the customer reads "someone will reply here — Monday at 09:00 Europe/London", and only when the desk is genuinely shut.
That is the whole feature. It does not change when the assistant answers — it answers around the clock, which is the point of it — and it does not queue, delay or hold anything. It adds a sentence, and only ever a true one.
The settings
They live on Admin → AI Support → Settings → Channels, under Office hours. The schedule only renders once the first switch is on, because a week of controls that mean nothing is worse than no controls.
It ships off, and that is an accuracy decision rather than a cautious one. Hours that are wrong are worse than no hours: a customer told "back at 09:00" who is still waiting at 11:00 has been given a broken promise by your product, where before they only had an unanswered ticket. Nothing is claimed until you have stated your own hours. The default schedule is filled in anyway, so switching it on is one toggle rather than a toggle plus a syntax lesson.
The schedule editor
Seven rows, one per day. Each has a switch, and the days you switch on get a start time and an end time.
A day with no hours is closed. There is no separate "closed" control and none is needed — an empty day is the same statement, and it is the statement the customer is given.
Add a second range to a day for a lunch break. Nothing forces a day to be
one continuous block. 09:00–12:00 plus 13:00–17:00 means the desk is shut
over lunch, and a customer who writes in at 12:30 is told the team is back at
13:00 rather than being told nothing. This has always worked; the older free-text
field simply gave nobody a reason to discover it.
Copy Monday to the other weekdays fills Tuesday through Friday from Monday. It deliberately leaves Saturday and Sunday alone — copying a weekday schedule onto the weekend is the one version of that button that is usually wrong, and it would be wrong silently, because you would see a full week and assume you meant it.
An end time at or before its start time is refused rather than interpreted.
22:00–02:00 is a plausible way to write "overnight" and an equally plausible
typo for 02:00–22:00, and guessing wrong tells your customers the desk is
staffed for twenty hours a day.
A desk that genuinely runs overnight writes 22:00–24:00 on one day and
00:00–02:00 on the next.
It used to be a textarea, and the textarea was the bug
Worth knowing if you are upgrading, because it explains the change.
The field was free text, and the parser behind it is tolerant — it accepts three
day spellings, several dashes, and a handful of words for "closed". None of that
carefulness helped, because the failure was never strictness. It was silence:
type mon 9-5 and nothing throws. The line simply is not understood, the whole
week reads as "nothing was configured", and the assistant responds by saying
nothing about hours at all. Meanwhile the switch is on, the screen looks
configured, and nothing anywhere disagrees with you.
The structured editor removes the class rather than validating it — there is no text to mistype. It reads and writes the same stored format, so a schedule entered on an older build loads unchanged.
Use your team's timezone, not the server's
The zone is an IANA name — Europe/London, America/New_York. Your customers
read the hours in this zone, and the zone name is printed alongside the time, so
this is the one field where the wrong answer is confidently wrong rather than
obviously wrong.
It should be the zone your support team works in. The server's timezone is irrelevant to when a person is at a desk, and picking it because it is the one you know shifts every stated hour by the difference.
A name the server does not recognise is refused when you save, rather than quietly becoming UTC — which would have moved every hour you just typed.
Two more things are refused on save, for the same reason: a schedule nothing in it could be read from, and a schedule that is closed on every day of the week. If the desk genuinely has no set hours, switch the feature off rather than saving an empty week.
The reader is deliberately silent about a schedule it cannot parse — see below — so validation happens on save, where there is a human present to be told. If you change this setting through the API rather than the screen, you get the same refusals; if you edit the row in the database, you get none of them.
When it says nothing, and why that is right
Three different situations end with the assistant having no opinion about hours, and all three behave identically to the feature being off:
- The switch is off.
- The stored schedule could not be read at all.
- The schedule parsed, but has no open window on any day.
In every one of those, the assistant says nothing about timing rather than guessing. It does not fall back to the default nine-to-five, and it does not announce that support is permanently shut.
That is the deliberate choice, and it is the safe direction: an unqualified "someone will reply here" is what the product said before this feature existed, and it is never wrong — only vague. "The team is back Monday at 09:00" derived from a schedule nobody could read would be a specific promise built on nothing.
The practical consequence for you is that a mistyped schedule looks exactly like the feature being off. If you have switched hours on and customers are not being told the timing, re-save the schedule from the settings screen — the save is what tells you whether it can be read.
The out-of-hours sentence
{when} is replaced with the next opening time. When there is no next opening
time to give, the placeholder and the punctuation around it are removed cleanly
rather than leaving a hole — a sentence reading "they'll be back — ." is worse
than one that never tried.
The sentence is appended only when the desk is shut. While it is open, nothing is added.