Live Chat
How Octocom decides whether an agent's reply reaches the customer in the chat widget or by email — the availability rules, the automatic switching in both directions, and why a reply is never delivered where nobody will see it.
When a web chat conversation is handed off to your team, every agent reply has to answer one question first: where will the customer actually see this? A chat message delivered to a widget nobody is looking at is a message nobody ever receives — it doesn't bounce, it doesn't notify anyone, it simply goes nowhere. Email, by contrast, always arrives.
The reply channel is Octocom's live answer to that question, and it is deliberately dynamic:
Replies go to the chat widget only while the customer is actually there and someone is available to chat. The moment the customer leaves, replies switch to email. The moment they come back, replies switch back to chat. Both directions are automatic — no agent action required.
This page explains how that decision is made, what makes live chat count as "available", and the situations where a conversation stays on email even though the customer has the widget open.
The principle: no replies into the void
It can feel wrong the first time you see it: a customer wrote in via chat, and your agent's answer went out as an email. Almost always, that is the system working exactly as intended — by the time the agent replied, the customer had left the widget, and a chat reply would have been invisible to them forever.
This is also why the email fallback cannot be switched off. Disabling it would not make replies reach the widget; it would mean a customer who closed the tab never receives their answer at all. The choice is never "chat or email" — it is "email or nothing".
The reverse is equally deliberate: while the customer is sitting in the widget and your team is available, replies always go to the widget. A customer watching the chat should never be answered by a cold email.
When live chat counts as available
Live chat availability is checked when the conversation is handed off, and then re-checked continuously for as long as the conversation stays open. All of the following must hold:
| Condition | Detail |
|---|---|
| It's a web chat conversation | Conversations that arrived by email or other channels never switch to the widget. |
| Live chat is enabled | A per-widget setting. With live chat off, handoffs go straight to email. |
| Someone can actually answer | At least one eligible agent is currently available — see below. |
"Someone can answer" means at least one eligible agent is currently available: not marked as unavailable, inside their working hours (if working-hour availability is enabled for your organization), and recently active in the dashboard — within the last five minutes — if activity-based availability is enabled. If an assignment rule routes the conversation to a specific team or person, only that team or person is counted.
If live chat is not available at the moment of handoff, the reply channel is set to email immediately and the customer is told the team will follow up by email. This is not final — see Switching back to chat below.
How Octocom knows the customer is there
While the chat panel is open and the browser tab is visible, the widget continuously signals presence. Closing the tab, navigating away, or closing the chat panel registers within seconds; a customer who simply stops pinging (laptop lid closed, network dropped) is marked as away within about a minute.
Two details worth knowing:
- A background tab counts as away. A customer who switches to another tab or minimises the browser is not watching the chat, so they are treated as not present. If they come back to the tab, presence — and the reply channel — recovers automatically.
- Presence is per-conversation and continuous. There is no fixed "session" that expires while the customer is actively there.
Switching to email
When a handed-off conversation loses the customer's presence while its reply channel is still chat:
- The reply channel switches to email.
- If no agent had replied yet, the widget leaves a short message for the customer ("Seems like you're not here anymore — we'll get back to you via email…"), so a returning customer knows what to expect.
- A timeline event is written on the conversation ("Customer left chat widget. Setting reply channel to email."), so agents can always reconstruct why a reply went where it did.
The same switch to email happens when the customer explicitly ends the chat: closing the conversation in the widget, clearing their chat history, or starting a new conversation while an old handed-off one is still open.
Switching back to chat
Coming back is just as automatic — and the customer doesn't even need to type. Reopening the widget is enough. Within seconds of the customer returning, Octocom re-checks live chat availability, and if someone can answer, the reply channel flips back to chat and a timeline event records it ("Customer came back to chat widget, setting reply channel to web"). Sending a message triggers the same re-check.
This also covers the "no agents were available at handoff" case: a customer who stays in the widget while one of your agents becomes available is switched to chat the moment that happens — the initial email decision is revisited continuously, not made once.
The reply channel will not switch back when:
- Live chat isn't available at that moment — nobody available, or outside working hours. The conversation stays on email, which remains the only channel guaranteed to reach the customer.
- The customer ended the chat themselves — closed the conversation, cleared history, or started a new one. Ended means ended; only their new conversation is live.
What your agents see
Agents never choose the reply channel manually — the reply box in the help desk always targets the conversation's current reply channel, and it updates in real time. An agent watching a conversation will see the composer flip from chat to email the moment the customer leaves, and back again when they return.
Combined with the timeline events, this answers the most common support question about live chat: "why did my reply go out as an email?" Open the conversation timeline — you will find the exact sequence of the customer leaving, returning, and the channel following them.
FAQ
A customer wrote in via chat and got an email reply. Is that a bug? Almost certainly not. It means that at the moment your agent replied, the customer was not present in the widget (or live chat was unavailable). Check the conversation timeline — the channel switches are all recorded there with timestamps.
The reply channel says email but the customer swears they had the chat open. A minimised window or background tab counts as away — presence requires the chat panel open in a visible tab. If they return to the tab, the channel recovers on its own.
Why doesn't the reply channel switch to chat when my agent replies? Because the agent replying tells us nothing about whether the customer can see the widget — the customer's presence does. If the customer is there, the channel has already switched before the agent's reply is sent; if they're gone, chat delivery is impossible and email is the only channel that reaches them.
Handoffs always go to email even when my team is online. This is nearly always agent availability: agents marked unavailable, outside working hours, or (with activity-based availability) not active in the dashboard in the last five minutes. An agent who has the dashboard open but hasn't interacted with it recently can count as away.
Can we turn the email fallback off so everything stays in chat? No. A chat reply to an absent customer is never delivered — not delayed, never delivered. The fallback exists so every customer gets their answer, wherever they are. If you want fewer conversations to fall back to email, the lever is availability: more agents online during the hours customers chat.
Does this apply to social and WhatsApp conversations? No — this page is about web chat. Conversations on social channels and WhatsApp are asynchronous and simply stay on their own channel.