Booking Lifecycle & 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, Adhyayans, Utsavs, 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 Adhyayan and Utsav 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, an Adhyayan, an Utsav, 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 an Adhyayan booking 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 Utsav booking as an extra. The backend applies this check to both member and guest booking flows.
2. Booking for yourself, a Mumukshu, or a guest¶
A member can make a booking in one of three ways:
- For themselves.
- For a Mumukshu, an existing, recognized person who already has a record in the system. A member looks the person up by a 10-digit phone number. An unknown number is refused as not found. A known number must belong to a Mumukshu, a Permanent Resident, or a Seva Kutir member. Any other known number, including a guest's, is refused with the message that the person is not a Mumukshu (backend). The system won't let someone create a "Mumukshu" from scratch through this path, only find one who's already known to it. When a member books for themselves, the member app sends the booking through this same path, with the member as the person booked for (member app).
- For a Guest, someone who may not have a record yet. The member types the guest's 10-digit phone number. If the number belongs to a known guest, the member app fills in that guest's details. If the number is unknown, the member enters the new guest's details, and a new guest record linked to the member is created before the booking (backend). If the number belongs to someone who is not a guest, the backend refuses it. A newly created guest receives a WhatsApp message with their name and new card number (backend). The backend can also list a member's 10 most recently updated guests, but the current member app does not use that list.
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 member 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.
The person who books pays. Every charge for a booking made for someone else is recorded against the booker. The booker sees it in Pending Payments, pays it, and receives any credit when it is cancelled. The country rule for online payment in §4 also follows the booker, not the attendee (backend).
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 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. If any part fails a check, nothing is created (backend). What happens next depends on the country registered for the person who books:
- Booker registered in India, with an amount due: a payment order for the full amount is created at once (backend). The review screen offers Pay Now, which opens the checkout, and Pay Later. Both buttons create the booking and the payment order in the same way. Pay Later only skips the checkout, and the member must then pay within 24 hours from Pending Payments (member app and backend).
- Booker registered outside India: no payment order is created. Each charge is recorded as payable in cash at the Research Centre, and it never expires (backend). See Payments, Credits & Reconciliation for paying online later.
After the booking commits, the system attempts WhatsApp and email messages for the attendee and, when different, the booker (see §11). 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 credit, the booking skips straight to confirmed, there's no separate online payment step needed in that case. A staff move of a waitlisted Adhyayan booking that credit fully covers stays payment pending (see Payments, Credits & Reconciliation).
The 24-hour rule. If an online payment by a member registered in India stays pending or failed for more than 24 hours, the system cancels the related booking. Bookings of members registered outside India are not auto-cancelled (see Status Vocabulary & Automatic Checks). Just before it cancels, the system checks the booking again; a booking that was paid or cancelled in the meantime is left alone. The effect on a waiting booking depends on the booking type. This is separate from any staff review of travel bookings (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 booking 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 an Utsav boundary.
- Adhyayans
- Utsavs
- Travel, although the current member create path starts bookings as awaiting confirmation.
Food bookings don't use a waitlist, a food order either goes through or it doesn't. A flat booking goes to waiting only when the person staying, unless a Permanent Resident, is over the 9-night limit within a 30-day window; it is not charged while waiting (backend, see Stay: Rooms & Flats).
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 only when the cancelled booking held one; cancelling a waitlisted booking frees no seat. Utsav cancellation does not promote a waiting booking. Room promotion at an Utsav boundary is manual. Travel has a waiting status and promotion helper, but member travel creation currently creates "awaiting confirmation", not a queue position.
Seats are counted one request at a time. For Adhyayans and Utsavs, the system takes or returns a seat under a lock (backend). When several people try for the last seat at once, only one is confirmed and the rest go to the waitlist. Staff cannot move a waiting Adhyayan booking forward when the Adhyayan is full.
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 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.
An Adhyayan or Utsav booking that is already cancelled cannot be cancelled again. A repeated cancel, such as a double tap, is rejected and frees no second seat (backend).
Staff can cancel or adjust bookings through their permitted staff flows. Travel and Utsav staff cancellations let staff choose whether to issue credit. A staff cancellation of an Adhyayan booking offers no choice and always returns the full price as credit (backend and staff panel).
Staff cancellation of a room stay. Super admins, office admins, and room admins can cancel a room booking from the stay reports in the staff panel, one booking at a time or several in bulk. A booking that is checked in, checked out, or already cancelled cannot be cancelled. A bulk cancel skips those bookings and tells staff how many it skipped (staff panel). The booking becomes admin cancelled. A paid stay's full price becomes stay credit, and an unpaid stay's applied credit is returned (backend). The attendee and, when different, the booker get a push notification that the stay was cancelled by admin, and the system sends a stay WhatsApp update. This shared cancel action covers room stays only. Flat bookings use a separate staff action (see Stay: Rooms & Flats).
8. Where a member starts and tracks bookings (member app)¶
Only a fully onboarded member reaches the screens below (see Accounts, Identity & Authentication).
- Bottom tabs. Home, Book Now, a button that opens the member's QR code, Bookings, and Profile.
- Home. Greets the member by first name with a random quote. Quick access opens WiFi, the menu, maintenance, contact information, support, and Pending Payments. It also links to Satshrut and the organisation's social pages.
- Book Now. The member chooses Adhyayan (selected first), stay, food, travel, or Utsav. Flat appears only for a member who owns a flat.
- Bookings. Lists bookings by type: Adhyayan, stay, food, travel, and Utsav, with each type's cancel action. There is no separate flat choice on this tab.
9. Adding extras in the member app¶
The member app decides which extras a member can attach. The backend then applies its own checks (see §1 and §10).
| Who the booking is for | Main booking types | Extras offered |
|---|---|---|
| Yourself | Stay, Adhyayan, travel, Utsav | Stay (unless the main booking is a stay), food, Adhyayan (unless the main booking is an Adhyayan or Utsav), travel (unless the main booking is travel; never for a member with guest status) |
| Guests | Stay, flat, Adhyayan, Utsav | Stay (unless the main booking is a stay or flat), food, Adhyayan (unless the main booking is an Adhyayan or Utsav). Travel is never offered for guests |
| Mumukshus | Stay, flat, Adhyayan, travel, Utsav | Stay (unless the main booking is a stay or flat), food, Adhyayan (unless the main booking is an Adhyayan or Utsav), travel (unless the main booking is travel). Extras can include only people already in the main booking |
- An Adhyayan or Utsav away from the Research Centre goes straight to review. No extras are offered.
- Utsav reminder. On an Utsav booking, the member app asks the member to book stay, food, and travel for an early arrival or late departure through the extras.
- Form checks. Every extra the member opens must be filled in completely, or the member app asks the member to fill in all fields. A stay extra for guests or Mumukshus needs a room type, a floor choice, and at least one person. A food extra needs at least one meal, a spice choice, and at least one person. A travel extra needs a date, pickup and drop points, and luggage. Exactly one end of the journey must be the Research Centre. A pickup or drop marked "other" needs a note in the special request, and a full-car booking needs the number of people.
10. Review, confirm, and the result screen¶
The review screen asks the backend for a preview every time it opens (§3). If a check fails, the member sees the backend's message, and closing it returns them to the form (member app).
- The screen lists each charge by type. Applied credit is shown with the original price struck through, then the total credit and the amount due. Guest and Mumukshu reviews also show a per-person breakdown of stay and flat charges.
- When an amount is due, the member sees Pay Now and Pay Later. Pay Later first shows a notice: the booking is temporary, payment is due within 24 hours, and the booking is cancelled automatically after that. When nothing is due, the member sees Confirm Booking.
- Result screens. "Request Received" appears when no payment was taken. "Booking Confirmed" appears when the checkout finishes. "Payment Failed" appears when the checkout fails or is closed; it offers payment tips, contact support, and Try Again, which opens Pending Payments.
Checks the backend applies at preview and booking:
- The same Utsav cannot be chosen twice for the same person in one request. The booking step also refuses a person who already holds a booking for that Utsav.
- A flat cannot be an extra and cannot carry a stay or Utsav extra (§1).
- Guest flat booking. The booker must own a flat. A checkout date and at least one guest are required. A guest who already has a flat booking on those dates is refused. A guest over the non-resident stay limit (see Stay: Rooms & Flats) is waitlisted with no charge. The flat owner stays free; anyone else pays the non-AC room rate per night, less any stay credit.
- Travel for Mumukshus. The date cannot be in the past, one end must be the Research Centre, and a person who already has travel booked that date is refused. Travel costs nothing at booking and starts as awaiting confirmation (see Travel).
- Meals are charged only for a person with guest status. Meals for anyone else cost nothing (see Food).
11. Messages sent for a booking¶
| Event | Message | Recipient | Key content |
|---|---|---|---|
| Booking created | One email, "Bookings created" | The booker | Every booking in the request, with each person's name and status. A booker registered in India is told that payment is due within 24 hours. A booker registered outside India is told to pay at the Research Centre on arrival |
| Booking created for someone else | A separate email | Each other attendee who has an email address | That person's bookings and status |
| Booking created | WhatsApp, one per booking type | The attendee and, when different, the booker, whose message names the person booked for | Type-specific booking details, including meals |
| Staff create a stay or flat booking for a member (staff panel) | Email, "Bookings confirmed" | The member | That stay or flat booking with its current status (see Stay: Rooms & Flats) |
| Payment confirmed | Email, "Bookings confirmed" | Each attendee, or the booker when the attendee has no email address | The confirmed bookings |
| Payment confirmed | WhatsApp status update, for stay, flat, travel, and Utsav | The attendee, and the booker for some changes | The new status. Adhyayan and food payments send no WhatsApp |
| A booking email addressed to one person that includes travel (production only) | A copy of the email | The travel team's mailbox | The travel details and the person's name |
What the booking emails contain (backend). Each email lists bookings by type. Stay entries show the dates and status. Flat entries also show the flat number. Adhyayan entries show the speaker and dates, plus a note that the Adhyayan committee may cancel a booking within 7 days if the person does not meet the Adhyayan criteria. Utsav entries show the package. Travel entries show the pickup and drop points, plus the standard pickup locations and times. Each email ends with a plain-language meaning of every status and the support phone numbers. Food bookings are not listed in the email.
The 24-hour payment check sends its own cancellation email (see Status Vocabulary & Automatic Checks).
Known limitations today¶
- A member registered outside India who taps Pay Now when booking for themselves sees an error. The booking was already created and waits for cash payment, but the review screen expects an online payment order that the backend does not create (member app). The guest and Mumukshu reviews show "Request Received" instead.
- The member app does not say when a booking is waitlisted. The backend reports how many bookings went to the waitlist, but the member app shows the same result screen as for any other booking.
- Booking emails leave out food. A request that contains only meals produces an email with no booking details.
- The travel team's copy can miss the booker's own travel. When a member books travel for themselves and others in one request, the copy covers only the other people (backend).
- An older flat booking path for guests still accepts bookings. The current member app no longer uses it.
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 Adhyayan/Utsav seats, all created through the same booking flow described here. Money mechanics (payment, credit, cancellation credit, the 24-hour unpaid-booking rule) are expanded in Payments, Credits & Reconciliation, and the full status vocabulary in Status Vocabulary & Automatic Checks. Who can be booked for, members, Mumukshus, and Guests, is covered in Accounts, Identity & Authentication.