Skip to main content
A channel has several independent parts: configuration, inbound delivery, conversation storage, automation, and outbound delivery. A channel card or a working credential verifies only part of that path. Use this guide to choose the correct operating surface and prove an end-to-end result.
The current Chat Desk list implementation reads native chat threads and response records with channel chat or email. Its send handler supports native chat and managed email. Do not assume every channel shown in the product has the same desk capabilities.

​
Channel coverage

These statements describe the checked implementation, not a promise that every workspace has all providers configured. Confirm your deployed version and verify a real conversation.

​
Website chat: one thread, two views

The visitor uses the widget; the operator uses the desk. Native chat replies are saved to the shared transcript and retrieved by the widget. Internal notes remain available to operators but are filtered from public widget reads. Use the widget-to-desk walkthrough to verify the same thread on both sides. Claim coordinates operator ownership; Pause AI / take over controls the conversation’s automation state. Verify both when handing a conversation to a person.

​
Email: managed conversation and delivery service

Start with the Email channel’s setup and readiness checks: the inbox or managed workspace, sending domain, and any required workflow connection. Then send a real message from an external mailbox and open the Email queue in the desk. The desk groups email response evidence into conversations. When the corresponding managed-mail conversation is available, it loads that service’s message history and enables replies through the mail service. This is different from simply viewing an email-shaped response record. For a first verification:
  1. Match the sender, subject/context, and conversation identifiers to your incoming test email.
  2. Claim the conversation if appropriate and confirm no other operator owns it.
  3. Send one reply, then inspect whether the result is queued, sent, or failed.
  4. Check the receiving mailbox and provider delivery evidence.
  5. Verify any status change in the owning mail service.
Managed email limitations: internal notes are not currently supported through the desk send handler. Protected sending requires the mail service’s idempotent-reply capability; if it is unavailable, the app keeps the draft and blocks that send. Do not bypass it by repeatedly submitting the message. Desk controls can map to provider state: for managed mail, Mark reviewed maps to a closed conversation, in_progress maps to pending, and snoozing sets the provider’s snoozed state. Treat these as operational changes, not cosmetic labels. A sent reply still does not prove that the recipient read it.

​
Helpdesk workflows and external ownership

A connected helpdesk may remain the system where tickets are received and replies are dispatched. The desk’s update handler includes Gorgias handoff and status synchronization for eligible conversations, but the desk send handler does not provide a generic Gorgias ticket-reply route. Follow the workflow trial for shadow replay, then verify provider readiness, routing, review, and actual dispatch before live use. A replayed draft is not a sent helpdesk reply. A record visible in the desk is not proof that every edit or reply is mirrored to the external helpdesk. Keep the provider ticket ID, Response record ID, and workflow run ID together when tracing an outcome. Do not substitute one for another in tools or support requests.

​
SMS and WhatsApp: verify the complete path

The messaging channel pages expose provider, sender, signed inbound route, and live-proof checks. The current SMS readiness endpoint can report ingress-ready when provider credentials and a sender are present, while conversationAutomation remains false. WhatsApp reports inboundRoute: false and conversationAutomation: false in the checked implementation. Some channel pages link to /chat-desk?channel=sms or channel=whatsapp. The current desk URL parser recognizes only email and chat/website-chat channel shortcuts. Opening such a link is not evidence that the desk has filtered, ingested, or can reply to that channel. Before describing either channel as live, have the deployment owner verify sender ownership, signed inbound handling, tenant routing, desk persistence, automated reply, consent/opt-out handling, and a real delivery test. Until those checks pass, use the page as a setup/readiness surface rather than a proven operational inbox.

​
Voice and ChatGPT: separate runtime checks

Voice: verify the authenticated tenant API, published voice agent version, assigned inbound number, and reachable session history. Place a real test call and inspect its session outcome in the voice system. Do not expect a phone call to become a native chat thread automatically. ChatGPT: verify the organization-scoped deployment and its MCP connection, then perform a bounded task through that app. The readiness check probes deployment health; it does not prove that app conversations are stored in Chat Desk. See the Response ChatGPT guide.

​
Record channel readiness with evidence

Use one record per channel instead of a single “all channels connected” status:
Keep secrets out of the record. Mark unsupported and unverified capabilities explicitly. If a conversation is stuck, start with Chat Desk troubleshooting or onboarding diagnostics. Implementation checked against response-one-prod on 2026-09-20: the chat-desk list, thread, send-message, and update-thread API handlers; hooks/useChatDesk.js; channel pages; and the messaging/ChatGPT readiness handlers. Recheck these boundaries when deploying channel changes.
Last modified on September 20, 2026