Two inboxes, one set of tickets

Installing this addon does not move your support desk. It adds a second view of the same tickets.

Screen	Path	What it is
Customer Support	/admin/crm/support	The ordinary desk queue. Every live conversation
AI Live Inbox	/admin/ai/support/inbox	The same tickets, with the assistant's reasoning attached
All tickets	/admin/crm/support/tickets	The archive: analytics, export, bulk actions, every ticket ever raised

There is one ticket table. A reply sent from either console is the same reply, in the same thread, and the customer cannot tell which screen it came from. The addon stores its own state in a side table (ai_support_session) with one row per ticket, which is why uninstalling it leaves core support byte-identical.

The desk console has no AI controls, on purpose

/admin/crm/support carries no drafted replies, no retrieval evidence, no confidence meters and no Teach from this ticket. Those need data that route does not have, and half of them would return 403 for an operator who has not bought the addon. An operator without it should never meet a control that fails.

The single place the desk admits the addon exists is one slot at the foot of the queue pane, with two states:

• Installed and enabled — a link headed AI Live Inbox: "Conversations the assistant is handling, with the evidence behind each answer and one click to take over."
• Not installed — a description of the add-on and a link to its page in the extension manager. That second state is hidden entirely from roles without access.extension, because desk agents work this console all day and are not the people who buy add-ons.

AI-written replies still render as AI replies on the desk. If the assistant has answered a ticket, its messages arrive in that thread carrying the AI badge and the bot glyph. That is a disclosure requirement, not a feature, and it is why both consoles draw the thread through the same component.

Which conversations appear in the AI inbox

The AI queue is a join from ai_support_session to support_ticket, so a conversation appears there only if the assistant has a session on it. One consequence worth knowing before anybody concludes the queue is broken:

• A ticket the assistant never touched is not in it. Tickets raised before you installed the addon, tickets on a channel you have switched off, and tickets that arrived while the assistant was off exist only on the core desk. The archive at /admin/crm/support/tickets is the only place that reaches every ticket.

Which conversations are in scope is decided by the ticket status, not by the session state, and the tabs above the queue choose between them:

Tab	What it holds
Waiting	A person has been asked for, or is already on it
Mine	Conversations you are holding
AI handling	Open, and nobody has taken over
Open	Everything the desk still owns. The default
Closed	Conversations on a closed ticket

Keying on the ticket is what makes a reopened ticket come back. Closing a ticket resolves its AI session, and nothing moves a session back out of RESOLVED — so a ticket you reopen from the desk returns to the core queue and used to stay invisible here for good. (Customers cannot reopen one themselves: both reply routes refuse a closed ticket.)

The queue is paged, not capped. 25, 50 or 100 rows a page, chosen from the sort menu, with the page number and the true total at the foot of the rail. The search box, the tabs and the sort all run in the database across every page, so a count in a tab is a count of every matching conversation and not of the page you happen to be looking at.

What each queue row tells you

Field	What it is
state	Session state, rendered as a plain-language label
escalationReason	Why it was handed over, in the same words the case card uses
turnCount	How many times the assistant has answered on this conversation
costUsd	What this conversation has cost so far
channel	TICKET or LIVE — a filed ticket, or the chat widget
ticketStatus	The core status: PENDING, OPEN, REPLIED, CLOSED
importance	The core priority: LOW, MEDIUM, HIGH
waitingSince	When the state last changed
ageMinutes	How long it has been in that state
humanAgentId	The agent currently holding it, if anyone

humanAgentId is the one to read before you start typing. Two agents opening the same escalation — the state that deliberately sorts to the top of everyone's queue — and both answering it is the failure this ordering makes most likely.

Queue order

The default is Priority: risk, then importance, then age.

Order	State	Label
1	HUMAN_REQUESTED	Waiting for a person
2	HUMAN_ACTIVE	A person is handling this
3	AI_SUSPENDED	AI is off for this conversation
4	AI_ACTIVE	AI is answering
5	AWAITING_USER	Waiting for the customer
6	RESOLVED	Resolved

