An agent who is signed in but not at their desk is a more expensive problem than one who is simply signed out. Routing still counts them as available, so chats go to a seat nobody is sitting in, and the visitor waits out the whole queue before anyone notices.
MyLiveChat handles this with an idle policy that runs inside the agent console. It is worth understanding properly, because the way it decides somebody has stepped away is narrower than most people assume, and one of the four settings does not do what its name suggests.
Four policies, one clock
There are four separate policies, and each one has its own on/off switch and its own timeout in minutes. In order of severity they set the agent to away, lock the console, sign the agent out of chat, and prompt them to leave the page entirely.
The important detail is that all four read the same inactivity clock. They are not a ladder, and nothing escalates from one to the next. The policy that fires first is simply the one with the smallest timeout.
That means the ordering is something you create by choosing numbers, not something the system guarantees. Set sign-out to five minutes and away to fifteen, and your agents will be signed out of chat without ever having been marked away. If you want the gentle step to come first, its timeout has to be the smaller one.
A policy whose switch is off does nothing. So does a policy that is switched on but left with a blank or zero timeout, which is the quiet failure worth knowing about: enabling a policy and not filling in the minutes leaves it just as inert as never having touched it.
The console re-checks every couple of seconds, and a policy that has just fired will not fire again for another forty-five seconds. That short suppression window is what stops a single idle stretch from posting the same notice over and over.
What actually counts as activity
Activity means mouse movement or a key press, in the console tab. That is the entire list.
Read that again, because the consequences are not obvious. Reading a long transcript without touching anything counts as idle. Working in another application counts as idle. Being on a phone call with the customer you are also chatting with counts as idle. And an incoming chat message does not reset the clock either, because a message arriving is not something the agent did.
This is the part most worth telling your team, since the natural assumption is that being busy in the console is enough. It is not. Only the mouse and the keyboard speak.
The practical consequence is that timeouts have to be generous enough to survive an ordinary reading pause. A three minute away timeout will fire on an agent who is carefully reading a long complaint before replying, which is exactly the agent you least want to interrupt.
Browsers add their own wrinkle. A background tab gets its timers throttled, so a console left behind another window may check far less often than every two seconds. The console notices this and posts a warning of its own when the tab appears to have been inactive for more than about ninety seconds.
Away and lock do almost the same thing
Both the away policy and the lock policy set the agent status to away. That is the whole of what either one does.
The lock policy does not require a password. It does not blank the screen, hide the transcript, or ask anybody to identify themselves before carrying on. The message it posts says the console has been locked and that activity will restore it, and activity does restore it, because the only thing that changed was a status.
The one real difference is which status each policy is willing to act from. The away policy only acts on an agent who is currently online. The lock policy also acts on one who is already away. So in practice lock behaves as a second, later reminder for somebody who has been gone a long time, rather than as a stronger form of protection.
If what you actually want is a locked screen, that is the operating system, not the chat console. Set a short screen lock on the machine and treat the chat policy as a routing courtesy rather than a barrier.
Signing out and leaving the page
The third policy disconnects the agent from chat. New conversations stop being routed to them, and the console posts a message explaining what happened and offering to reconnect.
The fourth builds directly on the third: it disconnects in exactly the same way, then about a second later asks the agent whether they want to leave the console page. Agreeing navigates the browser away. Declining keeps them on the page, but they are still disconnected, because the disconnect already happened before the question was asked.
Because the two overlap, enabling both with the same timeout produces one disconnect followed by a prompt. That is a reasonable setup for a shared machine, where you want the seat genuinely vacated. It is a poor one for a dedicated support desk, where an agent who steps away for coffee returns to a browser that has left the console.
Choosing timeouts that fit your team
Start from what the status actually means downstream. Away takes the agent out of the pool that new chats are offered to, so an away timeout that is too short quietly shrinks your staffing during the busiest part of the day.
A shape that works for most dedicated support teams is a modest away timeout of ten to fifteen minutes, a much longer sign-out at forty-five minutes or an hour, and the leave-the-page policy switched off. The away setting handles the ordinary case of somebody stepping out; the sign-out handles the agent who went home without signing out.
Shared machines invert that. A console on a reception desk or a shop floor is used by whoever is standing there, and leaving it signed in as the previous person is the real risk. Short timeouts on all four, including leave-the-page, are appropriate.
Whatever you pick, avoid an away timeout under about five minutes. Below that you get flapping, where agents bounce between online and away all afternoon, and the status stops carrying any information for the people watching it.
Write the numbers down somewhere the team can see them. Almost every complaint about this feature turns out to be an agent who did not know the policy existed and assumed something was broken.
This is not a security control
The whole mechanism runs in the browser, inside the console page. If the tab is closed, or the machine sleeps, or the timers are throttled hard enough, none of it runs.
Treat it as hygiene rather than enforcement. It keeps your routing honest and stops a forgotten session from swallowing chats, and those are genuinely worth having. It does not protect an unattended screen from somebody walking past it, and it does not end the dashboard session, only the chat connection.
The controls that do that work are elsewhere: an operating system screen lock, sensible access control for the team, and IP rules if you need to constrain where the console can be opened from at all.
What the visitor sees
Nothing, directly. There is no notice on the widget saying an agent went idle. What the visitor experiences is the knock-on effect of the status change.
If every available agent has been set to away, the widget behaves the way it does whenever nobody is available, which normally means offering to take a message instead of starting a chat. That is the correct outcome, and it is much better than a visitor waiting in a queue nobody is watching.
The case worth thinking about is a conversation already in progress when the sign-out policy fires. The agent is disconnected mid-conversation, and the visitor is left mid-sentence. This is the strongest argument for keeping the sign-out timeout comfortably longer than any plausible pause, and for not enabling it at all on teams where agents routinely spend several minutes researching an answer.
Common mistakes
Setting a sign-out timeout smaller than the away timeout, so the gentler policy never gets a chance to fire.
Switching a policy on and leaving its minutes blank, which reads as configured and behaves as off.
Assuming the lock policy hides anything. It does not.
Setting away so short that it fires while agents read, then concluding the status field is unreliable.
Expecting incoming chats or messages to count as activity. Only the mouse and keyboard do.
What to measure
Watch how often agents are automatically set to away during hours you believe are fully staffed. A high count means the timeout is shorter than the way your team actually works, not that your team is idle.
Line those transitions up against missed and abandoned chats. If missed chats cluster in the minutes after automatic away transitions, the policy is actively costing you conversations and the timeout should go up.
Then just ask the agents. Anybody who has been disconnected in the middle of a conversation will remember it, and one such report is enough to justify raising the sign-out timeout.