The failures are boringly consistent
When a team concludes that live chat did not work for them, the cause is almost never the software. It is a small set of setup decisions, made quickly at install time and never revisited, and the same ones recur across wildly different businesses. That is genuinely good news: it means the problems are cheap to fix, and it means you can avoid most of them by reading a list rather than by learning from experience.
Leaving it on when nobody is there
This is the most common and the most damaging. The widget is installed on a Tuesday afternoon, everyone is watching, and the first conversations go well. Then evening comes, then the weekend, and the widget is still there inviting people to chat with a team that has gone home. Visitors who type into it get nothing, and they learn something about your company that no amount of later diligence undoes.
Set business hours to what you can genuinely staff, and decide deliberately what happens outside them — an offline form with an honest response time, a pointer to your help content, or hiding the widget entirely. All three work. The one that does not work is an inviting chat box behind which nobody is sitting.
Nobody actually gets notified
A chat arrives and no one knows. The console was open in a background tab, sound was muted, the desktop app was never installed, or the agent was in another tool entirely. From the visitor’s side this is identical to being ignored, and from the team’s side it is invisible — they find the missed conversation later and are genuinely surprised.
Notification setup deserves five minutes of deliberate testing during install, not an assumption. Have someone start a chat from a phone on mobile data while the intended agent goes about a normal working hour, and see whether they actually notice. That single test catches this whole class of problem before real visitors do.
Everything is set to the defaults
Default greetings are written by software companies to be inoffensive in every context, which makes them generic in yours. Visitors read them as automated even when a person is genuinely waiting, and a message that reads as automated gets less engagement and worse information. The same applies to the offline message, the busy message and the widget colours — a widget that looks nothing like the site around it reads as a third-party advert rather than as your support.
Rewriting the handful of visible strings in your own voice takes twenty minutes and measurably changes how people respond. It is the highest return per minute of any configuration work.
Every field between a visitor and their question loses some of them, and the losses are steepest for the people who are least committed — which is to say, often the new prospects you most wanted to reach. Teams add fields because the data seems useful, then never actually use most of it. Phone number, company, and a dropdown of enquiry types that nobody reads are the usual suspects.
Ask only for what you will genuinely act on. For many teams that is a first name and possibly an email address for follow-up, and nothing else. If a field exists because someone thought it might be handy someday, it is costing you conversations today.
It is installed everywhere, on purpose or otherwise
Chat on every page sounds thorough and often is not. The pages where a stuck visitor is most valuable — pricing, checkout, key product and support pages — benefit enormously. A blog archive from 2019 mostly generates interruptions that dilute your team’s attention. Site-wide is a legitimate choice, but it should be a choice, and it should be reviewed once you can see where conversations actually come from.
The other half is placement. Widgets that cover a sticky checkout bar, a cookie banner or a mobile navigation control cost money in ways that never show up as an error, which is why they survive for months.
Nobody looked at it on a phone
Mobile is where widget problems concentrate and it is routinely tested last or not at all, because the person setting it up is on a desktop with two monitors. The classic failures are all mobile-specific: the launcher sitting on top of the checkout button, the on-screen keyboard hiding the send control, a panel that fills the screen with no obvious way to close it.
Ten minutes on a real phone, going through a real path to purchase or a real support question, catches nearly all of it. Use an actual device rather than a desktop browser pretending to be one.
Routing was never decided, or was decided too elaborately
With one person answering, routing is a non-issue and any effort spent on it is wasted. With several, two opposite mistakes appear. The first is no routing at all, so everything lands in one pool and either everyone answers or nobody does. The second is an elaborate department structure built on day one, which means visitors must classify their own problem correctly before they can ask it — and they frequently cannot, so questions arrive in the wrong queue and get transferred.
Start simple and let the real distribution of conversations tell you what structure you need. Every routing rule you add is a rule someone has to maintain and a way for a conversation to end up unowned.
Only the person who set it up ever tested it
The installer is the worst possible tester: they know where everything is, they are logged in, and they are on the network and device where it was built. Real testing means a different device, a different network, and ideally a different person who was not told how it works. That is where you discover that the widget does not appear behind your consent banner, or that the offline form sends to an inbox nobody monitors.
The same blind spot applies to account-level changes made in a hurry to fix something. Switching the chat interface itself — for instance rolling the embedded chat back to the Classic UI — affects every visitor on every page at once, so it deserves the same different-device, different-person check afterwards rather than a glance at your own screen.
How MyLiveChat fits
Every item above is a MyLiveChat setting rather than a limitation: business hours and offline behaviour, notification and sound options, the greeting and pre-chat form, widget appearance and placement, which pages carry the code, and departments when you need them. The free plan covers one agent with unlimited chats, so the sensible pattern is to configure these deliberately, launch on a few pages, and widen once a week of real conversations has shown you which of your assumptions were wrong.
One more mistake worth naming: stripping attributes from the install snippet during a tidy-up. Loading the chat script without slowing your page covers which ones are load-bearing and why removing them fails intermittently.
One more that is hard to spot: an integration that pre-fills visitor details and quietly does nothing. The page-code route into the widget will not overwrite a function your own page defined first, so the calls succeed and the values never arrive.
One setup decision that is easy to make by accident is which client your agents actually sit in. MyLiveChat ships four, and which agent console your team should use covers what each one is for and why the choice is reversible.
One more worth heading off in the first week: assuming an account email that has never been tested will work when it matters. How long the links in your account emails last covers the lifetimes and resend limits on the verification and recovery mail you will eventually need.