Client-managed recurring appointments for Wix Bookings

Show and tell
, ,
1

One recurring Bookings gap I kept seeing is that site owners can create recurring appointments from the Booking Calendar, but clients still can’t create their own recurring appointment series.

I built Recurring Appointment Self Service to cover that client-side workflow.

Signed-in members can:

  • create their own recurring appointment series
  • view the series
  • reschedule recurring appointments
  • cancel the series
  • have availability checked before bookings are created

This app is focused specifically on client self-service. It does not automate attendance-based charging or replace Wix’s payment and Pricing Plan workflows.

I’m the developer of the app, and it’s now available on the Wix App Market:

https://www.wix.com/app-market/61af7b57-529f-4a14-9479-e06a392a015b

I’d be interested in feedback from Wix Bookings users running recurring lessons, coaching, appointments, or similar services.

2

The gap is real and Wix documents it twice, which is worth knowing when you pitch this.

Two official feature-request articles cover it. “Allowing Clients to Schedule Recurring Class Sessions and Appointments” states, verbatim, that it is not possible for your clients to schedule recurring class sessions or recurring appointments on desktop. “Allowing Clients to Book Multiple Recurring Appointments in a Single Checkout” covers the checkout half. Both carry the same status, collecting votes. The owner side meanwhile has worked from the Booking Calendar for years. So the asymmetry you describe is documented platform behaviour, not something people can configure their way out of.

One thing to pin down before anyone relies on it. That first article says not possible on desktop. The wording leaves mobile ambiguous and I have not found Wix clarifying it anywhere. Does your app behave identically in the Wix mobile app and in the member area on a phone, or is it desktop web only? That is the first question a coaching client will ask, and the docs do not answer it.

Two more from configuring Bookings for real businesses.

Availability is the hard part and you have named it, so I assume you have thought about it. The case that breaks naive implementations is a series booked across a staff availability change, or a blocked period added after the series already exists. Does the series survive that, and does anyone get told when it does not?

Payments. You say you do not replace Pricing Plans or the payment workflow. For recurring lessons the usual commercial shape is a plan or a package rather than per-session checkout. So what happens when a member holding a ten-session package creates a twelve-week series? Does it decrement the package, or is the series purely a scheduling layer sitting beside whatever they bought? Spelling that out on the listing would cut your support load, because people will assume it either way and half of them will assume wrong.

Useful area to build in. The native workaround everyone lands on is a multi-session course or class, which forces a fixed shared timetable and does not fit one to one coaching at all.

3

Thanks for the detailed feedback — you’re right that these edge cases need to be explicit before anyone relies on this for a real booking business.

The app’s purpose is to fill the client-side recurring-booking gap you described: signed-in members can create and manage their own series on a Wix Bookings service page, while the actual booking and payment flow remains with Wix.

Here’s what I can confirm from the current implementation and QA evidence:

  • Mobile: I have not yet verified the flow in the Wix mobile app or in the mobile member-area experience, so I can’t claim identical mobile support.
  • Availability changes after creation: availability is rechecked for each occurrence when a series is created, and again when a member explicitly changes a series. The app does not currently run a background monitor or automatically notify a member about a later staff-availability change or newly blocked period. I have not verified how Wix itself treats an already-created booking when those later changes are made.
  • Pricing Plans / packages: the app does not read or decrement Wix Pricing Plans, session-package, or package balances. For online-payment services it passes the bookings that passed the availability checks to Wix’s native Cart and Checkout. I have not verified whether Wix may apply an existing native plan or package entitlement automatically in a particular site configuration, so I don’t want to promise that behavior.

That distinction is important: the app is a client-side recurring scheduling layer, not a replacement for Wix’s native entitlement or payment rules. I’ll keep the listing explicit about these boundaries.

Thanks again for raising these practical questions.

4

Two of your three unknowns are answerable from Wix’s own docs, and one of the answers makes the availability limitation more serious than it looks.

Blocked time does not touch existing bookings. Wix’s Blocking Off Time article is explicit: blocking off hours does not override class or course sessions happening in that same slot, it does not affect existing appointments, and it only prevents clients from booking new appointments in that time frame.

So the failure mode is concrete. A member creates a twelve week series. The owner later blocks a week off for holiday. Wix keeps the occurrences sitting inside the blocked period, silently, because that is its documented behaviour. Your app does not monitor for it and Wix does not flag it. The owner finds out when someone turns up.

That is not a criticism of the design. It is the one thing I would put on the listing in plain language, because owners assume blocking time protects them and it does not. That assumption predates your app, and you will get blamed for it anyway.

Short of a background monitor, the cheap mitigation is a re-validation when the series detail view is opened, or a health check the member or owner can trigger. Not continuous, but it converts a silent failure into a visible one at the moment someone actually looks.

On packages you can go further than you have. Wix documents that clients can pay for group bookings using purchased packages on both desktop and the member apps, and that each participant consumes one session. What is not documented is the same mechanic for individual appointment checkout. Since you hand off to the native Cart and Checkout, the likely answer is that Wix applies the entitlement itself and your app never needs to know about it. That is worth ten minutes to settle rather than hedge: create a service, give a test member a package, create a series through your app, and watch whether checkout charges or decrements. A stated behaviour is worth more on a listing than a caveat.

Pricing Plans I could not verify either way from the docs, so your caution there is correct.

The mobile gap is the one I would close first. Recurring lessons and coaching get booked from phones more than desktops, and an unverified answer there is the objection that stalls the sale.

5

Thanks again for flagging this. You were right about the blocked-time edge case.

I’ve now updated the app so future occurrences are revalidated when a recurring series is opened. If a later staff block conflicts with an existing occurrence, that occurrence is shown as Attention instead of failing silently.

I also added an Unverified state for cases where calendar data can’t be read, so the app never treats an API failure as “OK”.

I verified the full flow on a Wix Bookings test site:

  • existing recurring bookings remain intact
  • adding a staff block flags only the affected occurrence
  • the booking itself is not falsely detected as a conflict
  • removing the block returns the series to OK
  • reopening the series triggers the check again

Mobile support and Pricing Plans/package behavior are still separate items I haven’t fully verified yet, so I’m not making claims about those yet.

Thanks again — this was a useful edge case to catch before wider usage.

6

Good. The Unverified state is the part most people would have skipped, and it is the one that matters most. An app that reports OK when it cannot read the calendar is worse than one that reports nothing at all.

One gap left in what you have described. Revalidation on open means the member sees Attention when the member opens the series. The person who needs to know is the owner, and the owner is not opening member series views. So the original failure mode survives in a narrower form: block gets added, member never opens the series, owner finds out when nobody turns up. Whatever the answer is, a dashboard list of series carrying conflicts, a digest, a flag surfaced on the Booking Calendar, it needs to reach the owner without depending on a member opening a page. Roadmap item rather than a blocker on what you have just shipped.

The other one your test matrix does not mention is daylight saving. A weekly series crossing a DST boundary is where recurring booking implementations usually break. Worth an explicit test on a site in a timezone that observes it, because whether an occurrence holds local time or absolute time is a decision better made deliberately than discovered from a support ticket.

Neither of those should hold up the release.

7

Thanks — we implemented both points you raised.

The app now surfaces recurring-series health directly in the Wix Bookings Booking List for the site owner, so detecting a new calendar conflict no longer depends on the member reopening the series.

We also added explicit DST-boundary coverage and verified that weekly occurrences keep their intended local time across DST changes.

The owner-side states now distinguish between clear, attention required, and unable to verify, rather than reporting a false OK when calendar data cannot be fully read.

This is now released in the public version. Your feedback was very useful in tightening the failure handling.