HUMAN_REQUESTED is first because a person has been promised and has not yet arrived. It is the only state with a clock running against a promise the product made on your behalf. HUMAN_ACTIVE is second because that is the desk's live work, and AI_SUSPENDED third because the assistant has been switched off for that conversation — unless somebody picks it up, nothing answers it.

Within a state, HIGH importance comes before MEDIUM before LOW, and within that the longest wait first.

You can sort by something else. The choice is saved per browser, so it survives a reload and the next shift.

Sort	Opens on
Priority	The ranking above
Last activity	The conversation that moved most recently
Ticket created	The newest ticket
Importance	HIGH first
AI answers	The most-answered conversation
Cost	The most expensive conversation
Subject, Customer	Alphabetical

The arrow beside the sort name reverses it — "longest waiting" is Last activity ascending, "cheapest" is Cost ascending, and so on.

The core desk orders on the same principle in its own vocabulary: it opens on Waiting — the customer spoke last — oldest wait first, filterable by Waiting, Mine, Free (unassigned), All and Closed.

Which screen to answer from

Both consoles can reply, set status, set priority and assign; the AI inbox absorbed those desk controls so an agent who has just solved something does not have to go and find another page to say so. The one difference: a reply sent from the AI inbox goes through the draft route, and when it is sent against a draft it records how far you moved the assistant's text. That edit distance is what the promotion gate reads, so a half-corrected draft makes your install look less ready than it is. Either way the sent message is attributed to you, not to the bot — a human read it and chose to send it.

Answer from the core desk when:

• The assistant is not involved and there is nothing to review.
• You are working the general queue, including tickets with no AI session.
• You want the archive, analytics, export or a bulk close/reopen/assign — that is /admin/crm/support/tickets.

Answer from the AI Live Inbox when:

• The conversation was escalated and you need the handover brief and the escalation reason.
• There is a drafted reply to review, or you want one. The reasoning rail — what was retrieved and how confident it was — is the whole reason that review is not theatre, and Generate a draft never sends, whatever autonomy rung the install is on. See Live Inbox.
• You are about to take the conversation over, or hand it back.
• The reply you just wrote by hand is worth keeping — Teach from this ticket turns it into a draft article, and it needs create.ai.support.knowledge.

Its case pane has three tabs — Brief, Evidence, Case — against the desk's two, Case and Customer.

Custody: takeover and release

The queue decides who holds a conversation from the session state, and the two buttons that move it are the ones you should use rather than simply typing.

Take over stops the assistant on that conversation immediately, including an answer already being generated, and marks it HUMAN_ACTIVE with your id in humanAgentId. By default it posts a visible note — "…from the team has joined and is reading your conversation." It deliberately does not change the ticket status: writing REPLIED there would drop the ticket out of the queue you just claimed it from.

Release hands it back, announce on by default, and passes your messages to the assistant as trusted context so it cannot contradict what you promised. The keepAiOff option releases the conversation to the human queue and leaves the assistant switched off for this conversation only — use it when the topic is one it should never handle.

Permissions

Both queues run on the same core keys, which is why the AI inbox appears for your existing desk agents on upgrade with no grant step.

Key	Opens
access.support.ticket	/admin/crm/support and /admin/crm/support/tickets
view.support.ticket	/admin/ai/support/inbox, /admin/crm/support/{id}, and both queue routes
edit.support.ticket	Take over, release, request a draft, status, priority, assign
create.ai.support.knowledge	Teach from this ticket

A reviewer holding view.support.ticket and not edit.support.ticket can read every conversation and its reasoning rail and change nothing. The full map is in Permissions, and the core desk itself is described in the admin panel tour.

Both consoles are full-screen: the site header and footer are suppressed, and the back arrow in the top bar is the way out.