Live chat is the real-time messaging surface where a human agent talks to a customer inside your website or app, rather than over email or phone. For teams evaluating support channels, it is the lowest-friction way to convert an automated conversation into a human one without losing context. This explainer defines the term, names what a deployment actually has to operate, maps each piece to shipped surfaces on Devotel Orbit, walks the staffing math and the bot-versus-human decision, and ends with a worked scenario and an FAQ.
What live chat actually is
Live chat is a synchronous, text-based channel embedded in a web page or mobile app. A visitor opens a chat widget, a routing layer assigns the conversation to an available agent, and both sides exchange messages in real time. Unlike email, the session is live and typically resolved in one sitting. Unlike voice, agents can handle several sessions concurrently, which is why chat consistently lands as the most cost-efficient human-support channel per resolved contact.
Two boundary cases settle the definition. A chatbot alone is not live chat — it is automation in front of the channel, and the "live" in live chat refers to the human side. A chat window that posts an email form is not live chat either; it is a contact form wearing the same shape. The defining property is a staffed, real-time session.
What a live-chat deployment has to operate
A definition that stops at "a chat box on a website" hides the machinery a working deployment carries. Five components, each with its own failure mode:
- The reception widget. The embed on your site or app that captures the visitor, opens a session, and ties that session to an identity — anonymous at first, then an email address or account id once the visitor supplies one. If the widget cannot carry identity across pages and sessions, every conversation starts from zero.
- The routing queue. Something has to decide which team or agent owns the new conversation — by intent, language, customer tier, or channel — and what happens when nobody is available. A widget without a queue is a suggestion box.
- The bot tier. Most deployments put automation in front: the bot triages, answers the intents it can resolve, and escalates the rest. The design question is not bot or human but where the escalation boundary sits.
- The agent surface and system of record. Agents need one place to work conversations, and the conversation itself has to be one object — not a per-channel fragment — or context is lost every time the customer moves.
- Transcript continuity. When the conversation changes hands or changes channels, the full history travels with it. A hand-off that loses the transcript forces the customer to repeat themselves, and the channel's core promise — no lost context — is gone.
How Devotel Orbit's shipped surfaces map to those five
Each component above is a named, shipped surface rather than a diagram box.
The conversation as one thread. The conversations concept describes Orbit's model: a conversation (conv_…) is the single thread that owns every message a contact has exchanged, across every channel the thread has touched. The channel is a label on each message, not a separate thread — so a conversation that starts in the web widget and later continues on WhatsApp or SMS is still one object, with ownership (assignee, queue, team) attached to the thread rather than to whichever channel arrived last. That model is what transcript continuity means in practice.
Channels and routing into the inbox. The inbox setup guide walks the operator surface end to end: connect inbound channels, then write routing rules that assign a conversation the moment it arrives — by channel, keyword, language, country, sentiment, or customer segment — to a user, a team queue, or a round-robin pool. That is the routing queue component, configured per workspace.
The bot tier and the hand-off. A routing rule can hand the conversation to an AI agent first (trigger_agent), and the human hand-off carries the full transcript so the agent starts where the automation stopped. The same conversations concept page covers the AI-agent session: the agent attaches to the conversation, not the channel, so its context survives a channel switch instead of restarting.
SLA timers on first response. Live chat creates a staffing promise, and the promise is only real if it is measured. The inbox SLA timers guide documents the policy engine: a first-response clock that starts on the customer's first inbound message, a next-response clock for follow-ups, and a resolution clock — each with breach actions that notify, reassign, or post to Slack or Teams the moment a target is crossed. Before any policy exists, the workspace reports against synthetic defaults (4-hour first response, 24-hour resolution), so the dashboard badge works from day one.
Cross-channel continuation. When a visitor leaves the browser, the thread does not have to end. The continue-conversation-across-channels guide documents moving the same conversation onto WhatsApp, SMS, or email — from the inbox header or over the API — with the conversation id, full message history, and AI-agent session intact; only the default reply channel changes.
Staffing math: concurrent sessions versus voice 1:1
Voice is a one-to-one channel: an agent on a call serves exactly one customer. Chat is many-to-one — a competent agent works several sessions in parallel — and that ratio is the entire economic argument for the channel. Getting the ratio wrong in either direction hurts: set it at one and chat costs what voice costs; set it at six and first-response times collapse under load.
The mechanics sit in the ACD queue model. A digital queue is a FIFO waiting list plus an eligibility filter; an agent's presence state gates dispatch (available and nothing else), and on top of the state gate a blended load score subtracts agents already saturated on open digital conversations — so routing can respect a concurrency capacity you set rather than dumping every new session on whoever is logged in. A worked example: 40 inbound chat sessions per hour, averaging 12 minutes of agent work each — that is 480 session-minutes of work per hour, or 8 agent-hours. At three concurrent sessions per agent, three staffed agents absorb it with headroom; at one concurrent session, the same load needs eight. The concurrency setting is the multiplier, and the queue's SLA clock is what tells you whether the current multiplier is honest.
Decision checklists
Bot-first versus human-first. Bot-first when inbound volume is high and repetitive, when a large share of intents resolve from your existing help content, or when you need coverage outside staffed hours. Human-first when the conversation is high-value or regulated (a sales negotiation, a financial or medical thread), when the customer segment expects a person by default, or when volume is low enough that a bot tier is overhead. The hybrid most teams land on is bot-first triage with a fast human escape hatch — the confidence threshold decides, the transcript travels, and the SLA clock treats the bot's answer as a response only if it actually resolved the thread.
Chat versus asynchronous channels. Live chat buys speed at the price of staffing a window. Asynchronous channels — WhatsApp, SMS, email — let the customer leave and return without either side holding a session open. Choose live chat when sessions resolve in one sitting and your staffing can hold a first-response promise during the hours the widget is on. Choose asynchronous-first when volume is sporadic, the team is small, or your customers are already on WhatsApp — and note that in an omnichannel model the choice is per-thread, not per-business: a conversation that starts in the widget can continue on WhatsApp when the visitor steps away.
Worked scenario: widget to bot to hand-off to WhatsApp
One visitor, three systems, one thread — using only the shipped surfaces named above.
- Widget and routing. A visitor opens the chat widget on your site and asks about a billing discrepancy. The inbound message lands in the inbox as a new conversation; a routing rule evaluating channel and a
billingkeyword assigns it to the billing team's queue — the flow from the inbox setup guide. - Bot triage. The workspace runs bot-first: the AI agent takes the thread, answers the standard part (where the invoice line item comes from), and recognizes the discrepancy itself needs a human.
- Hand-off with the transcript attached. The conversation routes to a billing agent. The agent opens the thread and reads the bot's full exchange — no re-asking, no session restart — because the transcript lives on the conversation object described in the conversations concept.
- SLA clocks run throughout. The first-response clock started on the visitor's first message and stops on the first reply that resolves it; the resolution clock keeps running until the thread closes, per the SLA timers guide. A breach would page the team, not just age a badge.
- The visitor leaves the browser. They ask to continue on WhatsApp. The agent uses Continue on another channel — or the integration calls
resume-channel— and the same conversation, full transcript and all, continues on WhatsApp, per the cross-channel guide. For the visitor it reads as one conversation. On the platform it literally is one.
When live chat is the wrong channel
Live chat adds staffing obligations. If volume is sporadic or your team is small, a bot-first flow with asynchronous channels such as WhatsApp or email may answer better than an empty chat window. The decision question is not whether to offer chat, but how the hand-off between automation and humans is designed — an unstaffed widget is worse than no widget, because it writes a promise the queue cannot keep.
Frequently asked questions
What is the difference between live chat and a chatbot?
A chatbot is automation that answers; live chat is the staffed session a human answers. The two compose: the bot handles the intents it can resolve, and escalates to a live agent with the transcript attached so the human starts where the bot stopped. A deployment that runs only a bot has automation, not live chat.
Is live chat the same thing as web messaging?
Not quite. Web messaging is asynchronous — the visitor can close the tab and the conversation resumes later, email-style. Live chat connotes a staffed, real-time session. Orbit's conversations model holds both as one thread with a channel label, which is why a session can start live and continue asynchronously without splitting into two tickets.
How many chats can one agent handle at once?
Typical operations run two to four concurrent sessions per agent, and the honest ceiling depends on how much each conversation actually asks of the agent. The ACD queue model enforces it mechanically: presence gates who is dispatchable at all, and the blended load score pulls saturated agents out of rotation. Track first-response time against your SLA policy — when the clock degrades, the ratio is set too high or staffing is too thin.
What should travel with the conversation on hand-off?
The full message history, the customer's identity and record, and any AI-agent session state — which on Orbit is exactly what attaches to the conversation object. A hand-off that loses the transcript is a transfer of inconvenience: the customer repeats everything, and the agent starts blind.
When a visitor leaves the browser, is the chat over?
No. The thread can continue on WhatsApp, SMS, or email through cross-channel continuation — the conversation id, transcript, and agent context stay put; only the default reply channel changes. The widget session ending ends the channel, not the conversation.
Does live chat replace email and phone support?
It absorbs the slice of contacts that resolve in one real-time sitting — quick questions, triage, first-line troubleshooting. Email still fits long-form, attachment-heavy threads; voice still fits urgent, complex, or regulated calls. An omnichannel inbox treats live chat as one channel among them rather than a replacement, so the channels split by customer preference instead of by where your history got trapped.
Where it fits in Devotel Orbit
Devotel Orbit treats live chat as one channel in an omnichannel inbox rather than a standalone widget. Agents work web chat, WhatsApp, SMS, and email from the same queue, and bot hand-offs carry the full transcript. The docs pages linked above — conversations, inbox setup, SLA timers, cross-channel continuation, and the ACD queue model — carry the setup detail, and /blog/omnichannel-shared-inbox-entry-level-ccaas describes the shared-inbox model they plug into.