Acuity Scheduling

Acuity Scheduling (owned by Squarespace since 2019) has no built-in generative AI or predictive-scheduling model -- what looks "smart" is deterministic configuration: buffer times, per-appointment-type availability limits, and automatic client-side timezone detection, not machine learning acting on your booking data.

Practical detail

The real automation surface is templated: automatic email/SMS confirmations and reminders you configure once, plus Zapier for anything that needs to react to a new booking in another system (adding a contact to a CRM, posting to Slack, etc.). None of this involves a model making a judgment call -- it's rule-based triggers firing on a booking event.

Actionable considerations

• Don't expect Acuity to suggest optimal appointment slots or auto-adjust availability based on booking patterns -- that logic has to be built externally if you need it
• Use Zapier to react to booking events (new appointment, cancellation, payment) rather than looking for a native AI-driven workflow builder
• Configure reminder/confirmation templates carefully upfront, since they're static text, not adaptive messaging

Each staff member gets their own calendar with independent availability, and bookings can route to "any available staff" or a specific person depending on the appointment type's configuration -- this scales reasonably well for a single-location team but doesn't extend into a native multi-location hierarchy.

Practical detail

For multi-location businesses, the practical approach is separate calendars (or separate accounts) per location, since Acuity doesn't have built-in location-aware routing the way some enterprise scheduling platforms do. Classes also have a hard per-session capacity cap that doesn't flex automatically as demand grows.

Actionable considerations

1. Use "any available staff" routing for interchangeable services and named-staff routing where clients need continuity
2. Plan for separate calendars (or accounts) per physical location rather than expecting native multi-location support
3. Revisit Class capacity caps manually as demand changes, since they don't auto-scale

A working setup sequence: connect calendar sync first and confirm it isn't double-booking, then build out appointment types with real durations and buffers, attach intake forms to the types that need them, and configure the booking page's branding and timezone display before sharing the link publicly.

Implementation details

Testing the complete flow as a client -- booking an appointment, receiving the confirmation, receiving the reminder -- before going live catches configuration mistakes (wrong buffer, missing intake form, broken payment step) that are much cheaper to fix before real clients hit them.

Actionable considerations

• Verify calendar sync for double-booking conflicts before building out appointment types
• Attach payment/deposit requirements at setup time if you need them, since retrofitting can disrupt already-booked appointments
• Run a full test booking as a client before sharing the public booking page

Acuity's core unit is the appointment type -- each one has its own duration, buffer time before/after, optional attached intake form, and optional payment/deposit requirement. Clients book through a self-service page (a standalone link or an embeddable widget) that automatically detects and displays their local timezone, which removes a common source of scheduling errors.

Practical considerations

Group sessions run through a separate "Classes" feature with a hard capacity cap per session, distinct from the one-to-one appointment-type model -- if your business needs both individual bookings and capped group sessions, you'll configure them as two different constructs rather than one flexible appointment type.

Actionable considerations

• Map each real service you offer to its own appointment type, including realistic buffers, rather than one generic "meeting" type
• Attach intake forms only to the appointment types that actually need pre-visit information, since forms add friction to booking
• Use Classes (not appointment types) for anything with a hard headcount cap per session

Native integrations cover the essentials: Stripe, PayPal, and Square for collecting payment or a deposit at booking, plus two-way calendar sync via Google, Outlook, or CalDAV/Exchange (not just a one-way ICS feed, which matters if you also get booked outside Acuity). Beyond that, Zapier is the real cross-system automation layer.

Practical detail

Acuity has no internal multi-step workflow builder -- its own automation is limited to templated email/SMS reminders, confirmations, and follow-ups tied to packages or gift certificates. Anything conditional (route this client type to a CRM stage, notify a specific team member) has to go through Zapier reacting to a booking, cancellation, or payment event.

Actionable considerations

1. Set up payment collection (Stripe/PayPal/Square) at the appointment-type level if deposits or full payment should happen at booking
2. Use two-way calendar sync, not a one-way feed, if staff also get booked through channels outside Acuity
3. Build any conditional cross-system logic through Zapier rather than looking for it natively in Acuity

Acuity's help center and community forum are the primary self-serve resources, and since the 2019 Squarespace acquisition, live support routes through Squarespace's broader support system rather than a dedicated Acuity-only support line -- worth knowing if you're expecting category-specific phone support common with some standalone scheduling tools.

Practical detail

Most day-to-day configuration questions (appointment-type setup, calendar sync issues, payment integration) are well covered in the help center and forum, since these are common, well-documented scenarios across a large existing user base.

Actionable considerations

1. Check the help center and community forum first for common setup and sync questions -- they're well documented
2. Expect support to route through Squarespace's general channels rather than an Acuity-specific line
3. Budget onboarding time for staff to independently test their own calendar and booking flow rather than relying only on documentation

Acuity's permission model has exactly two tiers: Owner, who sees all calendars, clients, and billing, and Staff, who by default sees only their own calendar and clients. An owner can grant a staff member visibility into other calendars, but there's no department-level or granular field-level permission system beyond that.

Practical detail

Teams coming from tools with fine-grained role-based access control should know this upfront -- if you need permission tiers between "sees everything" and "sees only their own bookings," that distinction doesn't exist natively in Acuity and would need to be managed through process rather than a system setting.

Actionable considerations

1. Assign Owner access sparingly, since it includes full billing and account control, not just scheduling
2. Grant staff visibility into other calendars only where it's actually needed, since the default is calendar-isolated
3. Don't expect a middle permission tier -- plan team processes around the two-tier Owner/Staff model

A realistic rollout starts with one staff calendar: connect two-way sync (Google, Outlook, or iCloud/CalDAV) and confirm it isn't creating double-bookings before adding appointment types, intake forms, or a public booking page. Rushing straight to a public link before sync is verified is the most common source of early scheduling conflicts.

Practical detail

A real gotcha worth knowing upfront: events created directly in your connected external calendar (not through Acuity) still block availability correctly via sync, but they won't trigger Acuity's intake forms or automated reminder sequences -- those only fire for bookings made through Acuity itself.

Actionable considerations

1. Connect and verify two-way calendar sync on one staff calendar before rolling out a public booking page
2. Test the full booking-to-confirmation-to-reminder flow as a client would experience it before going live
3. Remember that externally-created calendar events block availability but don't trigger Acuity's intake forms or reminders

Client and appointment data lives inside your Squarespace-managed Acuity account, and you can export it as CSV from account settings -- but there's no self-serve bulk-delete tool for client records, so GDPR-style erasure requests for individual clients typically go through Squarespace support rather than a one-click admin action.

Practical detail

Access control is coarse by design: an Owner login sees everything (billing, all calendars, all clients), while a Staff login sees only their own calendar and clients by default, with an option for the owner to grant a staff member visibility into other calendars. There's no department-level or field-level permission tier beyond that split.

Actionable considerations

1. Export client and appointment data periodically via account settings rather than assuming a native retention/archival system
2. Route data-deletion requests through Squarespace support, since there's no self-serve bulk-delete tool for individual client records
3. Plan around the two-tier Owner/Staff permission model rather than expecting granular role-based access control