Most chat reporting answers questions about conversations: how many, how fast, how well. Availability data answers a question underneath all of that, which is whether anybody was there to have them.
It is the number you need when the story does not add up. Response times got worse in the second half of the month and nobody knows why. A shift that used to run smoothly now leaves a backlog. Somebody says we are understaffed and somebody else says we are not. Conversation metrics cannot settle those arguments, because they only describe the chats that happened. Presence describes the coverage those chats arrived into.
MyLiveChat records this per agent, and surfaces it in two dashboard views: Total Online Time, which shows a month and lets you drill into a particular day, and the Daily Agent Timesheet, which lays out a single day in detail. They read the same underlying record from different distances.
What the record actually contains
Knowing how the data is built tells you what it can carry. The record is kept per agent per month, and the finest grain it holds is a five-minute bucket. Within each bucket it stores the status the agent was in, drawn from four values: online, away, busy, and appear offline.
Two properties follow from that design and both matter when you read a chart.
- A bucket can hold more than one status. Statuses are combined rather than replaced, so an agent who went from online to away inside the same five minutes shows both. That is not a glitch, and it is why totals across statuses can look larger than the wall clock.
- It is sampled, not stopwatched. The record is written by a periodic sweep, so a status held very briefly between sweeps may leave no trace. The shape of a day is reliable. The exact minute count is an approximation.
That second point is the one to internalise. Read it as a good picture of coverage, and never as a clock.
The four things it will not tell you
Every dataset has an edge, and this one has four worth knowing before you quote a number in a meeting.
- Work done from a phone does not count. Only desktop console connections mark an agent as online. An agent covering an evening from the mobile console is genuinely working and will read as absent. If your team answers from phones, this view will understate them badly.
- Online is not the same as working. An agent signed in with the tab in the background is online. Availability tells you the seat was filled, not that anyone was in it, which is exactly the gap an idle policy exists to narrow.
- It is not workload. Two agents can log identical hours and carry wildly different loads. For that question you want concurrency and handle time, covered in measuring agent workload.
- Availability records are a paid-plan feature. If you are evaluating on a free plan, the views will be empty, and that is the plan rather than a fault.
Reading the shape of a day
Open a single day in the timesheet and look at the outline before any total. Three shapes come up repeatedly and each means something specific.
The ragged edge. Coverage that starts late and finishes early relative to the schedule. Usually a start-of-shift ritual, not absence: people arrive, deal with email, and sign into chat last. The fix is a shift checklist, not a conversation about commitment.
The synchronised gap. Every agent away at once, most often at midday. Harmless if your traffic dips then, expensive if it does not. This is the single most actionable thing in the view, because staggering a lunch break costs nothing and closes a real hole.
The long away band. A block of away that runs for hours. Sometimes a meeting nobody logged, sometimes an agent who forgot to come back, and sometimes an idle rule doing its job while the person worked in another tool. Check which before drawing a conclusion.
Compare the shape against arrival traffic rather than against the roster. A roster tells you what you intended. Availability against arrivals tells you what the visitor experienced.
Using it without turning it into surveillance
Presence data is the easiest reporting in any support team to misuse, because it looks like an attendance register and reads like one to anybody who has not been told otherwise. Treat that as a design constraint on how you use it.
Some rules that keep it useful:
- Use it on the team, not on the person. The question worth asking is whether the shift was covered. Ranking individuals by hours logged optimises for staying signed in, which is not a behaviour you want more of.
- Never combine it with a quality metric into one score. The two measure unrelated things and the composite hides both.
- Ask before you conclude. Given the mobile gap and the sampling, a surprising record is more often an artefact than a story. The agent usually knows which.
- Say out loud that it exists. Presence data discovered by an agent lands far worse than presence data explained on day one, a point we make more generally in sharing chat metrics with your team.
How MyLiveChat fits
Both views live in the dashboard next to the rest of the reporting, and both read the same per-agent record. They do not, however, report the same total, and it is worth knowing why before you try to reconcile them. The month view counts online time only — buckets where the agent was away, busy or appearing offline are excluded from its figure. The daily timesheet breaks those four statuses out separately and its headline totals count connected time, meaning any status at all. So the timesheet's total for an agent will normally be the larger number, and the gap between the two is the time that agent spent away, busy or hidden. Use the month view to find the day worth looking at, and the timesheet to understand it — but compare like with like, which means reading the timesheet's own online column against the month view rather than its connected total.
Pair it with the conversation reporting in analytics rather than reading it alone. Coverage plus arrival volume is a staffing conversation; coverage plus response time is a capacity conversation; coverage on its own is just hours, and hours have never settled anything.
If you are building a schedule from scratch, availability records from a few real weeks are the most honest input you have, because they describe what actually happened rather than what the roster said would.
What to measure
Pull three things from the record and ignore the rest until they raise a question.
- Covered hours against your published hours. The gap between what the widget promises and what the record shows is the single most useful number here.
- Overlap at your busiest hour. How many agents were genuinely online when the most visitors arrived. Daily totals hide this completely.
- Simultaneous away. The minutes when everybody was away at once, which is functionally an outage your visitors experienced and your uptime reporting did not notice.
Look at all three monthly, not daily. Presence data is noisy over one day and clear over four weeks, and reacting to a single afternoon is how teams end up managing a chart instead of a service.