Tentative vs confirmed bookings

Most booking systems have one kind of booking: a commitment that blocks everyone else. Syndik8 has two. A tentative booking is a non-binding hold — pencilled in. A confirmed booking is a commitment — the asset is yours for that slot. Tentative bookings can overlap freely with each other and with confirmed bookings; only confirmed bookings block the calendar. This page explains why.

How syndicate members actually plan

A member thinking about the weekend does not usually jump straight to a committed booking. The real sequence is more like: “I might want Saturday afternoon, if the weather is good and if the kids don’t need collecting.” They would like to register that interest in the group without having to commit, and without having to remember to come back and book it later.

The alternative — first-through-the-door with hard bookings only — rewards speed over actual intent. Members book early “just in case” and then cancel the ones they don’t use, which makes the calendar look busier than it is and makes future slots look less available than they are.

What the tentative slot allows

A pencilled-in slot says two things. It tells the rest of the syndicate that this time is being considered, so another member weighing the same afternoon knows they are not alone in thinking about it. And it tells the member themselves that they have a candidate plan — one click away from becoming real.

Because tentatives do not block anyone, two or three members can each pencil in the same Saturday afternoon. Whichever of them commits first takes the slot; the rest learn instantly that the slot has gone. The calendar renders tentatives with a diagonal-hatching pattern, visually distinct from the solid fill of a confirmed booking. See Tentative bookings.

The overlap is the point

The first time a member sees two tentatives overlapping on the calendar they sometimes wonder whether the system is broken. It isn’t — the overlap is the feature. Overlapping tentatives surface demand. If three members have pencilled in the bank holiday Monday, the group has information it would not otherwise have: that slot is contested, and whoever confirms first wins.

Under a hard-bookings-only model the same demand is invisible until two members try to book at the same moment and one loses. Making the invisible visible changes the social dynamic — the group surfaces conflicts early, when they can still be resolved by a conversation.

Confirmation promotes, rather than replaces

When a member is ready to commit, they confirm their existing tentative. The status changes in place from tentative to confirmed (or to pending, if the syndicate requires admin approval — see Booking statuses). The same row, the same history, the same notes — just promoted. Nothing is copied, deleted, or re-created. “Member X showed interest on Tuesday, then confirmed on Thursday” is one record, not two.

What prevents the obvious abuse

The natural worry: what stops a member pencilling in every weekend for the next six months just in case?

Tentative bookings are visible to the whole syndicate and show the author’s name. A member who pencils in more than they ever use is visibly doing so. The fairness dashboard does not count tentatives as usage; their effect on the group ledger is zero.

Technically, the overlap allowance only exists for tentatives. The moment any of them is confirmed, it collides with confirmed bookings under the usual database constraint. See Conflict detection. Pencilling is cheap; committing is the point at which the asset actually becomes reserved.

Why there is no auto-confirmation

Syndik8 does not promote tentatives to confirmed on a timer. Left alone, a tentative stays tentative. Auto-confirmation would reintroduce the “book early just in case” problem the tentative model is designed to avoid. A member who has not come back to confirm by the time the slot arrives loses it — another member can confirm over the top, or the slot passes unused. The explicit confirmation is the point at which intention meets commitment.