​

Pending replies — the supervisor approval queue

When the reply-approval gate is on for an agent, every reply that agent composes is held for sign-off instead of sending immediately. Inbox → Pending replies is the supervisor queue where that sign-off happens — one shared list of every gated reply, oldest first, with approve and reject inline. This guide walks you through when the gate applies, how to read the queue, and how to approve or reject so nothing a supervisor should review reaches a customer unreviewed.

​

1. When reply approval is on

The gate is scoped per agent, resolved in two levels each time a reply is submitted. A per-agent override set under Inbox → Settings → Reply approvals wins over the workspace default, and the workspace default require_reply_approval_default (an org inbox setting) is the fallback for anyone without an override. Default is off — until you turn the gate on, every reply dispatches directly. Use the gate where a reply must clear two sets of eyes before it leaves:

• Junior-agent onboarding. A new agent answers real customers from day one while a supervisor clears every reply, and you turn the gate off for that agent once sending directly has been proven.
• High-stakes queues. Teams answering complaints, regulated, or legal conversations often run a four-eyes rule as their own policy. The gate is a tenant control you switch per agent; whether it applies is your call, and the default is off.

An un-gated agent never sees the queue — their replies go out directly. The workspace owner is never gated, either, so the gate can’t strand the owner’s own replies behind themselves. The gating toggles themselves live in the dashboard under Inbox → Settings → Reply approvals and in the reply-approvals API; this page covers the other half, the queue.

​

2. Open Inbox → Pending replies

In the dashboard sidebar, open Inbox → Pending replies. The page lists every queued reply across all gated agents in one shared queue, oldest first, so the top of the list is the reply that has been waiting longest. Screenshot placeholder: pending-replies queue with one card per queued reply. Each card shows everything you need to decide:

• The requester’s display name (resolved from the team roster).
• A channel badge (SMS, WhatsApp, email, RCS, Viber, Instagram, Messenger, LINE, Telegram, Apple Messages, or fax).
• How long ago the reply was submitted, rendered relatively (just now, 12m ago, 3h ago) until it passes thirty days, after which the card shows the absolute date.
• The proposed body, exactly as the agent composed it — the body is what you approve or reject, so read it, not just the metadata row.

An Open thread link on each card jumps into the full conversation in the Inbox, which is how you review the customer’s earlier messages before deciding. When the queue is empty the page shows a “Nothing to approve” state instead of a spinner, and a queue that failed to load shows an inline error with a retry — so a blank queue always tells you which it is.

​

3. Approve a reply

Approve when the reply is correct as written. Click Approve & send on the card. The queued body dispatches to the customer through the same channel path a direct reply would take — the SMS goes out as SMS, an email goes out with the subject and cc/bcc the agent set, a WhatsApp reply posts to the thread — and the row is marked approved. The reply the customer receives is the exact text you reviewed; approving doesn’t paraphrase or regenerate anything. Approve is one click with no dialog, because the decision gate was reading the body. If the dispatch itself fails — the conversation closed, the provider is down, a send-time validation trips — the approval errors and the row stays pending, so a failed approve never half-sends a reply. Retry it after the underlying cause is fixed.

​

4. Reject with a note

Reject when the reply should not go to the customer. Click Reject on the card; a dialog opens and asks for an optional reason, up to 1,000 characters. Nothing is dispatched either way, and the row is marked rejected. The reason is optional, but it’s the only feedback the agent gets on their rejected row, so leave one — “Offer the discount code instead of a refund”, “Soften the tone and add the order number”, “This conversation already closed; check the thread before answering”. While you type the reason a failed reject (transport error, another reviewer decided the row first) surfaces inline in the dialog rather than only in the toast, so you can retry without losing what you wrote.

​

5. Bulk actions and filters

The queue renders up to 50 pending rows from the server, but the page mounts only the first 10 cards. A Load more control grows the visible window by 10 at a time with a “Showing N of M” counter, so a busy queue stays responsive and the sidebar keeps the list short. Screenshot placeholder: the Load more control and visible-row counter at the bottom of the queue. Use Open thread on each card to apply the thread’s context. The queue is the decision surface, not a filter workbench — assignment and priority routing live in the standard Inbox list; the four-eyes decision itself happens here.

​

6. Privilege model

The privilege split is deliberate: agents submit, supervisors decide.

• Submitting a reply is open to any full-seat agent; the gate only decides whether it queues or dispatches directly.
• Listing, approving, and rejecting are restricted to owners, admins, and supervisors. The dashboard page guards the same role set a viewer must have — a genuine non-supervisor never reaches the queue, and the server is authoritative on every call, so an agent with the composer can’t approve their own reply via the API either.
• Managing who is gated — reading the effective per-agent window and setting overrides — is likewise held to the same supervisor roles. A non-supervisor calling the queue endpoint gets a 403, which is how the gate never turns into a self-approval loop.

Every decision writes an audit event on the org — the queued submission, the approval, the rejection with its reason, and every setting change — with the acting user and the row it touched. The queue row itself names both sides of the four-eyes pair (the submitting user and the deciding user), stamps when the decision happened, and for approvals points at the message that actually went out. That pair is the record a QA review or an audit reads.

​

See also

• Inbox setup — channels, routing, SLA, the workspace the gate operates inside.
• Reply approvals — API — the endpoints this page’s queue mirrors, with curl samples for every shape.
• Supervisor coaching — the other supervisory review surface; coaching instructs live, pending replies gate text.
• Inbox API — the full inbox endpoint surface the queue endpoints belong to.