Handling Intercom Customer Support in Slack Threads
Choose the Slack-to-Intercom workflow that matches where customer conversations start
Slack and Intercom support workflows solve two different jobs. Intercom’s native connection brings customer messages from connected Slack channels into the Intercom Inbox. A bidirectional sync tool lets agents handle Intercom-originated conversations inside Slack threads. The right choice depends on the customer’s starting channel, the agent’s reply location, and where ownership and lifecycle actions occur.
| Workflow | Where the customer starts the conversation | Where agents reply | Best fit | Key constraint |
|---|---|---|---|---|
| Intercom’s native Slack channel | A connected shared, community, or Slack Connect channel | The Intercom Inbox | Supporting customers who use Slack as their contact channel | Agents primarily handle the conversation in Intercom |
| BackReply’s bidirectional Slack-thread workflow | An existing Intercom conversation | A designated Slack thread or the Intercom Inbox | Teams that want Slack-based collaboration and replies while keeping Intercom as the record | Some ownership and lifecycle actions still require Intercom |
| Deprecated legacy notification app | Intercom conversation or ticket activity | Intercom | Notifications about helpdesk activity | It does not provide Slack as an inbound support channel and is deprecated |
Intercom’s native Slack channel: Slack is the customer-facing channel
When a customer messages a connected Slack channel, Intercom creates an Inbox conversation. Fin and teammates respond through Intercom, and their replies return to the same Slack thread with the teammate’s name and avatar. Messages, threads, and attachments remain mirrored between the systems [1].
This workflow suits shared customer channels, private Slack Connect channels, and community support spaces. Slack is the customer-facing channel, while the Intercom Inbox remains the primary workspace for agents and automation.
Bidirectional syncing: Slack is the agent workspace for Intercom conversations
BackReply approaches the workflow from the opposite direction. It posts each Intercom conversation into a designated Slack channel as a thread. Teammates can collaborate there, and a public thread reply travels through the original Intercom conversation to the customer.
This model answers a common operational question: “How can we handle Intercom conversations from Slack while other agents keep working in the Intercom inbox?” Both groups work with the same helpdesk record, while Slack becomes a controlled reply surface for teammates who spend most of their day there.
Legacy notifications are not a support-channel workflow
The old Intercom app for Slack sent alerts about conversation and ticket activity. It did not turn Slack into an inbound support channel, and it was not the current two-way conversation workflow.
Intercom has deprecated the legacy Slack app and directs customers to its newer native Slack connection [2]. The replacement supports two-way conversations, Fin, and ticket management. Teams should remove the legacy app from new workflow evaluations.
Compare native Intercom Slack features with a bidirectional sync tool
“Which Intercom Slack integration keeps customer messages, replies, and file attachments synced in both directions?” requires a precise answer. Intercom’s native channel mirrors content for conversations that customers begin in Slack. BackReply syncs existing Intercom conversations into Slack so agents can respond there.
Neither model makes every Intercom action available from Slack. The matrix separates reply and collaboration features from ownership and lifecycle controls.
| Capability | Intercom native Slack channel | BackReply bidirectional sync | What the team should verify before rollout |
|---|---|---|---|
| Message direction | Supported: customer Slack messages create Intercom conversations, and Intercom replies return to the same thread | Supported: Intercom conversations appear in Slack, and Slack-thread replies return through the original helpdesk conversation | Confirm which system can initiate a conversation and how edits or delayed messages behave |
| File attachments | Supported: attachments remain mirrored between Slack and Intercom | Supported: attachments and rich content sync in both directions | Test file types, size limits, previews, permissions, and downloads |
| Assignment/ownership | Limited: the documented channel workflow does not establish all Slack-side assignment actions | Requires the helpdesk: establish or change the owner in Intercom | Confirm how the assigned owner appears in Slack and who handles reassignment |
| Ticket or conversation closure | Supported: tickets can be created and managed from Slack with automatic status updates; conversation close and reopen controls need validation | Requires the helpdesk: close, reopen, and other lifecycle actions are not established as Slack actions | Test ticket management separately from conversation close and reopen behavior |
| Dashboard requirement | Requires the helpdesk: agents answer customer messages from the Intercom Inbox | Limited: agents can reply and collaborate in Slack, while helpdesk-only actions still require Intercom | List every action that forces an agent to open Intercom |
| Internal notes | Requires the helpdesk: add internal Inbox context in Intercom unless the chosen workflow proves otherwise | Supported: prefix a Slack reply with [note] or use the Add Note button |
Confirm notes stay private and appear under the correct teammate |
| Formatting | Limited: mirrored messages are supported, but each required formatting type should be tested | Supported: bold, italic, code blocks, lists, and emoji are preserved in both directions | Test nested lists, links, mentions, code, emoji, and copied content |
| Advanced Intercom actions | Requires the helpdesk: use Intercom for actions outside documented Slack ticket management | Requires the helpdesk: tagging, snoozing, macros, saved replies, merging, priority changes, and new outbound messages require Intercom | Record which roles perform each advanced action and how Slack users request it |
BackReply can support public replies, attachments, formatting, and internal notes without an agent opening the Intercom dashboard. It does not establish Slack-side ownership reassignment or conversation close and reopen controls. Teams that need those actions must perform them in Intercom unless a pilot confirms a documented alternative.
The same distinction applies to native channels. Intercom supports ticket management from Slack, but agents answer the underlying customer conversation through the Inbox. Ticket actions and conversation actions should therefore have separate acceptance tests.
Run a shared Slack-thread workflow while Intercom remains the source of truth
A mixed workspace can support Slack-based teammates and agents who remain in the Intercom Inbox. The team needs one public response path, clear ownership, and a shared rule for private coordination.
BackReply must be installed in the Slack workspace and invited to each channel that should receive Intercom conversations. Slack users can also be mapped to Intercom admins so outgoing replies show the appropriate teammate’s name and avatar.
A conversation enters the Slack thread
- An Intercom conversation is routed to a designated Slack channel and posted as a thread. The thread carries the context teammates need to review the request and decide who will respond.
Routing the conversation does not transfer the underlying customer record to Slack. Intercom remains the source of truth, so agents working in the Inbox continue to see the customer conversation and responses recorded there.
For the reverse workflow, use Intercom’s native channel. A customer message in a connected Slack channel creates an Inbox conversation, after which replies from Intercom return to that customer’s original thread.
Teammates collaborate without creating duplicate customer replies
- Teammates discuss the request inside the Slack thread and use internal notes for context that the customer must not see. The team should distinguish public replies from notes through training, permissions, and a written response policy.
Only the designated owner should send the customer-facing response. Other participants can investigate the issue, draft language, or request an Intercom-only action without posting a competing public answer.
The assigned owner responds and Intercom retains the customer record
- The owner sends the approved public reply in Slack. BackReply passes it through the original Intercom conversation, where Inbox-based agents can see the updated customer record.
If ownership must change, make that change in Intercom. Use the Slack thread to communicate the handoff, then wait for the new owner to acknowledge it before another public reply is sent. This process keeps ownership and the conversation history aligned.
Set up routing and controls before the team starts replying
Configuration should define which customer messages enter the workflow, where conversations appear, and who may reply. It should also identify every action that remains inside Intercom.
Configure the native Intercom Slack channel
Connect the Slack workspace from Intercom, then select the channels to include. Mark each channel as conversational or notification-only. Conversational channels create synced Intercom conversations, while notification-only channels do not.
Choose whether every message starts a conversation or whether Intercom waits for specified user mentions, emoji reactions, or keywords. These triggers can apply to top-level messages and thread replies, so test them against the way customers use each channel.
Review these controls before enabling the channel:
- Confirm which Slack workspaces and channels Intercom may access.
- Restrict customer content to approved support channels.
- Decide whether all messages or selected triggers create conversations.
- Check how the workflow handles existing threads.
- Define who monitors new Inbox conversations.
- Document when Fin responds and when a teammate takes over.
Configure Slack-thread routing for Intercom conversations
Authorise the helpdesk through secure OAuth, install BackReply in Slack, and invite the app to the approved channels. Map Intercom inboxes to the Slack channels that should receive their conversations.
Routing rules can use the assignee, team, and related conditions. The first matching rule applies, so order narrow rules before broad fallback rules. Routing a conversation to a channel does not reassign its Intercom owner.
Test each route with representative conversations. Include different inboxes, assigned teams, unassigned requests, and any conditions used by the rules. Confirm that customer data reaches only the intended Slack audience.
Define a single-response rule
Give every conversation one designated customer-facing owner. That person may reply from Slack or Intercom, but the team should avoid simultaneous public responses from both workspaces.
The operating checklist should answer these questions:
- Which Slack members can view customer content?
- Who can send a public reply?
- How does a teammate add private internal context?
- Where does the team record ownership?
- How does an agent request reassignment, snoozing, tagging, merging, or a priority change?
- Who completes close and reopen actions?
- What happens when the Slack sync is delayed or unavailable?
Keep public drafts out of the live thread if any unmarked message can reach the customer. Use an internal note or a separate internal channel when the team needs to prepare a response.
Use a small-team cost method instead of assuming seat savings
“What is an affordable way for a small SaaS team to handle Intercom customer support from Slack?” depends on who needs helpdesk-only controls. Compare the seats and subscriptions required by the actual workflow rather than assuming that Slack access replaces an Intercom seat.
BackReply supports replies to Intercom conversations from Slack without requiring every participating teammate to hold an Intercom license. Treat this as a seat-allocation option, not a guaranteed saving.
| Cost input | Questions to calculate it | Why it matters for a small team |
|---|---|---|
| Slack seats | Which employees already have paid Slack access, and will the support workflow require new members? | Existing Slack access may cover regular collaborators, while external or new users can change the total |
| Intercom helpdesk seats | Which agents must assign owners, close or reopen conversations, use macros, merge records, or perform other helpdesk-only actions? | These responsibilities determine the minimum group that needs direct Intercom access |
| Integration fee | Which plan supports the required helpdesk users, workspaces, and monthly conversation volume? | The integration subscription must be added to the monthly operating cost |
| Occasional collaborators | Do engineering, product, sales, or leadership teammates need to reply, or do they only provide internal context? | BackReply plans include unlimited Slack collaborators, which may affect how occasional participation is allocated |
| Expected monthly conversation volume | How many conversations will enter Slack, and how much headroom is needed for seasonal or launch-related demand? | Conversation capacity can determine the suitable plan before seat counts do |
List the seats and fees that actually apply
Start with the people who must perform Intercom-only actions. Keep those agents in the helpdesk seat calculation. Then identify teammates who only need to review context, collaborate, add notes, or send approved replies from Slack.
A useful monthly calculation contains:
- The required Slack subscriptions.
- The required Intercom helpdesk seats.
- The BackReply integration subscription.
- Any access needed for occasional collaborators.
- Expected conversation volume and workspace count.
- Capacity for temporary increases in support demand.
BackReply may let a team limit direct Intercom access to people who need helpdesk controls. Check current Intercom, Slack, and BackReply pricing before calculating the total because no static price should be treated as current.
Use plan limits to select a trial scope
The published BackReply plan limits provide a practical way to size a pilot. The Free plan includes one connected helpdesk user, one Intercom or HubSpot workspace, and five conversations per month. It can support a narrow technical test.
The Starter plan supports up to five helpdesk users, one workspace, and 1,000 conversations per month. The Pro plan supports up to 25 helpdesk users, up to three workspaces, and 5,000 conversations per month. Select a trial that fits representative conversations, attachments, notes, routing paths, and ownership handoffs without exceeding the relevant capacity.
Test replies, attachments, ownership, and closure before rollout
Run the acceptance test in a private pilot channel with representative Slack and Intercom users. For every test, record where the action started, whether the customer saw the expected response, whether the Slack thread updated, and whether the Intercom record showed the expected state.
- Send an incoming customer message with a file. Confirm that the message, attachment, sender, and surrounding thread context appear in the connected system.
- Open the file from each workspace. Check its name, preview, download permissions, type, and relationship to the correct message.
- Send a public Slack-thread reply with a file. Confirm that the customer receives one response and that Intercom records the message and attachment under the original conversation.
- Reply from Intercom. Confirm that the response appears once in the same Slack thread and carries the expected teammate identity.
- Send messages from Slack and Intercom in sequence. Verify that both appear in the correct order within the same customer thread.
- Add an internal note from Slack using
[note]or the Add Note button. Confirm that Intercom records it as private and that the customer receives nothing. - Change the assigned owner in Intercom. Check whether Slack shows the updated state and whether the team’s routing and handoff process sends the next reply through the correct owner.
- Close the conversation or ticket through the documented interface. Record how both systems display the resulting state.
- Reopen the item from Intercom or through a supported customer response. Confirm that the Slack thread and Intercom record return to the expected active state.
- Repeat the tests with formatting, including bold text, italic text, code blocks, lists, links, and emoji. Watch for content that becomes unreadable or changes meaning.
Treat assignment, close, and reopen results as release gates. BackReply’s documented capabilities establish replies, notes, formatting, and attachment synchronization. They do not establish Slack-side reassignment or conversation close and reopen actions.
If an action is unavailable from Slack, complete it in Intercom and record the restriction in the team’s reply policy. This preserves Intercom as the authoritative record and prevents agents from relying on an incomplete Slack state.
Recommendation: select the workflow based on the support operating model
Choose Intercom’s native Slack channel when customers contact the company through shared Slack spaces, private Slack Connect channels, or community channels. Their Slack messages create Inbox conversations, and responses from Intercom return to the same customer thread.
Choose a bidirectional Slack-thread tool when teammates need to handle existing Intercom conversations from Slack. BackReply for Intercom fits teams that want Slack-based replies and collaboration while retaining Intercom as the authoritative customer record.
Keep agents in Intercom when the workflow depends heavily on assignment changes, tagging, snoozing, macros, saved replies, merges, priority controls, outbound messages, or conversation lifecycle actions. Slack participants can still contribute through threads and internal notes.
Approve either workflow only after the pilot verifies attachments, identity mapping, ownership handoffs, and close and reopen behavior. Document every action that requires Intercom rather than treating Slack as a complete helpdesk replacement.
Frequently asked questions
Is the old Intercom app for Slack still the right choice for customer support?
No. Intercom has deprecated the old notification app and directs customers to its native Slack channel integration. Check existing Slack app installations during migration so legacy alerts do not create duplicate notifications beside the new workflow.
Can Fin respond to customers in a connected Slack channel?
Yes. Fin can respond through Intercom when a customer message from a connected Slack channel creates an Inbox conversation. Test escalation behavior with customer language from your own support channels before enabling automated responses broadly.
Can we create Intercom tickets from a Slack conversation?
Intercom’s native Slack integration supports creating and managing Intercom tickets from Slack, including status updates. Ticket creation is separate from a standard Inbox conversation, so confirm which ticket types and required fields apply to the selected channel.
Should a white-glove Slack channel create an Intercom conversation for every message?
Usually only if every channel message represents a support request. For relationship-focused channels with routine discussion, use mentions, emoji reactions, or keywords to trigger conversations and reduce irrelevant Inbox records. Review trigger misses during the pilot so informal customer wording does not hide valid requests.