How to connect Intercom to Slack to bring an expert into a live chat

To connect Intercom to Slack, build an escalation path that reaches a person with the answer in seconds and returns their reply to the agent inside the live conversation. The customer is often still in the chat, so the useful window is minutes. A Slack notification feed does not solve that, but a routed escalation does.

Key takeaways

• Intercom conversations are often live, so escalation must reach a person in seconds and produce an answer the agent can use right away.
• Route escalations by topic, post the question with the customer's context, and add a timeout to a second route.
• Write the expert's answer back into the conversation as a note, and let the agent phrase the reply to the customer.
• Send the wider team only a short list of signals, such as topic spikes, serious accounts and cancellation mentions.
• Coverage decides whether the route works, so name a person per period and plan for out-of-hours.

What we'll cover

• Why does live chat change the timescale?
• How are conversations different from tickets?
• How do you build it with CodeWords?
• How do you pull in the right person?
• How do you get the answer back without losing the thread?
• What should the wider team hear?
• How do bots affect what reaches Slack?
• How do you make sure somebody answers?
• How do you keep the integration reliable?
• What are the limits?
• What should you set up first?
• Frequently asked questions

Why does live chat change the timescale?

Live chat changes the timescale because the customer is waiting now. A customer in a chat window leaves if nobody answers, so an escalation must be measured in minutes. Creating a ticket and waiting is not an escalation for a live conversation.

• The agent cannot wait and serve other conversations, so a long escalation blocks the agent or abandons the customer.
• Response time is visible to the customer in a way it is not in email, so expectations are different.
• Some conversations are not live. An email-originated conversation does not need the same urgency.

The design consequence: the escalation path reaches a person in seconds and produces an answer the agent can use in the conversation, not a record that somebody handles later.

How are conversations different from tickets?

Conversations continue, change hands often and have few states, so tags carry most of the routing information. This model differs from ticketing tools and shapes what you build.

• A conversation continues. The same customer returning a week later often continues the same conversation.
• Assignment goes to an agent or a team and changes hands during the conversation more often than a ticket does.
• State is open, snoozed or closed. Fewer states mean less structure to route on.
• Tags carry the classification. They are the main thing worth routing on, so tag discipline is the foundation of any routing rule.
• A closed conversation reopens when the customer replies, and automation has to handle that case.

How do you build it with CodeWords?

Build it in CodeWords by describing the escalation to Cody, the automation builder, in plain language. CodeWords connects to 3,000+ integrations (CodeWords pricing page, 2026), and you make each connection once and reuse it.

1. Open CodeWords and start a new automation.
2. Describe to Cody which conversations, what triggers an escalation and who should be reached.
3. Authorize the connection to Intercom with an access token, and to your Slack workspace.
4. Describe the exceptions: a conversation already closed, a customer who has left the chat, nobody available in the escalation channel.
5. Test with your own conversations into a test channel before anything reaches the team.

You describe the outcome, and Cody builds, connects and deploys it. The Free plan costs $0, Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

How do you pull in the right person?

Pull in the right person by routing on topic and posting the question with the customer's context. A billing escalation and an API error escalation need different people, and a general channel reaches neither reliably.

• Post the question, not the conversation. Include what the agent needs to know, with the relevant detail extracted. A link is a request to read a thread, which is why those escalations sit.
• Say the customer is waiting, and for how long. This separates something people get to from something they answer now.
• Include who the customer is: plan, account size and tenure. The person deciding whether to interrupt their work needs to know what is at stake.
• Name a fallback. If nobody responds in a short window, escalate to a second channel or a specific person.
• Acknowledge in the channel when somebody picks it up, so two people do not both stop what they are doing.

How do you get the answer back without losing the thread?

Write the expert's reply into the conversation as a note, and let the agent decide what to send. The agent then has the answer in front of them without switching to Slack.

• Do not send the reply to the customer directly. The agent decides the phrasing and the caveats, and checks that it answers the actual question. A raw engineering answer relayed verbatim often does not.
• Link the Slack thread on the conversation, so the reasoning is findable later.
• Tell the channel when the customer is satisfied, so whoever helped knows the loop closed.
• Record what was escalated and why. A recurring topic is a documentation gap or a product problem, and it is visible only if somebody counts.

What should the wider team hear?

The wider team should hear four signals, and nothing per conversation. A support feed in a general channel helps nobody.

• A spike in conversations about one topic, sent to engineering and product. This is often the first sign of an incident.
• A named account raising something serious, sent promptly to that account's owner.
• A conversation mentioning cancellation, sent to whoever owns the relationship.
• A weekly count of what customers ask about, sent to product as prioritization input instead of anecdotes.

Per-conversation messages make the channel unreadable and hide these four.

How do bots affect what reaches Slack?

Intercom's automation can answer conversations before a human sees them, so only conversations it could not handle should reach Slack. Otherwise the channel receives items that were already resolved.

