Managing coworking memberships without losing track of what people already paid for

Two things that are easy to confuse

A membership is an entitlement: a standing agreement that grants access, and often an allowance, over a period. A booking is a consumption of that entitlement, or a separate purchase when nothing covers it.

Systems that model membership as a discount on bookings work for exactly as long as every plan is a simple percentage off. They break at the first plan that includes eight meeting-room hours a month, because "included" is not a discount — it is a balance that depletes, and a booking has to know whether it is drawing on that balance or being sold outright.

The practical consequence: a booking should record which membership it was made against. Without that link you cannot answer, later, whether a given reservation was included or invoiced, and you certainly cannot rebuild a member's remaining allowance.

Decide what an allowance does at the boundary

Every plan with included hours needs an explicit answer to four questions, and the answers are policy, not engineering:

• What happens to unused hours at the end of the period — do they expire or roll over?
• What happens when a member exceeds the allowance — refuse the booking, or allow it and bill the excess?
• Does a cancelled booking return its hours, and does that depend on how late it was cancelled?
• When a member joins mid-month, do they get the full allowance or a proportion?

These look like small details. They are the ones that generate every awkward conversation at invoicing time, and they are much cheaper to decide before the first member signs up than to reconstruct afterwards from an argument.

The one worth thinking hardest about is the second. Refusing the booking protects your capacity but sends a paying member away; allowing and billing keeps them working but produces an invoice they did not expect. Whichever you choose, the member has to be told at the moment of booking, not at the end of the month.

Recurring bookings are a schedule, not a bulk insert

"Every Tuesday, 09:00 to 13:00, for the next six months" can be implemented as twenty-six rows created up front. It is the obvious approach and it causes three specific problems.

First, availability: each of those occurrences must survive the same conflict checks as a single booking, and some of them will not. A recurring series that silently skips the weeks it could not book is worse than one that tells you at creation time which dates are unavailable.

Second, editing: when the member wants to move the time, you need to know whether they mean this occurrence or the whole series. If the rows are indistinguishable from twenty-six unrelated bookings, you cannot offer that choice.

Third, the horizon: a series with no end has to be extended by something, and that something is a job that can silently stop running.

The point is not that pre-generating occurrences is wrong — it makes the calendar and availability queries much simpler. It is that the series has to remain a first-class thing the occurrences belong to.

Renewal is a deadline, so automate it as one

Memberships expire, and nobody notices until access stops working or a month of revenue quietly disappears. This is a scheduled condition — it becomes true with the passage of time rather than because anything happened — which makes it exactly the kind of thing a rule should watch.

Boris exposes membership expiry as an automation trigger for that reason. The valuable part is not the email; it is that the reminder fires from the data instead of from someone's memory, at a point where there is still time to have the renewal conversation.

What to get right first

• Link every booking to the membership it consumed, or to none deliberately.
• Write down the roll-over, overage, cancellation and proration rules before launch.
• Tell members at booking time when they are about to exceed an allowance.
• Keep recurring series as series, not as loose copies.
• Let expiry be a scheduled trigger, not a task someone remembers.