The chat ends. What happened in it does not.

Less than you might expect, and that is the honest answer. It knows an identifier the widget generated, which is used to reconnect the same person to the same conversation and for nothing else. It knows which workspace the chat belongs to, and that one it works out itself from the widget key — a workspace id sent by the browser is ignored, which is what stops one site embedding another company’s widget key and reading their chats. It knows the connection address and where the chat was opened. Anything else — a name, an email, a company — is there only because the visitor typed it or a flow collected it, and it is shown to the agent as something claimed rather than something proven.

By proving it, and only by proving it. If the conversation asks for an email address, a single-use code is mailed to it and has to come back within ten minutes; codes are stored hashed, attempts are limited, and the reply never reveals whether an address is on file. When it succeeds, the verified address and the CRM contact behind it are written onto the conversation itself and re-read from the database on every later turn, so nothing the browser sends can promote itself into an identity. That verification is performed by the chatbot flow rather than by the live chat handler — but because it is the same conversation, an agent picking the chat up afterwards inherits it instead of starting again.

A score, computed at the moment the chat needs an owner. If the chat names a department, that queue is tried first and the general queue second. An agent with no open connection, an agent who is not online, and an agent already at their concurrent limit are removed before scoring rather than ranked below it. What is left starts at a hundred points, loses twenty for each conversation already open, gains ten for having been active in the last five minutes, and gains thirty for being free when the chat is high or urgent. The highest score takes it. If nobody qualifies, the visitor is queued with a position and an estimated wait, and the alert that goes out is a durable notification as well as a broadcast — because a broadcast only reaches the agents who are already connected, which is precisely the wrong assumption to make when the problem is that nobody is.

Two different things get called that, so it is worth separating them. Per agent, yes and it is enforced: an agent at their concurrent limit — three by default — is skipped by the router entirely, which is why a busy team queues rather than quietly overloads one person. Per workspace, your plan records an allowance, and you can see it in the table above, but the widget does not currently turn a visitor away when you are over it. We would rather write that down than let a number in a pricing table imply a refusal that does not happen.

No, and this is the sentence most worth reading twice. Turning a conversation into a ticket is an action an authenticated agent takes: the ticket is seeded from the conversation, stamped with the conversation it came from, and from that point it is a real ticket with an SLA deadline and the created-automations run against it. Escalating is a different action with a different button — it raises the conversation’s status and notifies people, and it creates nothing. Marketing copy in this category loves the word "automatically". Here a person decides, every time.

It stays, whole. Every message keeps its sender, its timestamp and whether it was an internal note, and the lifecycle is inside the thread rather than beside it: the agent joining, a transfer naming both people, an escalation, and the close naming who closed it are all messages you can read in order. A closed conversation refuses new messages rather than silently accepting them, so the transcript is a record of what happened and not a document that keeps changing. If the visitor verified themselves, the contact link stays too, which is what makes it read as that customer’s history later rather than as an anonymous session.

One. An agent can ask for a suggested reply, and the model is given the last ten messages of the thread and returns a draft into the composer. It is metered against your workspace’s AI credits, and if you are out of credits you are told so rather than handed a silent failure. It cannot send, and nothing sends on its own. Be aware of one boundary: those ten messages are the last ten in the thread, internal notes included, so treat a note in an active chat as something a draft may have read. Everything else here is ordinary software — the routing score is arithmetic, the queue is a list, and the unread badge is a count.