Audit logs for operational communications

After a town centre incident, a member may ask when your team was notified and who attended. A timeline backed by system events is easier to defend than recollection alone. Insurance and clients increasingly want process evidence. You are not logging every spoken word on PTT by default. You are logging structured actions around jobs and administration.

What good logging enables

Login events. Admin changes. Assignment updates. Status moves on incidents. Combined with job timelines, you get a coherent picture from creation to closure without asking three people to piece together their personal mobiles.

This matters most in the moment someone external asks a question weeks after the fact. A member complaint, an insurer's query, or a client's own audit rarely arrives the same day an incident happens. By the time the question lands, memory has already faded, and a structured log is often the only reliable source left.

Why this matters more than it first appears

Most organisations only think about this after the first time they wish they had it. A supervisor gets asked when a crew was notified about a hazard, and the honest answer is "sometime around lunch, I think." That answer is fine internally. It is a weaker position with a member, a client, or an insurer who wants something closer to a timestamp.

Structured logging exists to close that gap without turning every shift into a compliance exercise. The goal is a record that exists automatically because of how the system works, not one that requires field staff to fill in extra forms on top of doing the job.

What to expect on RevoNet

Tenant admins review audit activity for their organisation only. Entries never cross tenants. Exact events evolve as features ship. Treat the log as shift support, not a legal archive unless your organisation configures retention and export to meet its own policies.

This distinction matters. The log is genuinely useful for reconstructing what happened and when. It is not, on its own, a substitute for whatever formal record-keeping your organisation is legally required to maintain. If your sector has specific retention obligations, that responsibility sits with your organisation's own policies and processes, supported by the log rather than replaced by it.

Culture matters

Heavy surveillance erodes trust. Log job state changes and admin actions rather than micromanaging break times. Tell staff why records exist: safety, fairness, and faster dispute resolution when something is disputed.

Staff who understand that logging exists to protect them, not just to monitor them, tend to have far fewer objections than staff who discover it after the fact. A short, honest explanation at rollout saves considerably more friction later than saying nothing and hoping nobody asks.

Where this shows up in practice

The most common real use is answering "when did you attend?" style questions from members or clients weeks after an incident. The second most common is internal: a debrief where a supervisor wants to reconstruct exactly how a job moved from creation to closure, including who was assigned and when the status changed.

Neither of these requires reading a transcript of what anyone said on the radio. Both are answered by the structured record around the job itself, which is the whole point of keeping voice and administrative logging conceptually separate.

Setting expectations with your team early

The best time to explain audit logging is during onboarding, not after someone asks why it exists. A short explanation, voice is not recorded, structured job and admin actions are, tends to prevent the assumption that every conversation on a talkgroup is being monitored. Left unexplained, that assumption spreads fast and erodes exactly the trust logging is meant to support.

It also helps to say plainly what the log is used for in practice: answering "when did you attend" questions, supporting debriefs, and giving tenant admins a record of who changed what. Staff who understand the practical use case rarely object to it once it is explained rather than discovered.

Common questions

Does this record what people say on PTT? No. Audit logging covers structured actions, logins, admin changes, and incident status moves, not voice content.

Who can see the audit log? Tenant admins for your own organisation only. Entries never cross into another customer's account.

Is this a legal record we can rely on in a dispute? Treat it as a strong starting point rather than a legal archive. If your organisation needs guaranteed long-term retention or export for compliance reasons, that is worth discussing directly, particularly on Enterprise plans.

Do we need to configure anything to get logging? Basic activity logging is available to tenant admins from the admin area. Specific retention or export needs beyond that are a conversation for Enterprise customers.

Review happens in the admin area at launch. Enterprise customers with specific export needs should contact us.

Retention follows infrastructure practice and what you document internally if you need multi-year storage. Serious events still need your formal reporting process. The log supports it; it does not replace it.