Appointment Change History for Service Teams

A client remembers one time, the current appointment shows another and the person who handled the original request has finished their shift. A useful change history gives the next team member a place to start.

Open Settings → Activity Log to review recorded actions. Read the entry, the actor and the time, then open the current record. That combination shows both the supported change and the state your team must work with now.

The log can help an owner, manager or other permitted team member prepare a focused handover. It does not replace a conversation with the client or the staff member who knows the circumstances. The Activity Log guide explains a full investigation workflow.

FindSlot records supported actions such as accepting or declining a request, canceling, rescheduling, reassigning a provider and changing an appointment to Missed or Completed. Entries describe the action in readable language, with before-and-after detail where recorded.

The history explains recorded changes, not every reason behind them. A reschedule entry may establish the old and new time while the reason still needs a short conversation.

A booking discrepancy can begin with a setting rather than with an appointment edit. A changed duration, saved schedule or booking-page detail may affect what the team expects to offer or communicate.

The Activity Log covers supported updates to services, staff, roles assigned to staff, saved schedules, clients, booking links, booking-form fields, company settings and calendar connections. Recorded booking-page design and FindSlot badge changes appear as separate fields where supported.

Saved schedules produce an entry when something changed. Use that context when a provider says their published availability looks different, then inspect the actual staff schedule and the public booking path. Reading an entry alone does not validate the full configuration.

The actor may be a staff member, Client, System or FindSlot support. Check the label before assuming that a colleague manually made the change. System activity can represent automated work, while a Client action differs from a staff member changing a booking after a phone call.

Next read the sequence. In an illustrative example, an appointment moves from 10:00 to 11:00, then is canceled later. The first entry explains the move, but it does not mean an 11:00 appointment still exists. The latest state and later entries matter.

Use the actor as evidence of the recorded source, not a reason to assign blame. Establish what happened, agree any correction and make that correction through the appropriate current controls.

Category, person and date filters help narrow a busy log. Begin with the approximate period of the change and the kind of action being investigated. Add the person filter when it helps, without excluding other actors who may explain a later step.

For a booking-time question, confirm the correct client, appointment date, service and provider first. Then look for the relevant change and any subsequent action. Review client appointment history when the issue also concerns past visits or the next booking.

This makes the review proportional to the task. Your team does not need to read every activity entry at every handover. Concentrate on disputed or unresolved work and settings that affect the next shift.

Activity entries are retained for 60 days. Investigate a recent problem while its relevant entries remain available. The log is an operational history, not a permanent archive or a complete compliance record.

The current business-facing log does not record appointment notes, edits to custom role definitions or staff-to-service assignment changes. It also does not show IP addresses, browser details or request identifiers. The absence of an entry therefore cannot establish that every field or configuration remained unchanged.

There is no undo function in the log. A readable historical sentence can still be useful when a related record was renamed or deleted, but it is not a restore control. Inspect the current configuration and make a deliberate permitted correction when one is needed.

Owners and managers have Activity Log access by default. Other people need the appropriate viewing permission. The feature is included across plans; access permissions still determine who can read it.

Agree who reviews disputed changes and who passes unresolved questions to the next shift. An employee without log access can identify the affected appointment for a permitted manager to investigate. Keep the handover factual: current booking, recorded action, remaining question and owner of the next step.

Use clear confirmation messages after an agreed booking correction, and make rescheduling rules understandable to the team. The history supports those actions; it does not communicate the resolution to the client by itself.

Review current FindSlot plans, open a recent supported change and compare its entry with the actual appointment. A clear current record and a useful recent history make the next decision easier.