Most AI chatbots have the same weak moment. The visitor asks something the bot can't answer, the bot apologises, offers a contact form, and the conversation dies. The customer wanted an answer now; they got a promise of an email later.
Live chat fixes that, but the usual objection is fair: nobody wants another inbox to watch. If your team already has Slack open all day, you don't need one. The bot can hand the conversation to your team inside Slack, and whoever picks it up chats with the customer in real time from a thread. This article answers the questions people usually ask before setting that up.
What is a Slack live chat handoff?
It is a takeover, not a notification. When the bot decides a person is needed, it posts the conversation into your Slack workspace. A member of your team replies in that thread, and their message is delivered to the visitor in the chat window on your website, word for word. The visitor's answer comes back into the same thread.
From that point you are chatting live with your client. They are on your website; you are in Slack. Neither of you had to install anything new.
The distinction that matters: a notification tells you something happened and leaves you to go and find the customer. A handoff moves the conversation to you while the customer is still there.
When does the bot hand over to a person?
Four triggers, and you control all of them.
- The visitor asks for a human. There is an always-available button in the chat for exactly this, and you write its wording. Never make someone fight a bot to reach you.
- The visitor is getting frustrated. Detected from how the conversation is going, not from keyword matching.
- The bot has failed to answer several turns in a row. You set how many. Two consecutive misses is the usual setting: enough to avoid escalating a single odd question, few enough that nobody gets stuck in a loop.
- A situation you defined yourself. You describe it in plain language — "the visitor is asking about a refund", "the visitor mentions a complaint", "the visitor is a journalist" — and the AI matches conversations against your description. No keyword lists to maintain.
That last one is the one worth spending time on. Most teams find two or three conversation types they always want a human on, and those are rarely detectable by keywords.
How does someone on my team take over?
They reply in the thread. That is the whole action. There is no button to press, no queue to join, no separate console to open. The first person to reply takes the conversation; that reply goes to the customer, and the thread becomes the place that chat lives.
This matters more than it sounds. Every extra step between "a customer needs help" and "someone is typing" is a step where the handoff dies, and a team that has to open a different tool to answer will not answer. Replying in a thread is something your team already does fifty times a day.
Formatting survives the trip. If you reply with a numbered list of steps, the customer sees a numbered list of steps, not one run-on line.
What if several people reply at once?
The first reply claims the conversation. That is deliberate: it stops two colleagues answering the same customer in parallel, contradicting each other in front of them. Everyone else in the channel can see the thread and read along, but the conversation belongs to whoever got there first.
Practically, this means you can drop handoffs into a shared channel that several people watch, without a rota and without anyone coordinating who takes what.
What does the customer see?
They see the chat continue. You choose the message shown at the moment of handover — something like "Let me get a colleague to help with that" — and then your team's replies arrive in the same window they were already typing in. No email, no "we'll get back to you", no new tab.
You can also decide whether the bot asks for contact details at the moment of handover. Taking an email before the human joins means that if the customer leaves mid-conversation, you can still reach them.
Does the AI keep answering once a human is involved?
No, and this is important. Once a handoff is raised the assistant steps back rather than talking over your colleague. Nothing is worse than a customer receiving a helpful human reply and an automated one in the same minute.
What happens if nobody picks it up?
The bot comes back. You set how long a raised handoff may wait before the assistant resumes for that visitor, and after that window the AI carries on helping rather than leaving the customer staring at silence.
This is the failure case people forget to design for. Muting your bot because a human was requested, and then not providing the human, is worse than never offering the handoff. The wait window is what keeps an unstaffed moment from becoming an abandoned customer.
What about outside working hours?
You can define when your team is actually around. Outside those hours a request for a human raises no handoff at all: the assistant keeps answering and offers the contact form instead.
That is the honest behaviour. Promising a person at 23:00 when nobody is there produces a customer who waits, gets nothing, and remembers it. Saying "the team is back tomorrow, leave your details and they'll pick this up" is a better experience than a silent thread.
Do the people answering need an account?
Yes. Anyone whose replies reach customers has to link their Slack account first, which is a one-time step. It exists for a plain reason: replies are relayed to your customers verbatim, so the system has to know exactly who is speaking on your behalf. Being in the Slack channel is not the same as being authorised to talk to your customers.
Once linked, that person just replies in threads and nothing else is required of them.
Can the team also just ask the bot things in Slack?
Yes. Separately from handoffs, the chatbot works as a Slack assistant for your own team: message it directly or mention it in a channel, and it answers from the same content it uses on your website. New starters asking about policies, sales asking what a product includes, anyone who cannot remember where a document lives.
It is the same trained bot, so anything you improve for customers gets better for your team at the same time.
How do I set it up?
- Connect your Slack workspace to your chatbot. One workspace connects to one chatbot, so pick the bot whose conversations your team should be handling.
- Choose the channel where handoffs should land. A dedicated channel works better than a busy general one, because a handoff scrolling out of sight is a missed customer.
- Have the people who will answer link their accounts. One time, per person.
- Set your triggers. Start with the "talk to a human" button and repeated failures, then add your own defined situations once you have read some real transcripts.
- Write the handover message the visitor sees, and decide whether to capture contact details at that point.
- Set your staffed hours honestly, including the days nobody is there.
- Set the wait window after which the bot resumes if nobody picks up.
- Test it end to end yourself. Open your own site, ask for a human, and answer from Slack on your phone. Anything awkward will be obvious in ninety seconds.
What this is not
Worth being straight, because it decides whether this fits your team:
- It is not a full help desk. No ticket queue, no SLA tracking, no macro library, no assignment rules beyond first-reply-wins. If you need a support organisation's tooling, you need a support product.
- It is not a replacement for the bot. The point is that the AI handles the volume and a person handles the handful of conversations that genuinely need one.
- It is not staffing. Handoff quality is a function of somebody being there. The hours and wait-window settings exist so the software behaves honestly when nobody is.
Related reading
- Channels tutorial, connecting Slack step by step
- Filtering leads before they reach a human
- Training the bot so fewer conversations need a person
- WhatsApp handover use case, the other way to reach a human