> ## Documentation Index
> Fetch the complete documentation index at: https://ihub.learnille.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Consultation booking, rescheduling, and rebooking journey

> Student and consultant journeys from purchase through attendance, missed-session recovery, and repeat purchase

**Owner:** Product and Backend Engineering

**Last reviewed:** 2026-09-23

**Next review:** 2026-12-23

Students purchase an available consultation, attend its sessions, and can later move
an eligible session or purchase another consultation. Consultants can prompt students
to reschedule missed sessions and approve replacement times.

## Initial purchase and attendance

| Step | User action | System response |
| - | - | - |
| 1 | Student discovers a published consultation | Shows consultation details and current pricing |
| 2 | Student selects an available date/time | Validates availability; selection alone does not reserve a slot |
| 3 | Student checks out directly or through the cart | Creates a new order and starts payment when required |
| 4 | Student completes payment | Backend payment processing and order fulfillment create enrollment, booking, sessions, and associated ledger entries; zero-total orders skip payment |
| 5 | Student and consultant review scheduled sessions | Sessions are scheduled for secured slots; slots unavailable at fulfillment may require pending-slot resolution |
| 6 | Both participants join and attend | Tracks attendance and ongoing-session state |
| 7 | Consultant completes the session or finalization runs | Finalization uses attendance to mark the session done or missed; qualifying completed sessions have release scheduled under the hold policy |

Initial purchase is not a consultant approval-then-payment workflow. Approval in the
rescheduling flow below applies after a replacement time has been applied.

## Recover a missed session

1. The owning consultant sends a reschedule prompt for an eligible missed session.
2. The student receives email and an in-app notification and opens that session's
   rescheduling UI. The prompt itself changes no booking dates or payment state.
3. The student selects a replacement time. Availability, fees, limits, minimum
   notice, and cooldowns still apply. The student can also start without a prompt.
4. With no fee, the backend applies the replacement dates immediately. With a fee,
   dates are applied after successful backend payment processing.
5. The consultant or an admin approves the `rescheduled` session, changing it to
   `scheduled`. Both participants attend the replacement session with fresh attendance tracking.

There is no reschedule-rejection endpoint in this flow. See the
[rescheduling and rebooking lifecycle](https://ihub.learnille.com/engineering/architecture/consultation-rescheduling-and-rebooking.md)
for the exact responsibilities and state transitions.

## Purchase the consultation again

1. The student chooses the same consultation and a new available date/time.
2. The frontend checks `canPurchase`, not just `isEnrolled`. Existing consultation
   enrollment does not block a repeat purchase, even if an earlier booking is active.
3. The student completes a new checkout at current pricing. Rebooking creates a
   separate order, enrollment, booking, and session set; earlier records stay unchanged.

Rebooking purchases more consultation time. Rescheduling moves an existing session.
Do not send a reschedule-fee order or reuse an old payment reference for a repeat purchase.

## Delivery and validation boundaries

Backend implementation and documented contracts do not prove that all frontend
clients or live integrations have been updated. Verify notification navigation,
`canPurchase` handling, actual payment callbacks, worker execution, and release
behavior with the [QA checklist](https://ihub.learnille.com/engineering/testing-and-qa/consultation-rescheduling-and-rebooking.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.