An idle seat is worse than an empty one
When nobody is online, live chat can tell the truth. The widget can show an offline form, set an expectation about replies, and the visitor decides whether to wait. That is a fair transaction. The visitor knows what they are getting.
An idle seat breaks that. The agent is technically connected, so the widget advertises a staffed chat, the router hands them conversations, and the queue counts them as capacity. Nobody is reading. The visitor gets the worst version of every promise the widget just made, and they usually leave believing your company ignored them rather than that your team went to lunch.
This is a common failure at small scale, because small teams do not log out. They leave the console open in a tab all day and treat presence as a background state. The console has no way to know the difference between an agent thinking hard about a reply and an agent who is in a meeting two floors away, unless you tell it what inactivity means.
The four rules, and what each one really does
MyLiveChat's Idle Agent Policy is four independent rules. Each has its own on switch and its own timeout in minutes, and each is evaluated on its own, so you can enable one, all four, or any combination. If a rule is switched off, or its timeout is zero, that rule simply never fires.
- Mark the agent as away. After the timeout, the agent's status changes from online to away. This is the gentle one and the one most teams should start with.
- Lock the agent console. Also sets the agent to away, and posts a notice in the console saying activity will restore it. Read the next section before you rely on the word lock.
- Disconnect the session. Signs the console out of the chat server. The browser tab stays open and the agent is told they were signed out for inactivity, with the option to reconnect.
- Log the agent out. Disconnects, then offers to leave the page entirely. The agent can decline that prompt and stay where they are.
The rules stack in severity, and that is how to think about the timeouts: away at a few minutes, disconnect at a much longer interval, log out longer still. Setting them all to similar values just means four notices arrive at once and the agent learns to dismiss them.
A rule that has already fired will not immediately fire again, so a genuinely idle console does not fill up with repeated notices. The status change is what persists.
What counts as activity, and what does not
This is the part that surprises people, and it is worth telling your team explicitly. The console watches for mouse movement and key presses in the console itself. That is the whole definition.
Two consequences follow, and both of them cause complaints if nobody has explained them:
- Reading is not activity. An agent working through a long transcript, or reading a knowledge base article in a second window, is invisible to the timer. They can be fully engaged in the customer's problem and still be marked away.
- Activity elsewhere is not activity. Typing in your ticketing tool, your CRM or your email does not reset the console's timer, because those are different pages.
So the timer measures attention to the console, not attention to the customer. That is a reasonable proxy in a chat-first workflow and a poor one in a team that lives in another tool all day. If your agents spend most of a conversation in a CRM, set the away timeout generously or you will spend your week explaining the away badge.
It also means the policy cannot catch the case people most want it to catch: the agent who is present, moving their mouse, and simply not answering. That is a coaching conversation, and no timeout will have it for you.
This is a queue control, not a security control
Be precise about this one, because the wording invites a wrong conclusion. Despite its name, the lock rule does not lock the console in the sense you would expect from an operating system. It changes the agent's status and shows a message. Nothing is hidden, no password is asked for, and any activity restores the session. An open console on an unattended laptop is still an open console showing customer conversations.
The log out rule is similarly softer than it sounds. It disconnects the chat session and then asks whether to leave the page. Someone sitting at that machine can decline. Treat it as tidying up abandoned sessions, not as ejecting anyone.
The control that actually protects an unattended machine is the operating system lock screen, with a short timeout and a password to return. That belongs in your device policy, and it is covered properly in our guide on securing the agent workstation. Configure both: the idle policy so your queue tells the truth, and the OS lock so your customer data is not readable by whoever walks past.
Framed that way the feature is easy to reason about. The idle policy exists to keep your availability honest. It is not an access control and should never be recorded as one when somebody asks how you protect conversations.
Choosing timeouts that fit the way your team works
There is no correct number, but there is a method. Start from the promise your widget makes. If it says you reply in under a minute, an agent who has been untouched for fifteen minutes is not going to keep that promise, and the away status is doing the visitor a favour.
A pattern that works for most small teams:
- Away after 5 to 10 minutes. Long enough to survive a bathroom break or a long read, short enough that a lunch break registers.
- Disconnect after 45 to 60 minutes. This is for the tab somebody left open on Friday, not for a working agent.
- Log out rarely, and only if abandoned tabs are a real problem for you. On most accounts, disconnect is enough.
Two adjustments worth making. If your team runs several tools and only visits the console when pinged, lengthen the away timeout and lean on notifications instead, or you will train people to ignore an away badge that is usually wrong. If you run a single-agent shift, shorten it, because there is nobody else to absorb a conversation routed to an empty seat.
Announce the change before you make it. An agent who is marked away without warning assumes something is broken, and the first thing they do is tell a colleague chat is unreliable.
How MyLiveChat fits
Idle Agent Policy sits in the dashboard alongside the other availability settings, and it applies to the account rather than to one person, so the timeouts you choose are the timeouts everyone gets. The agent console is what enforces them, and the notices appear in the console itself where the agent can see why their status changed.
It works with, not instead of, the schedule. Operating hours decide when your widget offers a chat at all; the idle policy decides what happens to an agent who is signed in during those hours but not actually there. Teams that get this right usually set operating hours first, then add an away rule, then leave the harsher rules switched off until they see a real problem.
Worth knowing: an agent who is set to away is still signed in and can pick a conversation straight back up. Away is a routing signal, not a punishment, and it is reversible the moment they touch the keyboard.
What to measure
You are looking for evidence that the policy improved honesty without adding friction. Three things tell you that.
- Chats routed to an agent who never replied. This is the number the policy exists to reduce. If it does not move, either the timeouts are too long or your problem was never idleness.
- Complaints about the away badge. A steady trickle from the same people means the timeout is shorter than their real workflow, not that they are slacking.
- First response time on the chats that did get answered. Watch that it holds. If it rises after you enable the policy, you have quietly reduced your own capacity and should reconsider the timeouts.
Review it once, a fortnight after you switch it on, and then leave it alone. This is a setting that rewards being roughly right and forgotten, not tuned monthly.