• Watch the handover point. A customer who went through several automated steps and still needs help is more frustrated than one who asked directly. The escalation should say so.
• Alert when deflection drops. A sudden fall in conversations resolved without a human usually means a broken flow or a new problem the content does not cover.
• Do not let escalation become the default path. If agents escalate most conversations, the problem is knowledge, and Slack is not the fix.
• Report the most-escalated topics monthly. That list is the specification for the documentation nobody has written.

How do you make sure somebody answers?

Make sure somebody answers by treating coverage as a staffing question: name a person per period, publish who it is and plan for time zones and out-of-hours. An escalation route is only as good as the chance somebody is there.

• Know who is available. A channel with twelve members may have two at their desks, and the message cannot tell which.
• Nominate a person per period. A named person answering escalations for the morning is more reliable than a channel of volunteers.
• Publish who it is in the channel, so agents know who they wait on and can follow up.
• Respect time zones. Route an escalation at the edge of one region's day to a region where the working day is under way.
• Decide the out-of-hours answer. Either the agent tells the customer somebody will follow up, or the escalation waits. Make the message say which.
• Measure time to first response in the channel. This number shows whether the route works far better than counting escalations.

How do you keep the integration reliable?

Keep it reliable by making alerts idempotent, handling reopened conversations and reporting outcomes.

• Make it idempotent, keyed on the conversation and the escalation, so a retried webhook does not ask twice.
• Handle the reopened conversation as a normal case, since closure is not final in Intercom.
• Map agents and experts to Slack users from your directory, and report failures instead of dropping messages.
• Time out gracefully. An escalation nobody answers escalates onward instead of disappearing.
• Report the outcome: escalations raised, answered, timed out and written back.

What are the limits?

Five limits apply: rate limits, webhook delivery, personal data in Slack, freeform tags and Slack response deadlines.

• Rate limits apply and depend on your plan, so bulk operations need pacing. Check Intercom's API documentation for your plan.
• Webhook delivery can repeat or be delayed, so handle duplicates.
• Conversation bodies contain whatever the customer wrote, including personal details. Slack holds a separate copy that Intercom's deletion process does not reach, so channel membership matters.
• Tags are freeform unless the team agrees a convention, and routing on inconsistent tags fails silently.
• Slack interactive components have a response deadline. Acknowledge a slow Intercom call immediately and finish it afterwards.

What should you set up first?

Set up topic-routed escalation first: the customer's context and wait time posted to a channel with the right people, with the answer written back into the conversation as a note. A support team using live chat cannot do this without leaving the tool.

Two habits make the difference. Post the question instead of a link to the conversation, since a link is a request to read a thread and that is why escalations sit. And add the timeout to a second channel from the start, because an escalation nobody sees is worse than no escalation route.

Frequently asked questions

Why is escalation from live chat different?

The customer is often still in the chat, so the useful window is minutes. An escalation route that produces a record for somebody to handle later has not escalated anything, because the customer has left by the time anyone reads it. Live chat needs a route that reaches a person in seconds.

Should escalations go to a general engineering channel?

No. Route by topic to a channel with the people who can answer, and add a timeout to a second channel or a named person. A general channel reaches nobody in particular, which is the same as reaching nobody, and the escalation sits until the customer has gone.

Should the expert's answer go straight to the customer?

No. Write the answer into the conversation as a note and let the agent phrase the reply. A raw internal answer relayed verbatim often misses the actual question and reads wrong to a customer, while the agent knows the context and the tone the customer expects.

What should the escalation message contain?

Include the question with the detail already extracted, who the customer is and what plan they are on, and how long they have waited. Do not rely on a link to the conversation, because a link asks the expert to read a thread before they can help.

Is putting conversation content in Slack risky?

It needs care. Conversations contain whatever the customer wrote, and Slack holds a separate copy that a deletion request in Intercom does not reach. Use private channels and prefer extracted detail over full transcripts, so less personal data lands in Slack in the first place.

How do I know if the escalation route is being overused?

Count what is escalated and on which topics, every month. If agents escalate most conversations, the problem is knowledge, not routing. The same list is the specification for the documentation that would reduce escalations, so it points directly at what to write next.

What should trigger an alert to product?

Alert product on a spike in conversations about one topic, which is often the earliest incident signal, and on a weekly count of what customers ask about. Per-conversation notifications to a wider channel help nobody, because volume makes them unreadable and hides the signals that matter.

How do I make sure somebody answers?

Nominate a named person per period instead of relying on a channel of volunteers, publish who it is, respect time zones and time out to a second route. A channel of twelve may have two people at their desks, and the message cannot tell which two.

What should happen out of hours?

Decide it explicitly and have the message say so, so the agent is not guessing. Either the escalation waits and the agent tells the customer somebody will follow up, or it routes to a region where the working day has started and an expert is available.

Related reading

• Intercom and CodeWords
• Connecting Zendesk to Slack
• CodeWords integrations and templates