See who did what, when, on every ticket.
Solves keeps a metadata-only audit history and a per-ticket timeline of every meaningful action: inbound messages, public replies, private notes, assignments, state changes, delivery outcomes and admin events. It records what happened, when, by whom and on which organisation, brand and ticket, never the words inside the message.
The short answer
A timeline of what your team did, kept as metadata
Every ticket in Solves carries a timeline, and your organisation carries an audit history. Together they answer the question every support team eventually asks: who did that, and when. The records are metadata only by design, so you get accountability without ever storing or showing the content of a customer message.
The timeline orders the life of a ticket as a sequence of events. An inbound message arrives. The ticket is assigned to an owner. A public reply goes out, and its delivery outcome comes back. A private note is added for a colleague. The state moves from New to Open to Waiting for Customer. Each of these is recorded as a typed event with an actor and a timestamp, so the history reads cleanly from top to bottom.
Crucially, the audit history stores the shape of each action, not its substance. It knows that a reply was sent, by whom, on which brand and ticket, and whether it was delivered. It does not store the reply text, the subject, the contact's address or the attachment. That content is encrypted at rest under per-organisation keys, and the logs and audit records hold metadata only. The result is a record you can keep, search and hand over without leaking what a customer wrote.
What gets recorded
The events behind every ticket
A typed, time-ordered history of the actions that move a ticket, captured as metadata.
Inbound received
When a customer message arrives and becomes a ticket, the timeline records the event, the mailbox and brand it landed on, and the time, without storing the message body or address.
Public reply sent
Each outbound reply is recorded with its actor, brand, mailbox and timestamp, so you can see who answered the customer and exactly when they did it.
Private note added
Internal notes are logged as collaboration events, by whom and when. The note stays internal and hard-separated from the customer; only the metadata enters the history.
Assignment and ownership
Every assignment, reassignment and change of owner is recorded, so a ticket that moved between teammates carries a clear trail of who held it and when.
State and priority changes
Moves between New, Open, Waiting for Customer, Snoozed, Resolved and Closed, plus priority and tag changes, are each timestamped against the actor who made them.
Delivery outcomes
When an outbound reply is accepted or fails downstream, the delivery outcome is recorded against the ticket, so a non-delivery is visible rather than silent.
Beyond the ticket
Admin and mailbox changes are audited too
Accountability cannot stop at the ticket. The settings that decide how mail flows are audited as well. When a mailbox is added or its sender details change, when a verification step completes, or when a live-send override is recorded during guided setup, the audit history captures the change, the actor and the time. So a question like "who turned on sending for this brand" has an answer.
What an admin event looks like
An admin event follows the same metadata-only rule as a ticket event. It records that a mailbox or sender setting changed, who changed it and when, scoped to the organisation and brand it affects. It does not store secrets, keys or DNS values as readable text in the log. You see that a change happened and by whom, which is what you need to trace a configuration decision back to a person.
Why a founder override is recorded
Solves keeps live sending for a brand blocked until its mailbox checks pass, with one deliberate exception: a recorded founder override during pilot setup. Because that override loosens a safety gate, it is exactly the kind of action an audit history exists for. The override is written as an audited event, so there is never an unexplained moment where sending was switched on for a brand that had not yet verified.
How to use it
From a question to an answer in three steps
Open the ticket timeline
Every ticket shows its history in order: inbound, replies, notes, assignments, state changes and delivery outcomes, each with an actor and a timestamp.
Read what happened
Follow the chain to see who picked the ticket up, who replied, when it moved to Waiting for Customer, and whether the reply was delivered, all as plain metadata.
Trace settings changes
For a configuration question, check the audit history for the mailbox or sender change, the actor and the time, so a setup decision can be explained and handed over.
Metadata only, by design
The audit history and timeline hold metadata: event type, actor, timestamp and the organisation, brand and ticket. They never hold message bodies, subjects, addresses or attachments. That content is encrypted at rest under per-organisation keys, and our application logs are metadata only too, in line with our security posture.
Where it helps
What a clean history is actually for
A metadata-only audit history earns its keep in the ordinary moments, not just the rare investigation. When a customer says they never got a reply, the timeline shows whether one was sent and what the delivery outcome was. When a teammate is unsure who owns a ticket, the assignment trail settles it. When a handover happens, the new owner reads the history instead of asking around.
Investigating without reading private content
The hardest part of investigating support is doing it without trampling on what customers wrote. Because Solves records actions and not content, a manager can reconstruct what the team did, when, and on which brand, without opening message bodies they do not need to read. Accountability and privacy are not in tension here: the record is built to give you one without the other.
Reporting sits next to the record
The same events that fill the timeline feed the reports. First response, resolution time, ageing and the waiting and breaching views all draw on timestamped events. The audit history is the per-ticket detail behind those summaries, so when a report raises a question, the timeline holds the per-ticket answer, scoped to the brand it belongs to.
FAQ
Audit log questions
What is an audit log in a support desk?
An audit log is a time-ordered record of the actions taken on your tickets and settings: who replied, who reassigned a ticket, who changed a mailbox, and when. In Solves it is metadata only. It captures what happened, when, by whom and on which organisation, brand and ticket, so you can answer "who did that and when" without ever reading back the content of a customer message.
What is logged, and what is not?
Logged: the type of event (inbound message received, public reply sent, private note added, ticket assigned, state or priority changed, delivery outcome, admin or mailbox change), the actor, the timestamp, and the organisation, brand and ticket it relates to. Not logged: the body of any message, the subject text, the customer's email address, attachments, or any other free text. The content of support email is encrypted at rest and is never written into the audit history or the application logs.
Can I see who changed a mailbox?
Yes. Mailbox and sender changes are audited. The audit history records that a mailbox setting was changed, the actor who changed it and the time, so a verification step, a forwarding change or a live-send override can be traced back to a person. This sits alongside ticket events in the same metadata-only record.
Does the timeline show private notes to customers?
No. The timeline records that a private note was added, by whom and when, as an internal collaboration event, but the note text itself stays an internal note and is never exposed to the customer. Public replies and private notes are kept hard-separated in Solves, and the audit history only ever holds the metadata of each, not the words.
How long is audit history kept?
Audit and timeline metadata is retained alongside the ticket it belongs to, so a ticket's full history travels with it. Because the records are metadata only, they stay small and readable. Retention of operational logs is governed by our observability runbook, and customer content is encrypted at rest throughout, with authorised access only.
Is the audit log a compliance feature?
It is an accountability and operational-transparency feature, built for UK SMEs that need to see who did what. It is encrypted at rest, access is authorised only, and the logs are metadata only by design. We do not market it as a formal compliance certification: it is a practical record that helps you investigate, hand over and explain what your team did.
Keep a clean record of who did what
Start at £29, or let us help you set up your brands, mailboxes and team.