Run the front desk from one Acuity Scheduling day board

Build me a front desk day board for Acuity Scheduling that my reception team keeps open all day instead of clicking around the Acuity admin. This is an interactive surface people work in between clients, not a scheduled digest, so nothing here runs on a timer.

The main screen is a single day view. At the top put a date picker that defaults to today with quick previous day and next day arrows, plus filters for calendar or staff member and for appointment type. Below that, list every appointment for the selected day in time order. Each row shows:

• Start time and duration

• Client name

• Appointment type and the calendar or staff member it sits on

• Price, and a clear paid or unpaid badge

• A flag when the client is new, plus a small indicator when the appointment already has a note or label

For the reads, use Acuity List Appointments with the selected day as the minimum and maximum date, List Calendars to populate the calendar and staff filter, List Appointment Types for type names, durations, and standard pricing, and List Clients for client lookup and contact details. Appointments that are already cancelled should still render but visibly muted, and reschedule should not be offered on them.

Two data quirks to normalize before anything reaches the UI. Acuity returns prices as decimal strings such as "10.00" rather than numbers, so parse them before formatting as currency or summing totals. Acuity returns the paid field as the string "yes" or "no" rather than a boolean, so convert it explicitly and never rely on truthiness, since the string "no" is truthy and would show every unpaid visit as paid.

Derive the new client flag by checking whether that client has any appointment before the selected day, using List Appointments filtered to their email with an earlier date range. Resolve this once per client per day rather than once per row, and cache it for the session, so a day with several visits from the same person does not fan out into duplicate lookups.

Clicking any appointment opens a side panel so the person at the desk gets context without opening a second tab. The panel shows the client's full visit history, meaning their past and upcoming appointments with date, type, calendar, price, paid state, and whether they attended, and it shows the intake form answers captured on the booking. Keep the day list visible behind the panel so the desk does not lose their place.

From that panel the user can take four actions. To reschedule, let them pick a target date and then call Get Available Times for that appointment type and calendar to show only slots that are genuinely open, then commit the chosen slot with Reschedule Appointment. Never let someone type a free text time. To cancel, call Cancel Appointment with an optional cancellation note. To mark a no-show, call Cancel Appointment carrying the no-show flag, since that is where Acuity records it. To save a note or a label onto the appointment, call Update Appointment.

After any write, refresh the affected appointment in place and keep the selected date, the active filters, and the scroll position exactly where they were. Update the row optimistically, and if Acuity rejects the change, revert the row and surface the reason in plain language rather than a raw error.

Add an end of shift handoff button that posts a summary to Slack using Slack Bot Send a Message. The post covers the selected day and lists the no-shows, the cancellations, and the visits still unpaid, each with client name, time, service, and amount owed where relevant, plus a short count line at the top such as how many appointments ran, how many no-showed, and the total still outstanding. Show the user a preview they can edit before it posts, and confirm once it has landed. Remember the chosen Slack channel for next time.

Remember each user's last used calendar or staff filter and their Slack channel choice, so the board opens on their own column each morning. Acuity allows roughly ten requests per second per account, so batch the day view reads and avoid firing unbounded parallel per row requests, particularly when resolving client history for the new client flag.