Live chat

What is live chat?

Live chat is a real-time text conversation between a customer and a support agent, conducted inside a website widget, a mobile app, or an embedded messaging surface. The customer types a question, an agent or AI agent replies within seconds, and the exchange continues until the issue closes or escalates.

Live chat sits between self-service and voice. It carries the immediacy of a phone call with the written record of an email thread, which is why most support teams run it as their primary synchronous channel for anything short of an outage.

How live chat works

Live chat runs as a stack of five layers: a client widget, a routing layer, an agent workspace, a data layer, and a transcript store. The widget opens a persistent connection to the server, usually over WebSockets, so messages arrive without the page reloading. Everything interesting happens above that connection.

Routing decides who answers. Rules read the page URL, the customer's account tier, the stated contact reason, and current queue depth, then place the conversation with a human, a team, or an automated responder. Many teams now put a conversational AI layer in front of that queue so common questions resolve before routing runs at all.

The answer itself depends on retrieval. An automated responder needs AI grounding against help content and account records, and tool calling to look up an order or issue a credit rather than describing the process. Session state matters as much as the lookup: agent memory carries the details a customer already gave across turns, and across the gap when a chat resumes an hour later.

Behind the workspace, agent assist drafts replies and surfaces policy for the human handling the case. The transcript store closes the loop, feeding quality review, AI observability, and the next round of content fixes.

Types of live chat

• Human-staffed live chat: A queue of human agents answering concurrently, typically several conversations per person, with routing rules and availability hours governing coverage.

• Automated chat with human fallback: An AI agent handles the conversation first and transfers to a person on low confidence, sensitive intents, or explicit request.

• Proactive chat: The widget opens itself based on page, dwell time, or cart value, which lifts contact rate and can annoy customers who did not want help.

• In-app and authenticated chat: Chat inside a signed-in product session, where identity is already known, so the agent can act on the account without verification questions.

• Asynchronous messaging: The same widget, without a session timeout, so the thread persists for hours or days and neither side waits online.

Live chat vs chatbot vs messaging vs help center

Teams conflate these four constantly, and the confusion usually shows up as a channel strategy that buys the same capability twice. Live chat is a synchronous channel with an expectation that someone is present right now. A chatbot is a software responder that may sit inside that channel, so it describes who answers rather than the channel itself. Asynchronous messaging relaxes the presence expectation and lets the thread run for days. A help center removes the conversation entirely and asks the customer to find the answer. The useful framing is that live chat defines the surface and the latency contract, while everything else defines who or what is on the other end of it.

If customers are already on your site with a blocked task, live chat is the channel. If most of the volume is the same twenty questions, the decision is not the channel at all: it is whether an AI agent answers first inside it.

Why live chat matters for customer experience

Live chat catches customers at the moment of failure. Someone stuck at checkout or mid-onboarding will abandon within minutes, and a channel that responds in seconds converts that abandonment into a resolution. Email cannot do this, because the customer has already left.

Remove live chat and the volume does not disappear: it reappears as email tickets filed hours later with less context, as phone calls that cost more per contact, or as churn nobody logs. The absence shows up as a rise in first-contact-to-resolution time even though the ticket count looks flat.

The tradeoff is real. Chat's promise of immediacy creates an obligation to staff it, and a widget that shows a long wait or an unanswered message damages trust more than having no widget at all. Teams that open chat without capacity planning usually end up with worse satisfaction than before they launched it.

How is live chat measured?

No standards body or public benchmark defines a target for live chat performance, so any percentage quoted to you describes one company's installed base and its own definitions. The honest approach is to define your own baseline and measure movement against it.

Five measurements carry most of the signal: first response time, average resolution time, concurrency per agent, containment (the share of chats closed without a human), and post-chat satisfaction. Each needs a written definition before it means anything, especially resolution, which teams variously count at chat close, at ticket close, or at seven days without reopen.

For AI-handled chat, treat measurement as a governance obligation rather than a reporting habit. The NIST AI Risk Management Framework sets out measure and manage functions that map cleanly onto chat: define what accuracy means for your intents, test against known cases, and monitor for drift once traffic changes.

How AI agents change live chat

The mechanism change is retrieval plus action. Earlier chat automation matched an utterance to an intent and returned a scripted reply, so anything outside the script failed. An AI agent retrieves relevant policy and account data at inference time, reasons over it, then calls tools to perform the action, which is why agentic AI can complete a return in chat instead of explaining the return form.

Two consequences follow. Concurrency stops being the constraint on chat capacity, because an AI agent handles arbitrary simultaneous conversations and the bottleneck moves to the accuracy of what it retrieves. And the human role narrows to the cases automation could not close, which raises the average difficulty of every conversation a person sees. Planning for that shift is the point of a designed AI to human handoff instead of a confidence threshold nobody tuned.

What to look for in live chat software

Judge live chat on the axes that decide whether it holds up at volume, not on widget styling.

Coverage comes first: which surfaces the widget supports, whether authenticated sessions pass identity through, and how the same conversation continues on email or SMS. Integration surface decides what an agent can actually do, so check for read and write access to your CRM, order system, and billing provider rather than read-only lookups. Governance covers routing ownership, transcript retention, redaction of card and health data, and who can change an automated response in production.

Security certifications are the gate for regulated teams: expect SOC 2 Type II and ISO 27001 as a baseline, ISO 42001 where AI governance is scrutinized, HIPAA with a BAA for health data, and GDPR handling for EU customers. The operational constraint most teams miss is staffing math. Published hours, expected concurrency, and holiday coverage have to be settled before launch, because chat exposes understaffing within a day.

Live chat and omnichannel support

Live chat rarely stays a single channel for long. A customer who starts in chat often replies later by email, so the thread has to carry forward, and teams running chat, email, and help center in one workspace avoid the duplicate tickets that come from treating each surface as its own inbox.

The same continuity problem appears when an intelligent virtual agent spans voice and chat, since a caller who abandons the phone queue and opens the widget should not start over. Once several automated responders share a customer, orchestration decides which one owns the conversation and what context passes between them.

What does live chat mean in plain terms?

Think of live chat as the help desk inside the store, positioned where customers get stuck instead of somewhere they have to walk to. The customer never leaves the page, never composes an email, and never waits for a reply that arrives after they have given up.

Take it away and a blocked checkout becomes a lost sale plus a support ticket filed the following morning, when the cart is gone and the customer's patience with it. The customer's problem was solvable in ninety seconds; the channel is what made those ninety seconds available.

The named tradeoff is staffing. Live chat sets an expectation of immediate presence, and that expectation is easy to advertise and expensive to honor. Open the channel only during hours you can actually cover, or hand the uncovered hours to an AI agent that resolves what it can and captures the rest as a ticket.

Common live chat mistakes

Four patterns cause most live chat failures, and none of them are widget configuration.

Launching without capacity planning is the first. Teams enable chat everywhere on day one, discover queue depth exceeds staffing by mid-afternoon, and respond by hiding the widget on high-traffic pages, which is the opposite of the intended coverage.

Optimizing for containment is the second. When the target is the share of chats that avoid a human, the system learns to stall, loop, and refuse escalation, and customers respond by filing a second ticket. The mechanism is a metric that rewards not transferring rather than resolving.

Treating automation as a deployment is the third. An AI agent in chat drifts as products, policies, and traffic mix change, so it needs testing against known cases on a schedule and evaluations that catch regressions before customers do.

The fourth is the blind handoff. Transferring a chat without the transcript, the account context, or a stated reason forces the customer to repeat everything, which is why a designed human fallback path beats a raw transfer button.