Live Chat
How Octocom decides whether an agent's reply reaches the customer in the chat widget or by email — the availability rules, the ten-minute fallback for replies nobody saw, and the automatic switching in both directions.
When a web chat conversation is handed off to your team, every agent reply has to survive one hazard: a reply delivered to a widget nobody is looking at is a reply nobody ever receives. It doesn't bounce, it doesn't notify anyone, it simply sits there. Email, by contrast, always arrives.
The reply channel is how Octocom handles that, and it is deliberately dynamic:
Replies go to the chat widget while the conversation is live there. If an agent's reply sits unseen in the widget for ten minutes, Octocom re-sends that same reply by email and moves the conversation to email. If the customer comes back to the widget, replies go 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: observed, not predicted
Octocom does not try to work out in advance whether a customer is still around. It cannot: a minimised window, a background tab, a phone that locked, a customer reading the page below the widget — none of these are distinguishable from someone who closed the tab and left for the day, and treating them as departures sends cold emails to people who are sitting right there.
So the reply goes to the widget, where the customer asked for it, and Octocom watches what happens next. If the customer was there, they saw it and nothing else happens. If ten minutes pass with no sign of them, the same reply goes out again by email. Getting that judgement wrong is cheap in one direction — a customer receives their answer twice — and expensive in the other, which is why the check is generous and the fallback always fires.
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.
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 a reply was seen
While the chat panel is open and the browser tab is visible, the widget checks in every fifteen seconds. That signal is a plain "the customer was here at this time" — nothing is torn down when it stops.
A reply counts as seen if any check-in arrives after that reply was sent. That's it. The comparison is per-reply and per-conversation.
What follows from this:
- A background tab is not a departure. A minimised window, another tab, a customer scrolling the page with the panel closed — none of it ends the chat or moves the channel. The widget prefixes the browser tab title with an unread count and plays a short sound when a reply arrives (the customer can mute it in the widget's settings), so a customer who is elsewhere on the page gets pulled back.
- Navigating between pages is not a departure either. The customer carries the conversation with them across your site.
- Each reply has its own ten-minute clock. An agent who keeps typing does not reset the timer on their earlier messages, and does not delay the fallback.
The ten-minute email fallback
When an agent's reply has gone ten minutes with no check-in after it:
- The customer is emailed the reply itself — the agent's actual words, not a "you have a new message" nudge. There is nothing to come back to the widget for. Several replies in the same window are combined into one email, in the order they were sent, attributed to the agent who sent the last of them.
- The widget message stays exactly as it was. This is a second delivery of one reply, not a move — the conversation transcript, its timestamps and your response-time metrics are all untouched.
- The reply channel switches to email, so the customer's reply from their inbox lands on the same conversation and the agent's composer follows.
- A timeline event records it ("Agent message was not seen in the chat widget. Sent it by email and set reply channel to email."), so agents can always reconstruct why a reply went where it did.
Two things must be in place for the fallback to fire, and if either is missing the reply stays in the widget:
- Octocom knows the customer's email address. An anonymous visitor who never identified themselves cannot be emailed.
- Your business has an email integration connected. Without a mailbox to send from, there is nothing to fall back to.
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.
Because nothing was torn down when the fallback fired, this is a clean flip back: the conversation was never closed, requeued or reassigned.
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 their history, or started a new chat. Ended means ended; only their new conversation is live. Each of these writes its own timeline event and moves the old conversation to email.
- The chat has been quiet for over an hour and your live chat runs through an external provider (LiveChat, Zendesk). A browser tab restored the next morning would otherwise re-queue a customer who gave up hours ago. They can still resume by sending a message.
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 to email when the fallback fires, and back to chat when the customer returns.
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 reply that went unseen, the email that followed it, and any switch back.
FAQ
A customer wrote in via chat and got an email reply. Is that a bug? No. It means the reply sat in the widget for ten minutes with no sign of the customer, so it was re-sent to their inbox. They received it in both places. The conversation timeline records exactly when.
Can a customer be emailed while they are sitting in the widget? Only if they went ten minutes without the widget checking in — which means the panel was closed or the tab was hidden that whole time. Simply having the chat open, in a visible tab, prevents it.
My agent replied and nothing was emailed, even though the customer had clearly left. Check that Octocom has an email address for that customer and that your business has an email integration connected. Without both, there is nowhere to send the fallback and the reply stays in the widget.
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 returning does — and it flips the channel back within seconds.
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.