Channels — where it answers, the opening line, and office hours

The Channels tab of AI Support settings — the two channel switches, the debounce, the greeting and quick replies, office hours syntax and timezone, and the handover thresholds.

5 min readUpdated 6 August 2026channels, live-chat, greeting, office-hours, handover

/admin/ai/support/settings, the Channels tab — second of five, after Guardrails. It holds thirteen settings in five sections:

Section	What it decides
Where it answers	Tickets, live chat, and how long it waits before replying
Opening line	The greeting and the one-tap starters under it
Office hours	When your human team is at the desk
Handover	When it gives up, and what it does after a person joins
Outbound	Whether it opens tickets nobody asked for

Needs access.ai.support.settings. Nothing on this tab is Super-Admin only — see Permissions for the twelve keys that are.

Where it answers

Drafts or posts a reply when a customer opens a support ticket.

Replies in real time in the chat widget.

On the shipped defaults the assistant touches tickets only. An install that never opens this tab has an assistant that appears to ignore the chat widget entirely, and nothing anywhere says why.

Turn it on only once you are happy with what it does on tickets. A ticket reply is read minutes later and can be corrected; a live chat reply is read within seconds.

Three things have to be true before either channel answers: the ai_support extension is installed and switched on, aiSupportEnabled is on, and the switch for that channel is on. Autonomy then decides whether it posts or drafts — AUTO_TICKET speaks on tickets and drafts in chat, AUTO_ALL speaks in both, COPILOT only ever drafts. See Autonomy.

How long it waits after a customer message before generating, in milliseconds. 0–60000.

Customers type in bursts. Four seconds means three short messages become one answer instead of three — cheaper, and it reads better. This is a property of the channel, not of handover, which is why it sits here.

Opening line

Greet a customer as soon as the chat widget is opened.

The greeting text. {name} is replaced with the customer's first name.

It is the same sentence every time, so it is never sent to a model. No model call, no cost, no turn recorded, and no conversation created — the widget deliberately does not open a session when somebody clicks the bubble, because that left an empty pending row in the desk queue for every customer who clicked and closed again.

That is also why this is the one customer-facing thing in the addon that ships on: it cannot say anything wrong.

{name} resolves to the customer's first name, read from their user record rather than from the session, and is dropped cleanly along with the space before it where no name is held — so the sentence reads correctly either way. The shipped default is written to survive that substitution:

Hi {name} — ask me anything about your account or how something works here.
I can look things up and point you to the right page, and I'll bring in a
member of the team whenever you want one.

The greeting is only shown where the assistant would actually answer. With live chat off, or in COPILOT, the widget shows no greeting — an install whose assistant is not going to speak must not open with "ask me anything".

One-tap starter questions. One per line, up to six.

Stored as a JSON array of strings. A newline-separated list is accepted too, because an older row or a hand-edited one may hold that shape. Whatever you write is bounded on read: at most six items, each truncated to 80 characters. They render as tap targets under the greeting, and a hundred of them — or one four hundred characters long — is a broken widget.

Invented starters are worse than none. A customer who taps "How do I withdraw?" and is told the platform has nothing documented about that has been actively misled by your product.

Fill these from Gaps, where the questions are real, and only add one once the answer exists.

Office hours

These describe when your human team is at the desk. They are not when the assistant answers — it answers around the clock, which is the point of it.

What they qualify is every "someone will reply here" the addon writes. At 09:00 on a Tuesday that sentence means twenty minutes; at 02:00 on a Sunday it means eleven hours, and the customer cannot tell which, so they wait, chase, open a second ticket, and conclude they were ignored.

Add the timing to every handover message.

The week. Stored as one line per day.

An IANA timezone name. Your customers see the hours in this zone.

Appended when the desk is shut. {when} is the next opening time.

Off by default, 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 the product, where before they had only an unanswered ticket.

The schedule itself is pre-filled, so switching it on is one toggle rather than a toggle plus a syntax lesson. The shipped week is Monday to Friday 09:00–17:00, Saturday and Sunday closed, in UTC.

The stored syntax

The screen renders a week of rows with time pickers, but the value written to the settings table is still one line per day, and that is what you will see if you read the row or set it through the API:

mon 09:00-17:00
tue 09:00-12:00, 13:00-17:00
sat closed
sun closed

Day names may be mon, Mon, or Monday; a colon after the day is optional.
closed, none, off, - and an empty value all mean shut.
A second range on the same line is a lunch break.
A day you omit entirely is closed.
An API caller may send {"mon":"09:00-17:00","sat":[]} instead; both shapes parse identically.

An overnight range is dropped rather than guessed. 22:00-02:00 is an equally plausible way to write "overnight" and to typo 02:00-22:00, and guessing the second tells your customers the desk is staffed twenty hours a day. Write two lines if you genuinely run overnight.

At read time an unparseable schedule fails silently — deliberately, because the alternative is announcing that support is shut forever. So the write route is the one moment there is a human present to be told, and it refuses three things with a 400 rather than saving them:

a schedule where nothing could be read (mon 9-5 is the classic — no leading zero, no colon)
a schedule that is closed on every day, which you should express by switching the feature off
a timezone Intl does not recognise, named back to you in the message

A row written before this validation existed can still be unreadable. If office hours are switched on and no customer ever sees a timing, open the tab: the week control reports a value it cannot render, and that is the only place in this feature an operator is ever told their hours are broken.

ai_support_agent.workingHours and ai_support_agent.timezone exist as columns, are accepted by the agent create and update routes, and are never read by anything. Settings are the only source of truth.

The persona row is optional — a real install can have none at all — so hours that lived there would be absent on most installs while looking perfectly configured. If you set hours through the agent API and customers still hear nothing, this is why.

Handover

How many attempts it gets before handing the conversation to a person. 1–20.

Keep preparing a suggested reply after one of your team takes over. It never sends it.

Low is safer on the turn limit. A customer going round in circles with an assistant is worse than a queue, and the cap exists to end the loop — an escalation for turn_limit is one of the reasons the assistant will not take the conversation back when the customer writes again.

Outbound

Open a ticket, with an explanation, when a customer's deposit or withdrawal fails.

This is the only setting in the addon that messages people who did not contact support. It ships off, and turning it on is a decision about how your platform speaks to people rather than a tuning knob.

The Preview block beneath it is not a setting. It runs the real selection against your own transactions and shows exactly who would have heard from you — because nobody sensibly turns this on from a description.