Helpdesk Slack: three models and how to choose between them

An internal bot turns Slack messages into tickets in a system customers never see. A Slack Connect channel makes the shared channel the desk, with the customer in it. A ticketing tool’s Slack plugin keeps the ticket as the record and lets agents act from Slack. The three differ on what the customer sees, where the record lives, and how access ends when someone leaves.

Three models side by side

The customer-contact row rests on two Slack articles: removing external people from channels doesn’t end all communication with them, and disconnecting removes them from channels and direct messages. The agent row is my inference, since Slack and the ticket tool keep separate permissions, so revoke both.

Which model fits

Work through these in order, because each answer removes options.

• Is the customer’s organization on a paid Slack plan? Channels need a paid plan on every organization in them. If not, use email, or the bot route.
• Do you promise a response time? If yes, every top-level customer message has to become a timestamped record without anyone remembering to log it. A bot that creates tickets only on an emoji reaction undercounts, because nobody reacts to a message they haven’t seen. Start the clock as the Slack Connect SLA guide describes.
• Must the record survive an internal audit? If yes, the record belongs in a system where you control export. Read the audit section first.

Rule: no paid plan on the customer side means email or the bot route. Paid plan, no clock, no audit need: a shared channel is enough. Paid plan plus a clock or an audit trail: the plugin, with the ticket as the record. This threshold is my own starting point, not a standard: move off a bare shared channel once you have more than about five agents or a few dozen threads a day.

If you build the bot route, store the Slack channel ID and message timestamp on each ticket so you can link back. Choose the trigger knowing its cost: an emoji-only trigger misses messages nobody reacts to.

Setting up the Slack Connect channel

Slack Connect is open to all members except Frontline Members and guests, on all plans. Only the organization that owns a channel can invite others, and invitations are managed from Home, then Directories, then External.

The Slack Connect guide doesn’t say whether admins must approve channel creation. Test it before the first customer: create a channel, invite a second workspace you control, accept from that side, and note any approval step.

A channel holds up to 250 organizations. One channel per customer organization keeps histories separate, which is my recommendation rather than a Slack requirement. Each organization chooses whether others see basic profile details or extended ones such as statuses and time zones, so check your setting before assuming customers see agent names.

Welcome post, pinned on day one:

“We’re handling your support requests in this channel now. Post each new issue as a new top-level message and we’ll reply in its thread. Please don’t send requests by direct message, because those don’t reach our queue.”

Direct messages can start on any Slack plan, so a Free-plan customer can still DM you. The welcome post is the cheapest way to route those.

The ticketing plugin route

Zendesk’s integration article sets the rules for its plugin in a shared channel:

• The Create a ticket action sits in the More actions menu. It adds the ticket as a reply to the Slack thread, and works only in channels where the integration has been invited.
• The created_from_slack tag is added to tickets created in Slack. The @zendesk mention in a Slack Connect channel does not add it, although the article says internal and external users there can create tickets with that mention.
• External users can’t use the global shortcut and don’t see the Assignee field.
• The requester defaults to the Slack user. An unrecognized Slack user creates a new end user.
• The article lists Support plans Team, Professional or Enterprise, and Suite plans Team, Growth, Professional, Enterprise or Enterprise Plus, as supporting the integration. It doesn’t mention add-ons.

The article doesn’t say how Slack users match existing Zendesk users by email, doesn’t mention merging, and doesn’t say where the Slack channel is stored on a ticket. Test with a contact who already emails you before you trust the requester field.

Failure mode: a report filtered on created_from_slack undercounts, because mention-created tickets don’t carry it. Fix: sample the channel instead of counting tags. Each month, take the last 20 top-level messages in a shared channel, open each thread, and confirm a ticket exists for it. My threshold, not a standard: more than one miss in 20 means the routing is leaking, so fix the trigger before you report numbers.

