Complete Guide to Setting Up Fair Booking Rules

Most of the friction in shared ownership doesn't come from people behaving badly. It comes from the suspicion that the calendar isn't fair. Someone notices that the same person always seems to have Saturday. Someone else feels like they have to book three weeks out just to get any time at all. Once that suspicion takes root, the rules (or the absence of rules) become the problem. The fix is almost always to write the rules down, in advance, in a way that everyone agreed to.

This is a guide to designing those rules without making the system more complicated than it needs to be.

The four kinds of booking rules worth knowing

Booking rules tend to fall into four families, and most working systems combine two or three of them.

The first family is slot ownership. Each member holds a fixed allowance of "prime slots" (weekends, holidays, peak periods), optionally in proportion to their shares. A slot is occupied while a booking is active or upcoming, and it frees up again once the trip is over, so the allowance recycles on its own and nobody can stockpile the calendar. This is the right tool when demand for prime times genuinely exceeds availability. It's extremely fair, and it's the cleanest way to prevent any one member from quietly hoovering up every Saturday for the season. The trade-off is that allowances need active management to set the right number, and there's a natural pressure to revisit them as the group changes.

The second is time-based limits: restrictions on how long a member can book at one time, or in total over a period. The classic shape is something like "maximum three consecutive days, maximum ten days a month." This is most useful for high-utilisation assets like aircraft and yachts, where every idle day is a real cost. It encourages efficient use, at the price of frustrating the member who actually does want to plan a longer trip.

The third is the advance booking window, meaning how far ahead a member can book at all. A typical setup is a thirty-day window, with ninety-day windows for designated peak periods, and the window is the same for every member: there are no VIP tiers who get to jump the queue. The benefit is structural: nobody can block out the whole calendar a year in advance. The cost is that members have to plan a bit further ahead than they're used to.

The fourth is sizing the slot allowance by ownership share. A 50% owner might hold twice as many prime slots as a 25% owner. This is the right answer when ownership is genuinely unequal, because it mirrors the real economics. The risk is that smaller owners can come to feel like second-class citizens if the gap is too large. Most groups that use it pair it with deliberately small differentials.

Designing your rule set, step by step

Start by asking the group the questions that actually matter rather than the ones that produce theoretical answers. What times are most in demand in your specific setup? Are there seasonal patterns? A sailing yacht is a different problem in February than in July. Do members typically want long trips or short ones? Is usage currently balanced, or has it drifted in one direction?

Then start small. A perfectly reasonable starting point for most groups is a seven-day minimum advance booking, a five-day maximum per booking, and a cap of two concurrent bookings per member. Three rules. Easy to remember, easy to enforce, and almost always enough on day one.

From there, add complexity only as patterns emerge. Define what counts as a peak period. Add slot allowances if they turn out to be needed. Agree a cancellation policy. Build a special-reservation mechanism for the occasional longer trip. Each new rule should solve a problem you've actually seen, not one you've imagined.

Configuring this in Kai is straightforward: open Group settings, go to the Booking Settings section, click "Create Rule Set", pick the asset (or apply group-wide), choose the rule types, set parameters, save, and communicate the change to members. Then come back every quarter and review: are the rules being followed, are members unable to book when they need to, is anyone systematically overusing, and is the administrative burden still proportional? Rules that worked twelve months ago may not be the rules you need today.

Three scenarios you'll probably recognise

The "weekend warrior" pattern: one member always seems to book weekends first. The cleanest fix is a weekend rule that caps each member at two active weekend bookings at a time, paired with a thirty-day advance window and a ceiling on simultaneous bookings. The member who likes weekends still gets weekends, and as soon as one weekend trip is over the slot frees up for the next. They just stop holding all of them at once.

Last-minute cancellations: members cancel just before their slot, leaving the asset idle when someone else could have used it. Agree a cancellation notice policy with the group up front, use the cap on active bookings to limit how many open bookings any one person can be sitting on, lean on Kai's automatic 24-hour reminders, and review cancelled bookings periodically for patterns. If one person is consistently the source, the problem is usually addressed by a conversation rather than a rule.

Holiday hoarding: a member tries to lock in every major holiday at the start of the year. The combination that handles this is defining your peak holiday windows as seasonal periods, capping advance-booking days so nobody can block the calendar a year out, layering the weekend rule or slot allowances on top of it, and routing extended stays through a separate special-reservation rule that requires earlier notice and gets distributed more deliberately.

A few things experience teaches you

Automate the enforcement, because manual enforcement always fails, quietly at first and then loudly. Use Kai's automated rule checks to prevent violations at booking time, send the reminders, and track slot usage in real time. Humans are bad at running these systems by themselves; software is good at it.

Build flexibility in. Start with fewer rules than you think you need, and add as you see actual patterns. Use special-reservation mechanisms for the genuine exceptions instead of trying to write a rule for every edge case. Group admins should be able to adjust as the group's needs change.

Document the policy, not just the rules. A short written policy that includes the rationale for each rule, examples of what a violation looks like, the dispute-resolution process, and the procedure for changing the rules saves more arguments than the rules themselves.

And when you introduce or change a rule, communicate clearly. Explain the why, not just the what. Give an example. Leave a feedback window before the change goes live. If it's a major change, phase it in. People accept rules they understood the reason for; they resent rules that landed on them with no warning.

A balanced sample to start from

This rule set works for a lot of groups out of the gate, with adjustments as you learn:

Base Rules:
  - Advance booking: 7 days minimum
  - Maximum booking: 5 consecutive days
  - Maximum active bookings: 2

Peak Period Rules:
  - Definition: Fridays-Sundays, seasonal peaks
  - Slot ownership: 2 prime slots per member
    (a slot is occupied while a booking is active or upcoming,
     and frees up once the trip is over)
  - Weekend rule: max 2 active weekend bookings at a time
  - Advance booking: 30 days, same window for everyone

Off-Peak Rules:
  - First-come, first-served
  - Maximum: 7 consecutive days
  - No slot limits

Special Reservations:
  - Each member: 1 per year
  - Duration: Up to 14 days
  - Requested: 90 days in advance

The right next move is to share this with your group, talk through which pieces fit your situation, set the simplest version up first, and then watch how it actually plays out for a few months before tuning. Fair scheduling rarely emerges from a clever ruleset on day one. It emerges from a simple ruleset, well-enforced, that the group has agreed on and is willing to revisit.

Need help getting your booking rules right? Contact support or book a demo to see how the system handles the heavy lifting.