A high-volume inbox
At volume the question stops being whether replies can be written and becomes which mail gets attention first, and what happens when the day allowance runs out. Connect picks work by the priority stored on the thread, holds rather than drops when the allowance is spent, and leaves the read cursor where it was so nothing is quietly skipped.
How work is picked#
threads.priority is read by the engine when it chooses what to handle, which means correcting a priority changes behaviour rather than re-sorting a list. starred and deleted_at sit beside it as the person own marks, and the same three exist on calls.
Around that sit the triage tools — filters, folders, marks, schedules and briefs. The useful mental model is that triage is not a view over the queue; it is an input to it.
What happens when the allowance runs out#
The daily allowance bounds how much mail is processed. When it is spent, work is held rather than dropped, and the read cursor deliberately does not advance — advancing it on a refusal is how a mail agent loses messages permanently. The refusal is visible in Needs You with its cause.
- Nothing is lost, but nothing moves either. On a workspace where most mail arrives in one burst, the allowance is the first number to look at, before any autonomy setting.
- A held reply and a refused one look different in the queue and mean different things: one is waiting for a person, the other for a ledger.
- Because the cursor holds, the backlog is worked in priority order when the allowance resets rather than in the order it happened to arrive.
Why the screens stay usable at volume#
Reading a big inbox used to be the expensive part, and the fixes are measured in statements rather than seconds, because a threshold in seconds measures the machine rather than the code.
| Screen | Before | After |
|---|---|---|
| Home, 40 conversations | 133 statements, growing with the page | 15, flat |
| Triage strip, 40 rows | 83 statements | 11, flat |
| Workspace console, 40 rows | 89 statements | 17, flat |
| Owner customer list, 1,857 accounts | 5,574 statements | 3 |
The conversation list carried a worse defect than slowness. It read 400 threads and then counted, filtered, searched and paged in Python over that slice — so on a workspace with 430 conversations whose 25 closed ones were the oldest, the Closed tab read 0, the total read 400, and page five came back empty. Counts are one GROUP BY now, the filter and the page are SQL, and a % or _ typed into the search box is escaped and matched as a character rather than as a wildcard.
What to automate first#
- The repeats. Whatever you answer identically twenty times a week belongs in Knowledge first, before any autonomy change. Automation without grounding produces refusals at volume.
- One endpoint, not the channel. Move the highest-volume mailbox to
ask_before_send, leave the rest. Endpoint scope beats channel scope, so this is a small, reversible change. - The queue discipline. If the approval queue is not worked within the hour at your volume,
ask_before_sendis not a safety setting — it is a delay the customer feels while seeing nothing at all. - Then release the safe channel. Under
autonomousthe refusals still hold: a price, an SLA or a warranty Knowledge cannot support is escalated whatever the mode.
Where the cost sits at volume#
Mail is text, so the per-message cost is small and the allowance is the real ceiling. What surprises people is that volume pushes cost sideways rather than up: a high-volume inbox generates follow-ups, and follow-ups on the phone channel are audio, which is metered at several times the rate of text. A thousand emails a week that produce forty call-backs is a voice budget question wearing an inbox costume.
Questions#
Does Connect read everything or only what it replies to?
Fetching, triage and drafting are bounded by the allowance rather than by selection: what the allowance stops is processing, and the read cursor stays put so the unprocessed mail is still unread rather than passed over. Priority then decides the order in which the backlog is worked.
Can I bulk-approve a queue of held replies?
Each approval is a decision recorded against a person and runs the send through the same boundary a person own send uses. If a queue is routinely too large to work item by item, the honest fix is the autonomy mode or the Knowledge behind it, not faster clicking.
Why did a search return nothing when I know the message exists?
Historically a % or _ in the search box was treated as a wildcard and the list was paged in Python over a 400-row slice, which produced empty pages and zero counts on large workspaces. Both are fixed: search characters are escaped and matched literally, and counting, filtering and paging happen in SQL.