Conversation statuses
CXP uses conversation status to explain where customer work is in the support lifecycle.Open
Use Open for active work that needs agent, AI Assistant, or team attention. Open conversations appear in open queue views and can be assigned to an agent or team. The conversation composer can send a Public reply through an available Email or active Chat channel. Internal notes are also available.Pending
Use Pending when work is waiting on a customer, internal team, vendor, or other follow-up condition. Pending conversations can include:- Pending On to show who owns the next action
- Pending Reason to explain why the conversation is waiting
- Pending At to record when it entered pending state
Resolved
Use Resolved when the customer issue appears solved but the tenant wants a reopenable review state. Resolved conversations are no longer treated as active open work, but they remain available in history and search. Moving a conversation to Resolved ends any active web chat immediately. A later widget reconnect by itself does not reopen the conversation. When the customer starts another chat, CXP resets the ended widget session and applies the tenant’s normal conversation-resolution rules. If that real customer activity is associated with the Resolved conversation, it reopens to Open. The composer offers Email when the contact has an email address and initially selects Public reply. Chat is unavailable because resolving ends active web chat. Sending an Email reply keeps the conversation Resolved and does not replace or cancel its existing automatic-close schedule. For Facebook and Instagram comments, Resolved releases agents from active Chat workload but retains the comment session. A new comment continues that session and reopens the same conversation in either conversation mode. To send an agent follow-up, reopen the conversation first. See Facebook comment lifecycle and Instagram comment lifecycle.Automatic closing after resolution
Tenant administrators can set Resolved conversation auto-close timeout under Settings → General. The value is a whole number of hours, defaults to 48, and accepts0 to disable automatic closing.
When a conversation enters Resolved, CXP schedules closing based on that
resolution time. The timer is intentionally low resolution: its due time is
rounded up to a five-minute boundary and is checked by a poller that runs about
once per minute. In healthy operation, closing can therefore occur up to about
six minutes after the unrounded timeout.
At expiry, CXP closes only if the conversation is still Resolved with the same
resolution timestamp and the setting is still enabled. Reopening, closing, or
resolving the conversation again invalidates the earlier timer. Changing one
enabled timeout to another affects conversations resolved afterward; already armed
timers retain their original due time.
Setting the value to 0 does not pause an outstanding timer. If the timer is
evaluated while disabled, CXP permanently completes it without closing the
conversation. Re-enabling before evaluation may still allow that timer to
close; re-enabling afterward does not recreate it.
Automatic closing uses Redis delivery state and does not scan Resolved
conversations to recover a timer that failed to arm or was lost. Administrators
must identify and close any affected conversations separately after such an
incident.
Automatic resolution after an AI Assistant interaction
Tenant administrators can set Bot conversation auto-resolve timeout under Settings → General. Enter a whole number from 1 through 48 hours, or enter0 to disable automatic resolution. The default is one hour.
After an AI Assistant completes a web-chat turn, sends a new public Email
reply, or ends a LiveKit voice interaction, CXP starts the timeout only when
the conversation is Open, unassigned, not routing or handing off to a person,
and has no active person or voice interaction. For Email, the timeout starts
from the committed AI Assistant reply; delivery-status updates and exact
inbound replays do not restart it. Customer activity, assignment, human
participation, handoff, routing, or a manual status change cancels the current
timeout. A later qualifying AI Assistant response starts a new timeout.
Stopping voice in the web widget also starts this timeout when the conversation
meets those conditions, even if its Chat remains active. You do not need to send
another chat message. Repeated call-end notifications do not restart the timeout.
A widget disconnect or reconnect without new customer input does not cancel or
restart this timeout.
If the widget resends the same saved contact-form answers after a reload, CXP
treats them as a duplicate and keeps the original timeout and deadline.
The same duplicate also leaves a Pending or Resolved conversation in its current
status. First submissions and changed answers follow normal customer-input rules.
When the timeout expires and those protections still hold, CXP performs the
same Resolved transition as the conversation’s Resolve action, including
the normal chat cleanup and notifications. A reconnect alone leaves it
Resolved; later real customer activity can reopen the conversation to Open
after normal conversation resolution. Closed conversations do not reopen.
After-hours email escalation
Auto-resolve after hours email escalations in Settings → General adds a specific exception for widget Chat handed off to external email after hours. When enabled, the same bot timeout resolves the conversation even though the handoff assigned a follow-up team. Email delivery outcome does not affect the timer. New customer input restarts it; active Voice defers it until the call ends. Human handling or reassignment removes that exception. The setting defaults off: Chat-idle then ends Chat while the conversation stays Open for CXP follow-up. With the setting on and bot timeout0, email
auto-resolution is disabled without a Chat-idle fallback. See
configuration and limits.