Booking Lifecycle & the Booking Engine¶

Part of the Aashray Business Logic. Related: Stay, Rooms & Flats, Food, Travel, Adhyayan & Utsav, Payments, Credits & Reconciliation.

This is the connective file that ties the booking types together. Stays, meals, study sessions (Adhyayan), festivals (Utsav), and travel use a main booking with optional extras, but each type has its own checks and statuses. Per-type details such as room assignment, meal cutoffs, bus groups, and event seats live in the linked files. This file explains the shared booking actions.

1. One main booking, plus optional extras¶

Whatever a member is booking, a stay, a meal, a study session, a festival, or travel, one of those is the main booking. On the same screen, before finishing, the member can attach one or more extras: for example, a stay with a meal plan and a travel leg attached, or a study-session registration with a meal add-on. Everything attached is submitted together, in one request, and billed as a single order.

A flat booking is the one exception. A flat cannot be an extra. A flat also cannot include a room or festival booking as an extra. The backend applies this check to both member and guest booking flows.

2. Booking for yourself, a fellow seeker, or a guest¶

A member can make a booking in one of three ways:

For themselves.
For a Mumukshu, an existing, recognized fellow seeker who already has a record in the system. A member looks the person up by phone number; the system won't let someone create a "Mumukshu" from scratch through this path, only find one who's already known to it.
For a Guest, someone who may not have a record yet. If the phone number isn't already known as a guest, a new guest record is created on the spot as part of the booking.

Whichever way a booking is made, it always belongs to one specific person, whoever is actually staying, eating, attending, or travelling. If someone else made the booking for them, that's also recorded, so the app can show "Booked For: {name}" and so both people, the attendee and whoever booked it for them, get notified about what's happening with it.

3. Checking availability and cost before committing¶

Before a booking is actually created, the member sees a preview: is what they're asking for available, and what will it cost? This preview also shows what happens if the member has store credit, the credit is shown as already applied to the cost, but nothing is actually spent yet. If something isn't available (the dates are blocked, a slot is already taken, there's no room left), the member sees a clear message and can change their request rather than being charged for something that can't be given to them.

4. Creating the booking¶

Once the member confirms, everything in the main booking and its extras is created together as one unit. What happens next depends on where the member is paying from:

Members in India get a payment order generated immediately, so they can pay online right away (or shortly after, since payment can be deferred, see below).
Members outside India aren't offered online payment for this; instead their charge is recorded as a cash amount payable on-site.

After the booking commits, the system attempts WhatsApp and email messages for the attendee and, when different, the person who booked it. The create path does not send a push notification. A notification failure does not undo the booking.

5. From "just booked" to "confirmed", the life-cycle in plain words¶

A booking generally moves through a small number of plain-English states:

Waiting, for stays, this can mean waiting for a room number to be assigned; for other types, it can mean waiting for a spot to open up if everything is full (see §6).
Awaiting payment, created, but payment hasn't gone through yet (or, for a stay, hasn't been fully applied).
Confirmed, payment has gone through (or been fully covered by credit) and, where relevant, staff have signed off. For stays, "confirmed" continues on into an actual check-in and, eventually, a check-out.
Cancelled, either the member cancelled it themselves, or it was cancelled automatically (see the 24-hour rule, below), or a staff member cancelled it.

If a member pays for the whole thing using existing store credit, the booking skips straight to confirmed, there's no separate online payment step needed in that case.

The 24-hour rule. If an online payment stays pending for more than 24 hours, the system cancels the related booking. The effect on a waiting request depends on the booking type. This is separate from any staff review of travel requests (see Travel).

6. Waitlists and automatically opening a freed-up seat¶

When a booking cannot receive a confirmed place, the system can place a new request in waiting status for these booking types:

Stays, when the stay exceeds the rolling limit, has no matching room, or is a single night on a festival boundary.
Study sessions (adhyayan)
Festivals (utsav)
Travel, although the current member create path starts requests as awaiting confirmation.

Food and flat bookings don't use a waitlist, a food order or flat either goes through or it doesn't.

The idea is that when a confirmed booking is cancelled, including an automatic cancellation for non-payment, the next person on the waitlist should be moved up and notified that a spot has opened.

The current paths differ by type. Adhyayan cancellation promotes the oldest waiting booking. Utsav cancellation opens a seat but does not promote a waiting booking. Room promotion at a festival boundary is manual. Travel has a waiting status and promotion helper, but member travel creation currently creates awaiting confirmation, not a queue position.

7. Cancelling a booking¶

A member can cancel their own booking while it is waiting, awaiting confirmation, awaiting payment, proceed for payment, or confirmed. When they do, any money already paid follows the booking type's cancellation rule. Some types create store credit and others do not. See Payments, Credits & Reconciliation for the full picture. The attendee and, when different, the person who made the booking can receive a cancellation notice.

Staff can cancel or adjust bookings through their permitted staff flows. Staff can choose whether to issue credit when a staff cancellation supports that choice.

How this connects to other domains¶

This file is the spine; the per-type files hang off it. Stay, Rooms & Flats covers room assignment and check-in/out. Food, Travel, and Adhyayan & Utsav cover meal cutoffs, travel/bus arrangements, and study-session/festival seats, all created through the same booking flow described here. Money mechanics (payment, credit, cancellation refunds, the 24-hour unpaid-booking rule) are expanded in Payments, Credits & Reconciliation, and the full status vocabulary in Status & Cron. Who can be booked for, members, Mumukshus, and Guests, is covered in Accounts, Identity & Auth.