> ## Documentation Index > Fetch the complete documentation index at: https://docs.stateset.com/llms.txt > Use this file to discover all available pages before exploring further. # Chat Desk Across Channels > Understand how website chat, managed email, helpdesk integrations, SMS, WhatsApp, Voice, and ChatGPT relate to the ResponseCX desk. 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 | Channel | Configure or inspect | Relationship to Chat Desk | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Website chat | [Widget Builder](https://response.stateset.com/widget-builder), [Chat channel](https://response.stateset.com/channels/chat) | Hosted widget conversations can create native chat threads with operator replies and internal notes | | Managed support email | [Email settings](https://response.stateset.com/settings/email), [Email channel](https://response.stateset.com/channels/email) | Email response records can resolve to managed-mail conversations with provider-backed replies and supported conversation controls | | Other chat/email response records | The owning integration and Response history | Visible for review when included in the desk query; the composer is disabled unless a supported native chat or managed-email send path exists | | Gorgias helpdesk workflows | [Workflow Studio](https://response.stateset.com/workflow-studio) and the connected helpdesk | Provider handoff/status integration exists for eligible records; desk visibility is not a general-purpose Gorgias reply transport | | SMS | [SMS channel](https://response.stateset.com/channels/sms) | Readiness can report ingress-ready, but currently reports conversation automation as unavailable; no dedicated SMS desk query/send path is established here | | WhatsApp | [WhatsApp channel](https://response.stateset.com/channels/whatsapp) | Current readiness reports setup-required, no inbound route, and no conversation automation | | Voice | [Voice channel](https://response.stateset.com/channels/voice) | Separate voice runtime, published agent, number routing, and session history; voice calls are not included by the current desk list query | | ChatGPT | [ChatGPT channel](https://response.stateset.com/channels/chatgpt) | Organization-scoped app/MCP deployment with its own health check; reachability does not establish desk transcript ingestion | 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](/stateset-response/chat-desk-widget) 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](/guides/first-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](/stateset-response/stateset-response-chatgpt-guide). ## Record channel readiness with evidence Use one record per channel instead of a single “all channels connected” status: ```text theme={null} Channel and environment: Organization and owning provider/runtime: Inbound test and provider message/ticket/session ID: Desk conversation ID, or not supported/not observed: Automation result and run/response ID: Human reply path tested: Outbound delivery evidence: Assignment, review, and escalation owner: Remaining blocker and next action: ``` Keep secrets out of the record. Mark unsupported and unverified capabilities explicitly. If a conversation is stuck, start with [Chat Desk troubleshooting](/stateset-response/chat-desk#troubleshooting) or [onboarding diagnostics](/guides/onboarding-troubleshooting). 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.