Customer support channels
Choose how requests enter and how your team responds.
Configure website chat, forms, email and supported API intake with explicit activation, defaults and the real delivery requirements of each channel.
Several intake routes still need one clear service organization.
Channels describe how a customer reaches the helpdesk. A channel's kind, configuration and state affect the public entry point and the return path. Create only the channels the team can maintain. A draft configuration does not prove that a website visitor can submit a request, a mailbox can receive it or a public reply reaches the intended customer.
Match the channel kind to the real customer interaction.
Website chat supports the embedded conversation experience, forms capture structured intake, email uses a linked shared mailbox, and the supported API door serves configured intake. Other listed channel concepts should not be assumed active adapters. Review each channel's supported setup rather than treating the presence of an idea in a roadmap or registry as a live connection to every messaging network.
- Distinct widget, form, email and supported API intake
Set defaults and public boundaries before activation.
Choose relevant default team, priority and tags where the channel supports them. Website embeds need permitted origins and appropriate appearance and visitor wording. Channel states such as draft, active, paused and error make configuration distinct from operation. Pausing a channel should trigger an operational review of how customers will contact the company instead, rather than silently leaving an advertised route unstaffed.
- Activated configuration with appropriate defaults and allowed embed origins
Test the actual reply route, especially for email.
An email channel requires selecting and activating a connected shared mailbox. New qualifying incoming mail after linking is processed into tickets; the feature is not a promise to import every historic email as a support case. Public replies leave through the linked mailbox and depend on working background services. Verify the customer receives the intended response and that internal notes are never mistaken for an external reply.
- Configured shared-mailbox intake and verified outward delivery
A concrete workflow
Select
Choose the supported route your customer actually needs.
Configure
Review defaults, public wording and allowed embed origins.
Activate
Enable only after required connection services are ready.
Verify
Submit as a customer and verify ticket and reply.
An illustrative working example
Illustrative scenario: adding email to an existing support form
A team already uses a support form and adds an email channel for existing customers. The administrator connects a shared address, selects it in channel setup and activates the link. A new test email becomes a ticket, and the responder verifies the outgoing reply from the expected service address. The team keeps the form's defaults separate and does not assume old inbox history has been converted into tickets.
Questions about this topic
Does every configured channel immediately receive requests?
No. Activation and the required live connection or public setup must be verified.
Are all messaging networks supported?
No such blanket claim is made. Check the actual supported channel adapter and deployment setup.
Does email intake import the whole mailbox history?
The configured flow handles qualifying new mail after the link, not automatic ticket migration of every historic message.
Can I pause a channel?
Yes. Review the customer-facing alternative and the channel state rather than leaving the advertised route unchecked.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
Gmail
Application concept: Plan a configured shared Gmail service address as an email channel, checking activation and actual incoming and outgoing flow.
Outlook
Application concept: Verify the supported Outlook mailbox connection before planning an active shared-email support channel.
Intercom
Application concept: Compare Intercom website-intake expectations with Tsumira's actual chat and form channel configuration.