Customers often write on both channels. Use the customer’s email address as the one identifier on every Slack-origin ticket. When a request arrives both ways, reply where the customer asked and add one line in the other: “We’re answering this in our Slack channel, linked here.”

For any other ticketing tool, check these in its current docs before you buy. I haven’t verified other vendors’ Slack integrations, so these are questions, not claims:

• Which plans include the Slack integration.
• Whether a ticket comes from a thread, a message action, or every message.
• Whether a Slack user matches an existing requester by email.
• Whether a tag or field records the Slack origin, and whether a mention sets it.

Audit, export and retention

Slack’s data management article says content sent by external people follows their organization’s retention settings. Your own retention policy doesn’t decide how long the customer’s messages exist.

On any paid plan, owners and admins can export public channels shared with other companies. Business+ and Enterprise owners can apply to export private channels and DMs with external people. Exports exclude the list of members from outside your organization, so an export can’t tell you who was in the channel.

Rule: if an auditor needs the customer’s side of a commitment, the ticket must contain it. Example: a customer writes “Can you confirm the export fix ships before our Thursday review?” The ticket gets that sentence verbatim, a due field set to Thursday, and the Slack thread link. When someone asks what you promised, the answer is on the ticket.

Departed employees: Slack’s profile deletion article says content that isn’t profile information stays in Slack, and lists a member’s message content from channels and DMs as an example. It also says a Workspace Primary Owner can delete profiles for deactivated members on Free, Pro and Business+. The article doesn’t address deactivated members in Slack Connect channels. Test it: deactivate a test account that has posted in a channel shared with a second workspace you control, then check from that second workspace.

Offboarding and failure modes

• A customer contact leaves their company. Owners and admins remove that person from channels in the external people dashboard, individually or in bulk. Removal doesn’t end all communication, so also revoke their ticket access and check their direct messages.
• A whole organization exits. Disconnecting removes its people from channels and direct messages. Reserve it for that case.
• The customer DMs an agent. Reply: “Please post this in the channel so it reaches our queue.” Ask the customer to repost the request there themselves. If they’d rather you repost it, post only a neutral summary, such as “Picking up the export question from earlier,” and only after they agree. Don’t quote their DM or link the ticket in the shared channel, because the customer’s colleagues and anyone else in the channel can see both. Put their verbatim words and the ticket link in the ticket. Check agent DMs at the start of each shift, which is my suggestion.
• A triage note reaches the customer. App and shortcut messages are visible to everyone in the channel. Keep triage notes in the ticket tool.

Moving between models

Most teams start with a bare shared channel and need a record later. Move in this order:

• Keep the channel, and run the sample check on the last 20 threads to see how many already have a record.
• Install the plugin and invite it to each shared channel, since the Create a ticket action works only where it has been invited.
• From cutover, create a ticket for every new top-level message and copy the customer’s words into it verbatim.
• For threads still open at cutover, create tickets and copy in the request. Don’t backfill closed threads unless an audit needs them.

This is not legal advice. I haven’t verified how each tool handles deletion or erasure requests, so check each vendor’s terms and your counsel’s view before promising a customer deletion.

Where a shared-channel inbox fits

Weft is a support inbox for teams that answer customers in Slack Connect channels and by email. Its homepage says each customer message in a shared Slack channel becomes a thread in one queue, with the customer and account attached, and that replies go out under the agent’s own name and avatar, not a bot account. Email from your own support address is listed under the Starter plan.

It fits a team whose customers already sit in shared channels, who also write by email, and who want one queue without a separate ticket system. If most customers aren’t on Slack, start with email and add channels for the accounts that are.

It doesn’t fit these needs:

• Response clocks, escalations or SLA timers now. The homepage marks workflows, SLAs and escalations as Soon, so they are planned rather than live.
• Customers whose organization is on a Free Slack plan. Channels need a paid plan on every organization, so use email for them.
• Audit logs, Microsoft Teams, SAML SSO or self-hosting. Don’t assume any of these. Ask before you rely on one.