Live chat is a queue with a person on the other end. Whether it works for your business depends on four operational decisions, not on the feature list of the widget: when the chat is open and what it says when it is closed, how fast the first reply has to arrive and how you measure it, what your saved replies are for and when they make a conversation worse, and when to move a chat to email instead of carrying on.
The arithmetic below shows what happens when the questions that never needed a person are answered automatically, and what that frees your team to do.
Most guides to live chat open with a screenshot of a chat bubble and a list of features. That is not what determines whether the channel works for your business. A live chat window is a queue with a person on the end, and the queue is what you are deciding about, not the window.
This article is for a small team that has decided to add live chat, or that has one and watches it go cold, and wants to understand what actually changes the outcome. The substance is the four decisions that decide whether live chat is a help or a cost centre, the measurements a reader can take on their own site today, and the arithmetic on what happens when the questions that never needed a person are answered without one.
What live chat actually is on your server
A live chat widget on a site is, mechanically, a small JavaScript client that opens a persistent WebSocket to a queue, plus a back-end where messages from visitors land in the order they arrived. An agent opens a console, claims the next message, types a reply, and the visitor sees it inside the widget. If nobody claims it within a timeout the visitor either waits, leaves, or sees an offline form.
That is the whole thing. The branding around the bubble, the typing indicator, the proactive trigger, the chatbot that sits in front of it, all of those are optional layers over a queue.
The reason this matters is that most "live chat strategy" articles talk as if the visitor side is the interesting part. It is not. The interesting part is the queue length, the wait, the abandonment rate, and what your team does when the queue length goes above what one shift can answer. Those are operational numbers, and they are the same whether you run the chat in-house or hand the queue to a vendor.
Decision one: when the widget is open and what it says when it is not
The first decision is also the one most teams fumble. They install the widget, leave it on all the time, and then ignore it outside office hours. The visitor types a message, sees nothing happen, and either sends it anyway (creating an email reply in the morning) or leaves.
A live chat widget that ignores people is worse than no widget. It tells the visitor that the company is not serious about the channel. The honest answer is to show an offline state when there is nobody on the queue, and to say clearly what will happen next.
Two configurations to choose between, both of which work:
- Hide the bubble when offline. No chat available, no prompt to start one. Visitors use email or a contact form. The widget only appears when there is somebody to reply.
- Show the bubble but make the offline state honest. The bubble says "leave a message and we will reply by email". The widget collects the visitor's email, the question, and a rough description of what they wanted. The team replies by email the next morning.
The first option is cleaner. The second option captures intent that would otherwise walk away. The choice depends on how much traffic you get outside hours and whether your team can reply by email the next morning without it piling up.
For most small businesses the right answer is the second option with a small twist: the offline message says when you will reply, not just that you will. "We reply by 10am the next business day" is more useful than "we will get back to you". A visitor who knows when to expect an answer is a visitor who does not send a second message wondering whether the first one arrived.
Decision two: how fast the first reply has to be
The single number that decides whether a visitor thinks live chat is good is the time from their first message to your first reply. There is no reliable published figure for what a visitor will tolerate, and you do not need one, because the number you can act on is your own.
You do not need a survey. You can measure this on your own site today. Open your chat console as a visitor. Send a message. Time how long until a reply appears. Do this at four times of day. That is your actual first reply time, and it is the number your visitors experience.
If your first reply time is over two minutes, the cause is almost always one of three things, and each has a different fix.
The first cause is that nobody is on the queue. The widget is on, but the team is not watching it. The fix is to make chat part of somebody's job for the hours it is open, not an extra thing on top of email and phone. A second person on a second screen watching chat works better than a single person juggling chat with three other tasks.
The second cause is that the visitor's question is complicated and the agent has to look something up. The fix is to scope what chat is for. If chat is for "where is my order", "how do I reset my password" and "what are your opening hours", those have written replies in a help center. Pointing the visitor at the article takes twenty seconds and is faster than typing the answer.
The third cause is that the visitor is asking something that should never have come to a person. A share of live chat traffic on any site is answerable from the website already, and the chat widget surfaces it because the visitor could not find the answer themselves. Count that share on your own transcripts; it is usually larger than the team expects. That is the most interesting cause, and it is the one an automated chat agent is built to absorb.
Decision three: what saved replies are for and when they make things worse
A saved reply is a short canned message that an agent pastes into the chat, usually bound to a slash command. "Hi, I am Sarah from support, how can I help today" is a saved reply. So is "I have looked up your order, it is being dispatched today, your tracking link is below". The point of saved replies is to keep the agent typing speed high without sacrificing accuracy on the parts that vary.
The mistake most teams make with saved replies is using them as a substitute for thinking about the conversation. A visitor describes a problem. The agent pastes a saved reply that does not quite fit. The visitor types a follow-up. The agent pastes another saved reply. The visitor is now talking to a wall, and they know it.
Saved replies are for the parts of the chat that are the same every time. They are not for the parts that require reading what the visitor wrote. The rule of thumb is that a saved reply should never close a conversation. It should open one, or carry information across one. Closing the conversation is the part that needs the human reading the words on the screen.
The other mistake is letting saved replies grow without anyone reading them. After two years a team's saved-reply library has three hundred entries, half of them out of date, a third of them contradicting each other. An agent picks the wrong one in a hurry. The visitor gets a link to a discontinued product. Audit the saved replies twice a year, the same way you audit your help center.
Decision four: when to move the conversation to email
Some conversations do not belong in chat. A billing dispute that needs an attached invoice. A technical problem that needs a screen recording. A complaint that needs a written response a manager can review. Carrying on in chat when the conversation has moved to one of those is a slow way to make the visitor angry.
The signal is simple: when the next message would attach a file, quote a policy, or take more than three short paragraphs to write, move it to email. The agent sends a short chat message that says "I am going to follow up by email so I can attach the form", the email goes out within the hour, and the chat is closed.
This is not a failure of live chat. It is the right outcome. Live chat is for the short, fast, answerable questions. Email is for the slow, careful, document-heavy ones. A team that tries to keep every conversation in chat ends up with chat sessions that run for an hour and please nobody.
The questions that never needed a person
Here is the interesting arithmetic for a small business. Most live chat traffic is a small number of questions repeated many times, and a large share of them already have a published answer: opening times, return policy, shipping cost, how to reset a password, where to find an invoice. The visitor does not know the answer is published. They see the chat bubble, they ask.
An automated chat agent answers those without a person. The person on the queue sees only the conversations that actually need one. The first reply time for the person-bound queue drops. The visitor who asked a published question gets the answer in seconds instead of waiting two minutes. The person on the team gets to spend their hour on the conversations that need them.
Published prices for Asyntai, which is one option for the automated layer:
| Plan | Monthly price | Messages per month | Cost per 1,000 messages | Cost per message |
|---|---|---|---|---|
| Free Plan | $0 | 100 | $0.00 | $0.000 |
| Starter Plan | $39 | 2,500 | $15.60 | $0.0156 |
| Standard Plan | $139 | 15,000 | $9.27 | $0.00927 |
| Pro Plan | $449 | 50,000 | $8.98 | $0.00898 |
The cost per 1,000 messages and the cost per message are calculated from the monthly price divided by the message allowance. The published price per message drops as you move up the plans, from about a cent and a half on Starter to under a cent on Pro.
The arithmetic that matters for your decision is the per-message cost on the plan you would actually buy. A visitor asking "what time do you close" sends one message and gets one reply, so a conversation uses a small number of messages. Suppose your site currently gets 2,000 deflectable conversations a month. Assume each one averages 3 messages from the visitor and 3 from the agent, so 6 messages per conversation:
Twelve thousand messages a month is above the Starter allowance of 2,500 and below the Standard allowance of 15,000. The Standard plan is the one whose message allowance fits, not the one with the lowest per-message number.
If your deflectable volume is closer to 5,000 conversations a month, the messages per conversation push you towards Pro. At 6 messages per conversation:
These are the reader's own volumes and the reader's own assumed messages per conversation, not market figures. The point of putting the maths in front of you is that the right plan is the one whose message allowance is closest to your total messages, not the one with the lowest number per message. Multiply conversations by messages per conversation first, then pick the plan whose allowance covers the total.
What to measure in the first week
Most guides tell you to track customer satisfaction scores and net promoter scores. Those are useful after you have been running chat for six months. In the first week, measure four things on your own desk.
First reply time. Send yourself a chat message at four times of day. Time the reply. If the reply takes more than two minutes during business hours, the queue is understaffed or the team is not watching it.
Abandonment rate. Open the chat console report. Count the conversations where the visitor sent a message and never got a reply, divided by the total conversations. Set your own target, then measure against it each week; the direction of travel matters more than the starting number.
Chat-to-email ratio. Count the conversations that ended with an email follow-up. A high ratio (above a third) usually means the team is taking chats that should have been emails, and the visitor is paying for the slowness in frustration.
Saved reply usage. Open the agent's chat log. Count how many messages in a typical conversation are pasted from a saved reply versus typed. A high ratio of pasted to typed is fine if the saved replies are accurate. A high ratio of pasted to typed where the visitor's follow-up shows they did not understand is a sign the saved replies need auditing.
None of these need a vendor dashboard. All of them can be taken on your own site in the first week, and the numbers you get are the ones that decide whether the channel is working.
The mistake most people make
The mistake most people make is installing a chat widget and treating it as finished. The widget is the queue's front door. The queue is the work. A chat widget without a person on the other end is a paper sign that says "ring the bell for service" with nobody in the building.
The second mistake is treating every conversation as needing a person, when a large share of the conversations already have a published answer. Putting those through a person slows the visitor who asked and burns the time of the person answering. The right shape is that the published-answer questions are answered before they reach the queue, the person-bound questions reach a person within ninety seconds, and the document-heavy questions move to email.
The third mistake is letting the chat widget stay open outside hours. A visitor who types a message at 11pm and gets a reply at 9am the next day has had a worse experience than a visitor who saw "leave a message, we reply by 9am" at 11pm. The offline state has to be honest, and the reply promise has to be kept.
Putting it together
Live chat is a queue with a person on the end, and the four decisions that decide whether it works are operational, not technical. When the widget is open and what it says when it is not. How fast the first reply has to be and how you measure it. What your saved replies are for and when they make things worse. When to move the conversation to email.
The arithmetic on the automated layer matters because the alternative is putting those conversations through a person. Multiply your deflectable conversations by the messages each one uses, then pick the plan whose message allowance covers the total. The published price per message on the Standard plan sits around nine thousandths of a dollar, and that is the cost of absorbing the questions that never needed a person, which is the cost of keeping your team's queue clear for the conversations that do.
The measurements in the first week tell you whether the channel is working. First reply time. Abandonment rate. Chat-to-email ratio. Saved reply usage. Take them on your own site before you decide whether the channel is paying back the time it costs your team.
If the volume you want to deflect fits within the message allowance on the Starter plan, Asyntai handles the published-answer questions before they reach your team. You write the answers once. The chat agent answers the visitor. Your team sees only the conversations that need a person.
Sources and dates: Asyntai published pricing and message allowances from the Asyntai pricing page, checked September 2026. Per-message costs in the price table and per-conversation costs in the maths blocks are calculated from the published monthly price divided by the published message allowance. Deflectable conversation volumes and messages per conversation are the reader's own assumed inputs, not measured market figures.