The question you will need to answer later
Something will eventually require reconstruction. A customer disputes what an agent promised. A
refund was issued that nobody can account for. Someone asks who has read a particular conversation.
In each case the question arrives days or weeks after the event, when memory is useless and only the
record can help.
The uncomfortable moment is discovering that the record does not exist — that you can see
the conversation but not who opened it, or that settings changed with no trace of who changed them.
Audit logging is the unglamorous work that decides whether those questions are answerable at all,
and it can only be done in advance.
Two different records, often confused
Transcripts and audit logs get treated as one thing, and they answer different questions.
The transcript is what was said between an agent and a customer. It answers
“what did we tell them?” The audit trail is what your team did to the
system: who logged in, who read which conversation, who changed a setting, who exported data, who
added or removed an account. It answers “who did that, and when?”
Disputes about a promise need the first. Anything involving access, privilege, or data movement
needs the second, and it is the second that teams more often find missing when they go looking.
What is worth recording
Log the events that are hard to reconstruct and consequential when contested:
- Authentication — sign-ins, failures, and where from. A cluster of failures followed by a success is one of the few genuinely early warnings available.
- Account and role changes — agents added, removed, or promoted. Privilege changes are the single most important category, because they are how a small compromise becomes a large one.
- Configuration changes — routing, hours, retention settings, integrations. These change behaviour invisibly and are frequently blamed on software faults.
- Data access and export — who read or downloaded transcripts in bulk. Bulk export is the action most worth being able to attribute.
- Token lifecycle — API credentials created and revoked, with their scopes.
Each entry needs the same four facts to be useful: who, what, when, and from where. An entry
recording only that something changed tells you a story has happened without telling you any of it.
A log nobody reads is only half a control
Logging that is written and never examined provides forensics after a known incident, but no
detection of an unknown one. The gap between those is usually where the damage accumulates.
You do not need a monitoring programme to close most of it. A short periodic look at a few things
— privilege changes since last time, sign-ins from unexpected places, bulk exports, changes made
outside working hours — catches the obvious cases at a cost of minutes. The value is less in
any individual review than in the fact that reviews happen, because unexamined systems drift.
Set an expectation for how quickly you would notice something. If the honest answer is that nobody
would look until a customer complained, that is the finding, and it is worth writing down.
Accountability without surveillance
Audit logs can curdle into monitoring of people rather than protection of data, and a team that
believes it is being watched behaves worse, not better — less willing to escalate, more
defensive about mistakes, slower to report the thing that would have contained an incident.
Three practices keep the distinction real. Be transparent: tell people what is logged and why,
during onboarding rather than during an investigation. Be purposeful: review for security events and
data access, not for how long someone took on a chat — performance conversations should draw on
performance data, openly. And limit who can read the logs, applying the same access discipline you
apply to transcripts.
Framed as reconstruction rather than supervision, audit logs mostly protect the team. When an agent
is accused of something they did not do, the record is what clears them.
Retention, and the accidental archive
Audit logs need a stated lifetime, decided deliberately rather than by default. Too short and the
questions that surface late cannot be answered. Too long and you have accumulated a detailed history
of your staff’s activity that must itself be protected.
Audit entries and transcripts do not need the same lifetime, and it is reasonable for the audit
trail to outlive the conversation content it refers to — the entry recording that someone
exported data stays useful after the exported conversations are gone. Whatever you choose, write it
down, make sure deletion actually happens, and remember to apply it to the copies: logs shipped into
another tool quietly inherit that tool’s retention, which is frequently forever.
What the audit screen actually shows
It helps to know what the built-in audit view is, because its shape decides which of the questions above it can answer for you and which ones you still have to arrange yourself.
MyLiveChat's audit log is a merged read-only feed rather than a single table that everything writes to. It pulls from five separate places and interleaves them in time order: outbound webhook deliveries and their outcomes, knowledge base article versions as they are saved, ticket activity such as status changes and assignments, channel identities being bound to a person, and AI tool invocations with the tool that ran and how it finished.
That design has a direct consequence worth internalising. The feed shows what those five subsystems already record, so it is excellent on the work itself and silent on things none of them touch. If your question is who changed a setting last Tuesday or who signed in from an unfamiliar place, this is not the screen that answers it. Knowing the boundary in advance is far better than discovering it during an incident, and it tells you which of your accountability needs have to be met somewhere else.
The view defaults to the last seven days and accepts a longer window up to ninety, which is also the outer edge of what it will show. Each of the five sources contributes at most a few hundred of its most recent entries to a single view, so a busy week will fill the window rather than showing you everything that happened in it. Filter before you scroll: you can narrow to one source, match on an event type, or match on an actor, and any of those turns an overwhelming feed into a readable one.
Reconstructing an incident in practice
The way to use a merged feed is to work backwards from the moment you care about, and to widen only when you have to.
Start with the time window as tight as you can make it, then filter by the source that maps to your question. A complaint that a customer was told something wrong is ticket activity plus, if you run an assistant, tool invocations. An integration that stopped receiving data is webhook deliveries. Content that changed without anyone remembering why is article versions. Doing this in the right order is the difference between a two-minute answer and an afternoon of scrolling.
Then export. The audit view offers a CSV of exactly what you are currently looking at, filters included, which is what you want to attach to an incident write-up rather than a screenshot. The export escapes values so that a cell beginning with a formula character cannot execute when the file is opened in a spreadsheet, which matters more than it sounds: audit exports frequently contain text somebody else typed, and that is precisely the path a spreadsheet injection takes.
One habit makes all of this easier. When you find the answer, write the finding into the ticket itself as a comment, with the timestamps you used. The log will roll past the window eventually; the ticket will not. Teams that keep their conclusions where the work lives rarely have to reconstruct the same incident twice.
What to arrange elsewhere
Because the feed is derived from those five sources, a complete accountability story usually needs two other pieces alongside it.
The first is anything you want retained longer than the window. Audit entries are a live view over data that ages out on each subsystem's own schedule, so if a compliance obligation says two years, the mechanism for that is a scheduled export you keep somewhere durable, not the screen. Decide that consciously and write down where the exports go, or you will find the obligation and the reality disagree at the worst possible time.
The second is real-time reaction. A log is for afterwards; it is not an alert. If you want to know at the moment something happens rather than at the end of the week, subscribe to the events that matter and send them somewhere a person sees, which is what sending live chat events to your own systems covers. The pairing is the useful pattern: events tell you now, the audit feed tells you what led up to it, and the administration features hold the controls that decide who could have done any of it in the first place.
Your own audit trail is only half of the picture. The other half is what is recorded when somebody at your vendor opens the same account, which who can open your dashboard when you ask for help covers in detail.
Tickets keep a trail of their own alongside all of this, with its own rules about what is written down and what is not. What your ticket history actually records sets out every event it captures, and the four it never will.