A drop is a symptom, and the causes are not alike
Chat volume falling is one of the few support metrics that reliably triggers a same-day investigation, and it is also one of the most commonly misdiagnosed. The number went down, so something broke — except that a fall in conversations can mean the widget is missing from the site, or that fewer people visited, or that the same people visited and simply did not need to ask, or that nothing changed at all except the way the number is being counted.
Those four explanations call for completely different responses, and three of them are not emergencies. The mistake that wastes the most time is starting with the most alarming hypothesis, rebuilding the deployment, and discovering afterwards that a public holiday and a paused ad campaign account for the whole thing. Work in the order below instead: it is arranged so the cheapest checks eliminate the most expensive possibilities first.
First, prove the widget is actually on the page
This takes two minutes and rules out the worst case, so it goes first. Open your highest-traffic page in a private window on a device that is not yours, and look for the launcher. If it is there, open it and send yourself a message. A widget that renders but does not connect is a different fault from one that never renders, and you have just distinguished them.
If it is missing, view source and search for chatbutton.aspx. The install is a single script tag placed before the closing body tag, loaded with async and defer so it stays off the critical rendering path. The most common way it disappears is not a chat problem at all: a site redeploy, a theme update, or a template change ships a page that no longer carries the snippet. Nothing errors, nothing alerts, and the first symptom anyone notices is the conversation count a week later.
Check more than one page. Snippets are frequently installed per template rather than globally, so a redesign that rebuilt only the product template takes chat off the product pages and leaves it on the blog, which produces a partial drop that looks like seasonality.
If the snippet is present and the widget still is not, something is stopping it from loading. Open the browser console on the page and look for network or policy errors. Two causes account for most of these.
The first is Content Security Policy. The widget runtime loads from a MyLiveChat node host rather than from your own domain, so a CSP that does not allow it will block the script outright — and because styling is fetched too, a policy that permits scripts but not styles produces the confusing half-broken case where the widget mounts but looks wrong. The second is mixed content: an http snippet left on a page now served over https is refused by the browser, which is a classic leftover from a migration to TLS.
Both of these are worth ruling out early because they are invisible to you. They frequently affect only a subset of visitors — a stricter corporate network, one browser, one region — so the site looks perfect from the office while a slice of your audience has had no chat for weeks. If the drop is partial rather than total, this is the most likely branch, and it has a guide of its own.
Third, check whether the traffic changed rather than the chat
Only now is it worth looking at demand. Chat volume is roughly proportional to qualified traffic, so the honest first question is whether fewer people arrived. Compare the same window in your own web analytics, and compare like with like: the same days of the week, not a bank holiday week against a normal one.
Campaign changes are the usual culprit and the easiest to overlook, because the person who paused the campaign and the person watching the chat queue are rarely the same person. A paused paid campaign, a seasonal lull, an expired sponsorship, a search ranking change, or a competitor outbidding you all reduce chat volume without anything in the chat product changing at all. Visitor monitoring is useful here because it shows referrer and current page for the people who are on the site now, which tells you quickly whether the mix of arrivals has shifted rather than only the total.
If traffic held steady and chats fell, the conversion from visitor to conversation is what moved, and that is a genuinely interesting finding rather than a fault. It usually means something changed about how visible or how necessary chat is.
Fourth, check whether somebody changed a setting
Configuration changes are the quietest cause because they are intentional, made by somebody who had a good reason, and rarely announced. Several settings reduce chat volume by design.
- Operating hours. Narrowing them, or a timezone that is now wrong, takes the widget offline for hours you think you are covering.
- The offline path. Switching from a visible offline form to a hidden widget converts a countable message into no contact at all.
- Proactive invitations. If invitations were paused or their rules were retargeted, a share of conversations that used to be started by the invitation simply stops happening.
- Pre-chat form fields. Adding required fields to the form is one of the most reliable ways to reduce the number of conversations that start, and it is usually done in the name of lead quality.
- Widget placement or template. A launcher moved behind a cookie banner, or hidden under a sticky bar on mobile, is present in the source and invisible in practice.
Ask what changed in the two weeks before the drop, and ask people outside the support team. Marketing, web and design all routinely make changes that move this number.
Fifth, make sure the number itself did not change
The least dramatic explanation is that volume did not fall and the measurement moved. This happens more often than teams expect. A reporting window that shifted, a date range comparing 28 days against 31, a filter that now excludes a department, a duplicate snippet that was double-counting until somebody fixed it, or a definition change from conversations started to conversations answered will all produce a step change in a chart with no change in reality.
The tell is a clean vertical step rather than a slope. Real demand changes are usually gradual or tied to an identifiable event; instrumentation changes tend to happen between one day and the next and land on exactly the day someone deployed something. Your chat analytics and your web analytics counting different things is normal and not itself a problem, as long as you know which one you are looking at.
When the drop is real, and it is you
Sometimes every check passes and volume genuinely fell because the site got better. Rewriting a confusing pricing page, publishing the help article that answered the most repeated question, or shipping an AI assistant that resolves the routine tail all reduce human chat volume on purpose. That is a success, and it will look identical to a failure on a chart that only counts conversations.
This is why chat volume is a poor headline metric on its own. Pair it with something that reflects the outcome — resolved contacts, conversion rate on the pages chat covers, or the volume of the specific questions you set out to eliminate. If deflection was the goal, falling chat volume alongside steady sales is the result you wanted, and treating it as an incident wastes a week and possibly reverses a good change.
The one case that should worry you is volume falling while complaints, refunds or abandoned carts hold steady or rise. That combination means the questions are still being asked and are no longer reaching you.
What to measure
- Chats per thousand sessions, not raw chats, so a traffic change stops masquerading as a chat problem.
- Widget impressions against chats started, which separates a widget nobody saw from a widget nobody used.
- The shape of the drop — a vertical step points at a deploy or a setting, a slope points at demand.
- Coverage by page template, because a partial drop is usually a partial install.
- Offline messages and other contact channels, which rise when chat is unavailable and stay flat when demand genuinely fell.
- A dated change log for the site, the campaigns and the chat settings, which turns this entire investigation into one lookup next time.
If the drop is on a messaging channel rather than the widget, the counting rules are different again. How your channel message counts are counted covers the month boundary and the best-effort increment, both of which can move a number without any traffic changing.