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

The thing that makes Intercom different from a ticketing system is that the customer is frequently still there. A conversation is live, somebody is waiting, and the useful window for getting an answer is minutes rather than the next working day.

That changes what a Slack integration is for. It is not a notification feed; it is a mechanism for pulling somebody with the answer into a conversation that is happening right now, and for getting their reply back to the customer before they close the tab.

What we'll cover

• Live changes the timescale
• Conversations are not tickets
• Building it with CodeWords
• Pulling in the right person
• Getting the answer back without losing the thread
• What the wider team should hear
• Bots, and knowing when to stop
• Coverage, which decides whether any of this works
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

Live changes the timescale

A customer waiting in a chat window will leave. The question is not whether the answer is correct in an hour, it is whether anybody answers before the tab closes.

Escalation has to be measured in minutes. An escalation route that involves creating a ticket and waiting is not an escalation for a live conversation.

The agent cannot wait and also serve other conversations, so a long escalation blocks them or abandons the customer.

Response time is visible to the customer in a way it is not in email, which is why the expectation is different.

Some conversations are not live at all, and treating an email-originated conversation with the same urgency wastes the mechanism.

The design consequence: the escalation path needs to reach a person in seconds and produce an answer the agent can use in the conversation, rather than producing a record that somebody handles later.

Conversations are not tickets

Worth being clear about, since the model differs from ticketing tools and it affects what you build.

A conversation continues. The same customer coming back a week later often continues the same conversation rather than starting a new one.

Assignment is to an agent or a team, and it changes hands during the conversation more often than a ticket does.

State is open, snoozed, or closed, which is fewer states than a ticketing workflow and means less structure to route on.

Tags carry the classification, and they are the main thing worth routing on, which makes tag discipline the foundation of any routing rule.

A closed conversation reopens when the customer replies, which is a case automation has to handle rather than treating closure as final.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: 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; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Pulling in the right person

Route by topic, not to a general channel. An escalation about billing and one about an API error need different people, and a general channel reaches neither reliably.

Post the question, not the conversation. What the agent needs to know, with the relevant detail already extracted. A link to a conversation is a request to read a thread, which is why those escalations sit.

Say the customer is waiting, explicitly, with how long. It is the difference between something somebody will get to and something they answer now.

Include who the customer is — plan, account size, tenure — because the person deciding whether to interrupt their work needs to know what is at stake.

Name a fallback. If nobody responds within a short window, escalate to a second channel or a specific person rather than letting it sit.

Acknowledge in the channel when somebody picks it up, so two people do not both stop what they are doing.

Getting the answer back without losing the thread

Write the reply into the conversation as a note, automatically, so the agent has it in front of them rather than switching to Slack.

Do not send it to the customer directly. The agent decides how to phrase it, what caveats apply, and whether it answers the actual question — and a raw engineering answer relayed verbatim frequently does not.

Link the Slack thread on the conversation, so the reasoning is findable later.

Tell the channel when the customer is satisfied, closing the loop for whoever helped.

Record what was escalated and why. A recurring escalation topic is a documentation gap or a product problem, and it is only visible if somebody counts.

What the wider team should hear

A short list, because a support feed in a general channel helps nobody.

A spike in conversations about one topic, to engineering and product, which is often the first sign of an incident.

A named account raising something serious, to that account's owner, promptly.

A conversation mentioning cancellation, to whoever owns the relationship.

A weekly count of what customers are asking about, to product, as prioritisation input rather than as anecdotes.

Nothing per conversation. Volume makes it unreadable and it obscures the four above.

Bots, and knowing when to stop

Intercom's automation answers a good share of conversations before a human sees them, which affects what should reach Slack.

Only escalate what the automation could not handle, or the channel receives things that were already resolved.

Watch the handover point. A customer who has been through several automated steps and still needs help is more frustrated than one who asked directly, and the escalation should say so.

Alert when deflection drops. A sudden fall in conversations resolved without a human usually means something changed — a broken flow, or a new problem the content does not cover.

Do not let the escalation become the default path. If agents escalate most conversations, the problem is knowledge rather than routing, and Slack is not the fix.

Report what gets escalated most, monthly. That list is the specification for the documentation nobody has written.

Coverage, which decides whether any of this works

An escalation route is only as good as the chance somebody is there, and that is a staffing question rather than a technical one.

Know who is actually available. A channel with twelve members has maybe two who are at their desk, and the message does not know which.

Nominate a person per period rather than relying on whoever notices. A named person answering escalations for the morning is far more reliable than a channel of volunteers.

Publish who it is in the channel, so agents know who they are waiting on and can follow up.

Respect timezones. An escalation at the edge of a region's day should route to wherever the sun is up, and a route that does not know this fails predictably every afternoon.

Have an answer for out of hours. Either the agent tells the customer somebody will follow up, or the escalation waits — decide which, and make the message say it rather than leaving the agent guessing.

Measure time to first response in the channel, since that number tells you whether the route works far better than counting escalations does.

Making it survive

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, reporting failures rather than dropping messages.

Time out gracefully. An escalation nobody answers should escalate onwards rather than disappearing.

Report the outcome. Escalations raised, answered, timed out, and written back to conversations.

Limits worth knowing about

Rate limits apply and depend on your plan, so bulk operations need pacing.

Webhook delivery is at-least-once and can be delayed.

Conversation bodies contain whatever the customer wrote, including personal details, so channel membership matters and Slack is a separate copy that Intercom's deletion process will not reach.

Tags are freeform unless the team agrees a convention, and routing on inconsistent tags fails invisibly.

Slack interactive components have a response deadline, so a slow Intercom call needs acknowledging immediately and completing afterwards.

What to set up first

Topic-routed escalation with the customer's context and how long they have been waiting, posted to a channel where the right people are, with the answer written back into the conversation as a note. It is the one thing a support team using a live chat product genuinely cannot do without leaving the tool.

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

Frequently asked questions

Why is escalation from live chat different?

Because the customer is often still there. The useful window is minutes, so an escalation route that produces a record for somebody to handle later has not escalated anything — the customer has already gone.

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 named person. A general channel reaches nobody in particular, which is the same as reaching nobody.

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

No. Write it into the conversation as a note and let the agent phrase it. A raw internal answer relayed verbatim frequently misses the actual question and reads wrong to a customer.

What should the escalation message contain?

The question with the detail already extracted, who the customer is and what plan they are on, and how long they have been waiting. Not a link to the conversation, which is a request to go and read something.

Is putting conversation content in Slack risky?

It needs care. Conversations contain whatever the customer wrote, and Slack is a separate copy that a deletion request in Intercom will not reach. Use private channels and prefer extracted detail over full transcripts.

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

Count what is escalated and on what topics, monthly. If agents escalate most conversations, the problem is knowledge rather than routing, and the same list is the specification for the documentation that would fix it.

What should trigger an alert to product?

A spike in conversations about one topic, which is often the earliest incident signal, and a weekly count of what customers are asking about. Per-conversation notifications to a wider channel help nobody.

How do I make sure somebody answers?

Nominate a named person per period rather than relying on a channel of volunteers, publish who it is, respect timezones, and time out to a second route. A channel of twelve has maybe two people at their desk, and the message cannot tell which.

What should happen out of hours?

Decide it explicitly and have the message say so, rather than leaving the agent 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.

Related reading

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