Raj Pravas (Travel)¶

Part of the Aashray Business Logic. Related: Booking Lifecycle, Adhyayan & Utsav, Payments, Pricing & Credits, Accounts, Identity & Auth. For implementation detail — exact routes, database structure, and known code-level defects — see the companion Technical Reference — Travel.

Raj Pravas is car/bus transport between the Research Centre and Mumbai-area points (city locations, airports, and railway stations). It's fundamentally a staff-run logistics operation, not a self-service booking: a member's request is just the trigger that feeds into a planning process staff run — deciding whether a vehicle is worth sending, working out its route, and only then locking a request in. A request is always a single one-way leg, either to or from the Research Centre, on one date.

Who can request travel, and what a request must include¶

A member can request travel for themselves, for one or more Mumukshus they're acting on behalf of, or for a Guest — the travel flow offers the same Self / Mumukshu / Guest choice as stays, food, and the rest. (The one exception: an account that is itself a guest can only book travel for itself.)
Exactly one end of the trip must be the Research Centre. Either the pickup or the drop is the Research Centre — never both, never neither.
One request per direction per day. A person can hold at most one "to Research Centre" request and one "from Research Centre" request for the same date — they can't double-book the same direction.
A trip can be one-way or a round trip. A round trip is booked as a single linked booking: the member picks an onward date and a return date, and the return leg runs the reverse of the onward route on the return date. (The two legs share a common trip grouping, so they aren't two unrelated bookings.)
A request is either "Regular" or "Full Car." Full Car requires stating how many people are travelling; Regular guarantees no more than 1 seat per booking. Choosing "Full Car" is meant to mean the trip is fulfilled using one of the centre's own cars rather than the shared/hired fleet — today this is only a label on the request, with nothing connecting it to which vehicle staff actually assign (see "Known limitations today").
Luggage must be declared (at least one option, including "none").
An arrival time is required when travelling to or from an airport or railway station, so the trip can be timed against a flight or train.
If either end of the trip is "Other" (not one of the standard locations), the member must describe it in a comment.
The list of valid pickup/drop points changes during a festival. During an Utsav, an event-specific set of locations is offered instead of the everyday list (both lists below).
"Leaving post adhyayan?" is a yes/no question shown only when the trip starts from the Research Centre — meant to capture whether someone is departing right after finishing a study session. Today the member answers this themselves; it isn't checked against their actual study-session registration (see Planned changes, below).
Requesting travel costs nothing up front. No charge is created when a member submits a request; a staff member sets the fare only once they've decided to actually run the trip (see "Deciding whether — and how — to run a trip," below).
Travel can also be added on top of another booking (a stay, a meal, a study session, or a festival registration) rather than requested on its own.

Valid pickup/drop locations¶

On ordinary days: Research Centre, Dadar (Swaminarayan Temple), Amar Mahal, Airoli, Vile Parle (Sahara Star), Airport Terminal 1, Airport Terminal 2, Bandra Terminus railway station, LTT–Kurla Terminus railway station, CSMT railway station, Mumbai Central railway station, Navi Mumbai Airport, or "Other" (with a description).

During a festival (Utsav): Research Centre, Dadar (Pritam Da Dhaba), Amar Mahal, Borivali (Indraprasth Shopping Centre), Mulund (Sarvoday Nagar), Vile Parle (Sahara Star), Airport Terminal 1, Airport Terminal 2, Bandra Terminus railway station, Kurla Terminus railway station, CSMT railway station, Mumbai Central railway station, Navi Mumbai Airport, or "Other."

Deciding whether — and how — to run a trip¶

This is the actual heart of Raj Pravas: nothing a member requests turns into a ride until staff decide to run one. (Everything in this section — the fleet, the threshold, the route-drafting process, the observed route patterns — comes directly from the SRATRC travel team's own practice, not from anything the system enforces on its own; see "Known limitations today.")

The fleet. The centre's baseline fleet is 1 owned car. Beyond that, staff hire additional vehicles sized to demand — a 20-seater or a 35-seater — chosen by judgment rather than a fixed formula. These larger hired vehicles are not reserved for festivals or events: staff will put a 20- or 35-seater on the road on ordinary days too, whenever that day's bookings justify it. During a typical study session, staff usually see a maximum of 20–25 requests in total. The system itself doesn't distinguish a car from a bus at all — whichever it is, staff plan and assign it through the exact same process (a name, a stop sequence, a capacity number); which specific vehicle a trip ends up on is entirely staff's own bookkeeping, invisible to the system.

The threshold. Staff want at least 2 requests in before committing to send a vehicle at all, and in practice wait for a total of 3 before locking it in, since a request doesn't always turn into an actual traveler. This minimum is counted across both directions of that date combined — every request to and from the Research Centre that day taken together — not per direction, and not per specific pickup point.

Drafting the route and judging the threshold happen together, not one after the other. Staff sketch a stop sequence and rough timings for a prospective vehicle, and as they do, they can see how many current requests would actually fit that route — so the "is this worth it" judgement plays out while the route is being drafted, not as a separate decision made first. Once staff commit to a stop sequence, every current request whose pickup and drop both fit it, in order, is normally pulled onto the vehicle in that same action — finalizing the route and assigning matching requests aren't two separate steps. The vehicle's capacity is a soft limit here: if committing would go over it, staff see that and can still choose to proceed.

There's more than one way requests end up on a vehicle, not a single fixed method: automatically, by matching everyone whose route fits (the default); one at a time, by hand; in a batch, by hand; or — for a large event — by uploading a prepared spreadsheet that lays out several vehicles and their passenger assignments all at once. Naming a traveler as a vehicle's coordinator (see "Running the trip," below) can happen at the same time as this assignment, or separately, whenever staff get to it.

Three pickup sequences recur, based on where demand tends to come from — a pattern staff have learned from experience, not a rule anyone has encoded anywhere:

Dadar → Amar Mahal → Airoli → Research Centre
Borivali → Vile Parle → Amar Mahal → Research Centre
Airoli → Research Centre (run on its own when Airoli has enough demand by itself)

Looping through Airoli after Amar Mahal (route 1) adds meaningfully to the trip's length, so staff prefer to skip it unless there are genuinely few people who can't otherwise reach Amar Mahal — those travelers are asked to make their own way to Amar Mahal and join there instead. When Airoli has enough demand on its own, staff run it as its own direct trip (route 3) rather than folding it into route 1. Every time, staff work out the right stop sequence from scratch based on where that day's actual travelers are — this is a natural candidate for the system to eventually learn and suggest on its own, rather than staff reconstructing it from memory each time.

If the threshold isn't met by roughly a day before travel, staff manually cancel the request(s) and tell the member to arrange their own way there, or book a Full Car themselves. Nothing about this is automatic today.

Confirmation and payment¶

Staff only confirm a request once they've already gone through the decision above and committed to running a trip for that date and direction. Confirmed means confirmed: once a member's request reaches that state, a vehicle is coming for them — it isn't a provisional status that might still fall through. Confirmation is the result of deciding to send a vehicle, not something that happens beforehand — staff aim to reach this point, and let the member know, at least 24 hours before travel. (This happens to share a number with a separate, unrelated 24-hour rule that automatically cancels a booking if payment isn't completed in time — that one is about payment, this one is about travel-arrangement confirmation, and the two shouldn't be confused.)

There's no automatic waitlisting today — every new request simply waits for that staff decision (see "Known limitations today," below). Once a fare is set (or the trip is left free), payment follows the same rules as other bookings (see Payments, Pricing & Credits) — except for what happens if it's cancelled (see Cancellation, below).

Running the trip: the coordinator role¶

The concrete details of a trip — which vehicle, its stops, and (when reliably available) a pickup time — are filled in as staff assemble it (see "Deciding whether — and how — to run a trip," above). The member sees those specifics once that's done, but by the time a request is confirmed, whether they're getting a vehicle at all is already settled.

For each vehicle, staff may designate one traveler as its coordinator — this role exists for buses (the larger, hired vehicles), not for the owned car, which is small enough that no one needs to manage a roster on board. A coordinator logs in with a one-time code sent to their phone via WhatsApp, and from there they can see everyone assigned to their vehicle (names, pickup/drop points, luggage, any notes) and mark each person as boarded or not. That's the full extent of what a coordinator can do — they cannot change the route, the vehicle's capacity, anyone's fare, or a booking's status. They're not staff, and they don't have a staff account.

Today there is one coordinator per vehicle. A planned change is to have a coordinator per stop rather than a single one for the whole bus — so each pickup point along the route has its own person managing boarding there. This isn't built yet (see Planned changes).

Cancellation & changes¶

A member can cancel their own request while it's awaiting confirmation, confirmed, waiting on payment, or (nominally) on a waitlist.
Cancelling a travel booking does not automatically refund or credit any payment already made. If the member had already paid, that payment simply stays as it was. Issuing a credit is a separate decision a staff member makes when they review the cancellation — it's not something that happens on its own. (This is different from some other booking types, like stays, where cancelling a paid booking credits the member automatically — see Payments, Pricing & Credits.)
The traveler is notified by WhatsApp, email, and an in-app notification; if the booking was made on someone's behalf, that person is notified too.
Staff can also cancel a booking, with or without issuing a credit.

Planned changes¶

Four changes are planned. (Two items previously listed here — guest travel booking and a genuine linked round-trip option — have since been built and are now live in both the app and the backend; they are described in "Who can request travel," above, and are no longer planned work.)

A coordinator per stop, instead of one per vehicle. Today a bus has a single coordinator managing boarding for the whole vehicle. The plan is to designate a coordinator at each stop along the route, so boarding is managed locally at every pickup point rather than by one person for the entire trip. Not built yet.
A WhatsApp reminder for festival travel. Members answer a yes/no question when registering for a festival about whether they're arriving by their own car — but answering that question is not the same as actually booking travel, and people often forget the second step. The plan is to remind, by WhatsApp, anyone who said they need travel but hasn't actually booked it — and separately, to flag when one member of a family has booked travel for the festival while another hasn't, which is usually an oversight. Neither exists today, and the second part needs a way to recognize which members belong to the same family — something the system doesn't track at all yet.
A reliable "time to leave" shown to the traveler. Once staff set a departure time for a trip, members should be able to see it clearly and dependably in the app. A version of this exists today but doesn't always work reliably.
Authoritative visibility into whether a traveler is registered for a study session, replacing the current self-reported answer. Today the "leaving post adhyayan?" question is something the member answers themselves. The plan is to check this against the member's actual study-session registration instead — arrivals need to land before a session starts, departures need to wait until it ends — and show staff that directly rather than relying on a manual answer.

Known limitations today¶

A few of the rules described above don't fully hold in practice yet:

Seat promotion on cancellation doesn't currently trigger. The system is designed so that if someone cancels, a waiting traveler in the same direction should automatically move up — but nothing currently puts a booking into a waiting state in the first place, so this never fires.
There's no dedicated way to record "cancelled because not enough people signed up" as a distinct reason, separate from any other cancellation.
A "Full Car" request doesn't guarantee — or even influence — getting the centre's own car. It's recorded as a label on the request, but staff assign every request to a vehicle the same way regardless of this label, and the system has no concept of "car" separate from any other vehicle. Whether a Full Car request actually lands on the owned car depends entirely on the staff member assigning it remembering to do so.
Nothing stops a coordinator from being set on what's meant to be a car. The coordinator role is only meant to exist for buses, but because the system doesn't distinguish a car from a bus at all, it has no way to prevent — or even notice — a coordinator being assigned to the owned car.

Neither of these is visible to a member day-to-day — they only affect how reliably staff tooling behaves behind the scenes. Full engineering detail, and every other known defect, is tracked in the technical reference.