If you build Squarespace sites for clients, the problem usually shows up when the class works.
A workshop fills. A class sells out. Someone buys two spots. The buyer is not the person attending. Someone asks to join a waitlist. The client needs to email only the people registered for that one event. Someone needs to check people in at the door.
Before that, the client needed a way to take a booking.
Now they need a way to run what they successfully filled.
The question is no longer only, “When can someone book?” It becomes, “Who is coming? What did they buy? What do they need to know? Is there room? Who is waiting? Who showed up? What happens next?”
Acuity is for availability.
Eventually is for programming: the classes, gatherings, and recurring events a business wants to run through its own Squarespace site.
Use Acuity when people are mostly booking a time.
Use Eventually when people are choosing what to attend.
Acuity can still be the right answer
Acuity is usually the first tool Squarespace designers reach for when a client wants to run a class or workshop. A lot of the time, that makes sense.
If the client is booking one-on-one appointments, consultations, private sessions, simple group classes, or workshops with one price, one time, and one clean registration flow, Acuity may be enough.
In those cases, the customer is choosing a time and booking into it. The business needs a name, an email, maybe an intake form, payment, confirmation, reminder emails, and a place on the calendar.
Acuity is built for that.
Even for group classes, Acuity can work well. If the client has a weekly class with a clear maximum number of people and no special registration complexity, there may be no reason to move away from it.
A tool does not need to be replaced just because another tool exists. If Acuity works, the client understands it, and the business is not losing time or clarity around the process, leave it alone.
The question is not whether Acuity can handle classes.
The question is whether people are just booking a time, or choosing what to attend.
Where the setup starts to feel wrong
The phrase I would listen for is:
“We’re using Acuity, but it feels weird.”
Most of the time, Acuity still works well enough for someone to register. The problem is what the client has to manage around it.
They may be exporting lists, emailing attendees manually, tracking waitlists in a spreadsheet, or trying to manage different ticket types with workarounds. They may be using a scheduling page when what they really want is an event page. They may be trying to make a class feel like part of the brand while the flow still feels like booking an appointment.
The issue may not be the design of the page.
The business may have outgrown the appointment model.
The buyer is not always the attendee
For an appointment, the buyer and the attendee are usually the same person.
Classes and workshops get messier.
One person may buy two tickets. A parent may register a child. A company may register a team member. A friend may buy seats for a group. A nonprofit supporter may purchase tickets for guests.
Now the business does not only need the buyer’s information. It needs to know who is actually coming.
The client may need each attendee’s name, email, meal preference, access needs, waiver status, experience level, or answer to a custom question. They may need to know which attendee belongs to which ticket. They may need a check-in list that reflects actual attendees, not just the person who paid.
If the client keeps saying, “We need to know who is coming,” they may need more than scheduling.
They may need event registration.
The waitlist becomes more than a name in a spreadsheet
A simple appointment waitlist is about filling a canceled time slot.
A class or workshop waitlist is about managing demand for a specific event.
The business may need to know who asked first, who gets the open spot, who needs to be notified when someone cancels, who should hear about the next date, and how many people were interested but could not get in.
A sold-out class should not create a second system made of spreadsheets, inbox searches, and memory.
When the waitlist becomes part of the business, the client has probably moved beyond simple scheduling.
Ticket types change the shape of the offer
Acuity is strongest when people are booking a spot in a time slot.
But many workshops and classes eventually need ticket types: general admission, member pricing, early bird, VIP, child ticket, in-person, virtual, workshop plus materials, class plus kit, drop-in, full series.
Once the client starts thinking this way, the class is no longer just a time slot. It is an event offer with different ways to participate.
Capacity can also get more complicated. A room may hold 50 people total, but the client may want to sell a mix of tickets. There may be 20 in-person spots and 100 virtual spots. The event may have add-ons that require their own inventory.
“Just let people book a class” starts to break down.
The client needs to manage the event as a whole.
The calendar becomes something people browse
Acuity is good at showing available times.
Some businesses need more than available times. They need a calendar people actually browse.
A cooking school is not just saying, “Here are the times you can book.” It is saying, “Here are the classes we are offering.”
A pottery studio is not just publishing availability. It is presenting wheel throwing, glaze night, hand-building workshops, open studio, and seasonal classes.
A coworking space is not just listing open slots. It is showing founder breakfasts, member workshops, pitch nights, and community events.
The calendar is not admin anymore.
It is how people choose what to attend.
That is programming.
The event needs its own communication
Acuity confirmations and reminders may be enough for appointments.
Programming often needs a different communication pattern.
The client may need to email everyone registered for one specific workshop, send a prep email before the event, update attendees if the time or location changes, send the right Zoom link, or follow up only with the people who attended.
When those messages happen manually, the event setup is not carrying the full workload.
The website may look fine from the outside, while the client is doing extra labor behind the scenes to make the event run.
This is where a designer can become useful again.
Check-in makes the difference visible
Check-in is another place where a class starts behaving like an event.
For a small class, the client can look at a list and mark people off. But once the event gets larger, more frequent, or more operationally important, check-in starts to matter.
Who arrived? Who bought a ticket but did not show up? Who is on the waitlist? Who has a guest? Who bought the workshop plus materials? Who is attending virtually? Who needs to be scanned at the door?
Order confirmations are not the same thing as a check-in flow.
If the client is running events where attendance matters, they need a cleaner way to manage the room.
That is event operations, not appointment scheduling.
Where Eventually fits
Eventually is for the moment a Squarespace business stops asking, “How do people book?” and starts asking, “How do we run this?”
It is for businesses whose calendar has become part of how they earn, teach, gather, or build community: cooking schools, pottery studios, yoga studios, wineries, restaurants with tastings or seasonal events, nonprofits with community programming, coworking spaces with member events, cultural spaces, membership communities, and studios with recurring classes and workshops.
These businesses may not think of themselves as event businesses. They may not say they are doing events at scale.
But they understand programming.
Their calendar is no longer just a list of times. It is where people browse what is coming up, choose what they want to attend, register, receive the right information, and show up.
Eventually is for that.
Acuity vs Eventually
The simplest way to think about it is this:
| Use Acuity when… | Use Eventually when… |
|---|---|
| People are booking a time. | People are choosing what to attend. |
| The buyer is usually the attendee. | The buyer may not be the attendee. |
| There is one price and one attendance type. | There are multiple ticket types or ways to participate. |
| The client mainly needs booking, payment, confirmations, reminders, intake forms, and calendar management. | The client needs attendee information, waitlists, QR check-in, hybrid attendance, event-specific communication, or a branded event calendar. |
| The class still behaves like an appointment. | The class has become programming. |
Not because Acuity is bad.
Because the problem has changed.
The designer opportunity
For Squarespace designers, this creates a useful reason to revisit past clients.
You probably have clients who are already running classes, workshops, events, tastings, trainings, gatherings, or recurring programming. You may also have clients who are quietly managing all of that through Acuity, Squarespace events and service products, spreadsheets, inboxes, Zapier, custom CSS, and manual follow-up.
Eventually gives you a reason to go back and say:
“I think there’s a cleaner way to run this now.”
That is different from trying to sell a redesign. It is not about changing the look of the site. It is about helping the business carry something it is already doing.
If the client’s programming is working, the next question is whether the website can support it.
A simple decision test
Ask this:
Are people just booking a time, or are they choosing what to attend?
If they are just booking a time, Acuity may be enough.
If they are choosing what to attend, and the business needs to manage who is coming, what they bought, what they need to know, and how they show up, the client may have outgrown scheduling.
That is the moment to look at Eventually.
The client is no longer only managing availability.
They are running classes, gatherings, and events that the website now has to support.