Why Automatic Booking Instead of Driver Approval?

Commute Matcher is designed for people who are already travelling to work, rather than professional drivers actively waiting for ride requests.

On ride-hailing platforms, drivers are usually financially motivated to respond quickly because accepting trips is part of their primary work. A driver approval workflow fits that environment because drivers are actively monitoring the platform.

Commute Matcher operates differently. Its drivers are commuters first. They may be getting ready for work, already driving, attending a meeting, or simply not checking the application when a passenger submits a booking request.

Early-morning passengers also need predictable transport arrangements. Waiting for manual approval could create uncertainty when passengers need to know whether their commute is confirmed.

Passenger bookings are confirmed automatically when a matching route has an available seat.

Drivers do not need to manually approve each booking. When a driver publishes a route and specifies the number of available seats, that action is treated as a pre-commitment to accept eligible, verified passengers.

A manual driver approval workflow was considered:

This approach would give drivers greater control over individual bookings. However, it would also make passengers dependent on drivers noticing and responding to requests in time.

A time-limited approval model was also considered, where a booking would be automatically approved or cancelled if the driver did not respond within a set period.

That approach would add more complexity while still leaving the passenger uncertain during the waiting period.

The decision is based on the expected behaviour of Commute Matcher users.

Drivers are not expected to remain active on the application throughout the day. Requiring their approval for every booking would introduce a dependency that the product cannot reliably expect them to fulfil quickly.

If passengers had to wait for approval:

• the driver might not see the notification immediately;
• the passenger might not know whether to continue searching for another route;
• available seats could remain temporarily blocked;
• early-morning commuters could experience unnecessary delays; and
• the platform could feel unreliable even when suitable routes are available.

Moving the driver's decision earlier in the process reduces this uncertainty.

By publishing a route, choosing a departure time, and declaring available seats, the driver is explicitly indicating that those seats are available to eligible passengers.

This is a human-centred design decision because the workflow is based on the real behaviour and constraints of everyday commuters rather than being copied directly from ride-hailing platforms.

Automatic booking reduces the driver's ability to review and approve each passenger before confirmation.

A driver may prefer greater control over who joins the commute. Automatic booking could therefore create discomfort if the platform does not provide sufficient trust and accountability mechanisms.

There is also a risk that a passenger could reserve a seat and fail to appear, preventing another passenger from booking it.

These risks must be managed through:

• user verification;
• clear cancellation rules;
• booking limits;
• user accountability;
• audit trails;
• ratings and reporting features; and
• restrictions for repeated no-shows.

The trade-off is less individual booking control for drivers in exchange for greater speed, certainty, and reduced friction for passengers.

When a driver creates a route, they provide:

• origin;
• destination;
• departure time;
• total available seats; and
• other relevant route details.

When a passenger books a route, the backend checks that:

• the route exists;
• the route is still available;
• at least one seat remains;
• the passenger is eligible to book;
• the passenger has not already booked the same route; and
• the booking will not cause the route to exceed its seat capacity.

If those conditions are satisfied, the system:

1. creates the booking;
2. marks it as confirmed;
3. reduces the available seat count; and
4. returns the confirmed booking information.

The database operation should be handled safely so that two passengers cannot claim the final available seat at the same time.

Drivers may still cancel a route or report a passenger, but they do not need to approve every valid booking individually.