Almost every live chat deployment starts the same way: a launcher sits in the corner of every page, and anyone who wants help clicks it. That is the right default, and most sites should stop there. But there is a second way to deploy the same account, and it is easy to miss because it removes the one part of live chat everybody pictures. Monitor mode loads the widget with no launcher at all.
What survives is everything the visitor never sees. The session is still tracked, so agents watching the live visitor list see the same referrer, country, current page and browsing path they would see on a normal deployment. Invitation rules still evaluate, so an agent or a rule can still open a conversation with somebody. The only thing that has changed is that the visitor is not being offered a button.
The product describes this as silent monitoring, and the phrase is accurate in both directions. It is silent from the visitor's point of view, and it is silent about demand too: nobody can raise their hand on a page where there is nothing to click.
What the monitor snippet actually changes
The difference is one word in the script tag. A standard install points at chatbutton.aspx; the monitor snippet, which the dashboard generates for you on the Monitor-Only Mode page, points at chatapi.aspx instead. Both carry the same account id, both load asynchronously, and both sit at the bottom of the page before the closing body tag.
That endpoint hands the browser the same runtime, but tells it which mode it is running in. The runtime only draws a launcher for the modes that are supposed to have one, and the monitor mode is not among them. It is worth being precise about this because it explains what does and does not break: nothing is disabled, nothing is switched off on the server, and no setting in your account has changed. One rendering step is skipped.
The practical consequence is that switching between the two is a snippet edit on your side, not a support request or a migration. You can run monitor mode on your marketing pages and the ordinary snippet on your help pages, because the choice is made per page by whichever tag that page carries.
Nobody can open a chat unless you give them a way
This is the part that catches teams out, and it deserves stating bluntly. With no launcher on the page, a visitor has exactly two routes into a conversation. They can accept an invitation that you sent them, or they can click something you built yourself that opens the chat window. There is no third route, and there is no hidden gesture that experienced users know about.
Building your own opener is deliberately simple. The runtime exposes a global function, MyLiveChat_OpenDialog(), and any element on your page can call it: a link in your navigation, a button at the end of a pricing table, an item in a footer menu. The dashboard ships worked examples of exactly this under its developer demos, because the same function is what the text-link deployment uses. If you take nothing else from this guide, take this: decide what your opener is before you deploy monitor mode, not after.
The failure mode when you skip that step is quiet rather than loud. The page looks correct, the visitor list fills up, agents see traffic, and no chats arrive. Everything is working as designed and the design has no door in it.
When monitor mode is the right call
There are a handful of situations where hiding the launcher is genuinely the better decision.
- Invitation-only engagement. If your model is that agents reach out to visitors who look like they need help, rather than waiting to be asked, the launcher is doing nothing except taking up a corner. The invitation rules are the front door instead.
- Pages that must stay visually quiet. A campaign landing page, a checkout step, a page already carrying a cookie banner and a promotional bar. Adding a third floating element is a real cost, and on small screens it is a bigger one.
- Measuring demand before you staff. Monitor mode lets you see who is on the site, on which pages, at which hours, without promising anyone a reply you cannot yet give.
- Your own opener is better than ours. If you have designed a support panel or a help menu that already fits your site, calling the chat from inside it is cleaner than running two competing entry points side by side.
When it is the wrong call
The mirror image is just as clear, and the mistake usually comes from treating monitor mode as a tidier default rather than a specific tool.
Do not run it on pages where people arrive already needing help. Help centre articles, order status pages, troubleshooting content, anything reached from a receipt or a confirmation email: on those pages the visitor is looking for a way to talk to you, and hiding it converts a chat into a support email at best and an abandoned visit at worst.
Be equally careful with it as a bandwidth control. Teams sometimes reach for monitor mode because the queue is uncomfortable, which is understandable and almost always the wrong lever. Hiding the launcher does not reduce the number of people with a problem; it reduces the number you find out about. Shorter hours honestly advertised, or an offline form that promises a real reply time, leave you with a queue you can manage and a reputation you can keep.
Finally, do not use it as a soft launch that never ends. A quiet deployment that nobody revisits is indistinguishable from a broken one, and after a few months nobody on the team remembers which it was.
Rolling it out without surprises
A monitor-mode rollout is short, but each step exists because skipping it produces a specific confusion later.
- Pick the pages first. Write down which templates get the monitor snippet and which keep the ordinary one. A site that mixes both without a rule becomes impossible to reason about six months on.
- Build the opener before you deploy. One link, one clear label, somewhere a visitor would look for help. Test it on a phone as well as a desktop.
- Set the invitation rules that will carry the load. With no launcher, your invitations are not a bonus channel, they are the channel. Give them the attention you would give a launcher.
- Tell the agents. A visitor list with plenty of traffic and few chats reads as a broken widget to anybody who was not told the launcher is deliberately absent.
- Put a review date in the calendar. Two weeks is enough to see whether the quiet version is serving visitors or only serving the page design.
What to measure
The metric that matters is not chat volume in isolation, because monitor mode is supposed to reduce it. Compare conversations started per hundred sessions on the monitor pages against the same figure on pages that kept the launcher. That ratio tells you what the design decision actually cost.
Watch invitation accept rates closely too, since they are now doing the work the launcher used to do. If accepts fall, the effect on the monitor pages is immediate and total, in a way that would only be a minor dip on an ordinary deployment.
Then check the channels next door. A rise in support email or contact-form volume that starts in the same week you hid the launcher is not a coincidence, and it is the clearest evidence that the demand did not go away, it went somewhere with a slower reply.