Web chat is a conversation with a visitor who is on your website now. It arrives in the same inbox as everything else and behaves differently once opened.
Why it has its own treatment
Every other channel is asynchronous. An email answered in an hour is an email answered promptly.
A web chat answered in an hour is a visitor who left forty minutes ago.
That difference justifies a separate reader: visitor and agent turns clearly distinguished, messages arriving live rather than on refresh, and the visitor's session held open rather than treated as a mailbox thread. Underneath it is a different store entirely, keyed to the session, which is why the reading experience differs rather than only the styling.
The page context
Knowing where somebody is on your site changes the conversation.
A visitor on your pricing page asking "how does this work" is asking about commercial terms. The same words from somebody on a support article are asking something else entirely, and answering the wrong one wastes the only minute you have.
Read it before the first reply. It is the closest thing available to knowing why they are there.
Speed is the feature
This is the one thing that determines whether web chat is worth having at all.
Answer within a minute, or do not offer it. A chat widget nobody answers is worse than no widget, because it converts a visitor who might have emailed into one who feels ignored, and they were on your pricing page when it happened.
Say something immediately, even if the real answer takes longer. "Let me check that for you" holds somebody for two minutes; silence does not hold them for thirty seconds.
Do not offer it during hours nobody is watching. A widget available at midnight and unanswered is a promise your website is making on your behalf, and the visitor has no way of knowing the office is shut.
The visitor is anonymous until they are not
Most chats start with somebody you cannot identify.
Ask for a name and a way to reach them early, and naturally rather than as a form. A conversation ending with no way to follow up was worth very little regardless of how well it went, and asking at the end feels like a toll gate.
Once they identify themselves, the conversation attaches to the person like any other thread and their history becomes available. If they turn out to be an existing customer, that changes the conversation completely, and it is worth checking before you explain something they already own.
Keeping it useful
Short turns. A visitor watching a typing indicator for ninety seconds usually leaves. Two short messages beat one long one.
Answer the question, then offer the next step. Chat rewards directness in a way email does not; there is no room for a preamble in a small box.
Do not paste documentation. Link it and summarise the answer in one line. Somebody who wanted to read the page would have read the page.
When the conversation ends
Two endings, and they need different handling.
Resolved. Close it, and note anything worth keeping.
They left. Common, and not a failure. If you have a way to reach them, follow up by email; the conversation is already on their record, so the follow-up carries its own context and does not need explaining.
Handing over
Some chats need somebody else, and a handover in a live conversation is harder than in email because the visitor is watching the gap.
Say what is happening. "Let me bring in somebody who handles billing, one moment" costs a sentence and buys you two minutes of patience.
Do not hand over silently. A visitor watching nothing happen for ninety seconds assumes the conversation ended.
Write what you already know into a note before the handover, so the second person does not open with the question the visitor already answered. Asking somebody to repeat themselves is the fastest way to lose them.
If nobody is available to take it, say so honestly and offer to follow up by email. That is a better outcome than a conversation quietly dying.
Turning it into something
A chat that goes somewhere becomes a lead, a ticket or a booking.
It does not become a deal on its own. Nothing inbound does. A visitor asking about pricing is a lead until a person decides otherwise, and that rule is what keeps a pipeline meaningful rather than full of everybody who ever hovered over a price.
Volume, and what to do about it
Web chat produces a lot of very short conversations, and most of them are one question with a one-line answer.
That is a success, not noise. A question answered in forty seconds is a question that did not become an email, a ticket, or a decision to go elsewhere.
Watch for the same question repeating. Three visitors a week asking where your pricing is means the answer is a website change rather than a chat habit. The channel is telling you something about the page it is sitting on.
Do not staff it by adding people. Chat scales by being answered fast during hours you can actually cover, not by being available constantly with a longer queue.
Two habits
Watch the page, then the message. Two seconds of context changes the first reply, and the first reply decides how the whole conversation goes.
Move channel when chat stops suiting the conversation. Anything needing a document, a long explanation or a third person is better as an email or a call. Say so and move, rather than conducting something complicated through a small box while the visitor loses patience.
What is not here
Configuring the widget. Where it appears, its hours, its greeting and its intents are administrative and live in Operations.
Automatic answering. Whether an assistant replies first is configured rather than assumed, and it is covered in the AI section.
Visitor analytics. Who is on your site and what they are doing is a Web HQ question, not this surface.
Did this answer your question?
No, ask a person