Who Changed That, and When? Audit Logs Are Now Live

Every hotel has a version of this conversation. A guest's chat ended up with a different butler halfway through the stay. Or a room number changed. Or someone adjusted an SLA threshold and nobody can say who.

Reception thinks the night manager did it. The night manager is off until Thursday. Nobody wrote anything down, because writing it down was never anybody's job.

Audit Logs is now live in Butler AI, and it answers those questions without anyone having to remember.

An append-only timeline of notable actions for your hotel, newest first. Each entry answers five things: what happened, when, who or what caused it, who it was about, and any extra context.

Events are written automatically when the underlying action succeeds. There is no "log this" button, nothing to switch on, and no way for a staff member to forget.

Live today:

• Chat — chat.assigned, chat.reassigned
• Guest — guest.qr_scanned, guest.updated
• Reservation — reservation.created, reservation.updated
• Hotel — hotel.updated
• Settings — settings.updated

Reservation events carry their origin, so a record created by Mews is labelled differently from one pushed in through the reservation API. Chat events carry the assignment strategy and the room. Guest and settings events carry the list of fields that actually changed.

Each row leads with a human-readable summary rather than a machine key — "Reassigned Sofia Martinez's chat to Alfredo Rossi", not chat.reassigned. The action key is still there, in monospace, for anyone who wants it.

Underneath, a fact line gives the shape of the change at a glance. Reassignments read as "Carlos Mendes → Alfredo Rossi · Guest request". Settings changes read as "Updated: sla, guestTags". Reservations read as "mews · Room 412 · checked_in".

Each row is colour-coded by category and carries an actor badge — staff, guest, system, or the PMS that produced it.

The feed is filterable by the things you would actually ask about:

• Date — Today, Last 24h, Last 7 days, or an explicit range
• Category — chat, guest, reservation, hotel, settings and the rest
• Action — an exact event type
• Staff — everything tied to one butler
• Guest — search by name, with room number shown to disambiguate
• Room — for when the room is all you have

Active filters show as chips you can clear one at a time. Any row can also become a filter: click the guest, the staff member, or "this action" and the feed narrows around it.

Expanding a row shows the changed fields as chips and the full raw metadata as JSON. That is the level operations actually needs during a dispute — not a paraphrase, the record.

From there you can jump straight to the guest profile, open the conversation the event refers to, copy the guest ID, or copy the whole event.

The toolbar carries Expand all, Collapse all, Copy link, Export CSV and Refresh. Copy link preserves the filters you applied, so "here is exactly what I am looking at" is one paste rather than a screenshot and an explanation. Export CSV takes the filtered view out for a handover pack or an owner's report.

You will find it at Dashboard → Audit Logs. It is scoped to your hotel, using the same permissions as the rest of your ops data — results never cross properties.

Most accountability tooling in hospitality is a paper trail someone has to maintain. That works right up until the shift gets busy, which is exactly when the record matters most.

This is the opposite: the record is a by-product of the work. The butler reassigns a chat because a guest asked; the event exists because the reassignment happened, not because anyone remembered to note it.

That changes what a handover can be, what a dispute looks like, and how much of your service quality depends on who happens to be on shift. It sits alongside the SLA alerts and tracked resolution managers already use, and it records changes to the ops settings themselves. For the wider operations layer it belongs to, see Butler Operations.