User Flows & Scenarios - Diyar68/Slotify GitHub Wiki

User Flows & Scenarios

This page describes the main user flows of the Booking System and important alternative scenarios.

The focus is on interactions that contain relevant business logic. Simple CRUD operations are not documented as separate scenarios unless they affect the booking process.

1. Provider Setup Flow

Before customers can book appointments, the Provider must configure the basic information required for booking.

Preconditions

  • The Provider has created an account.
  • The Provider is logged in.

Flow

  1. The Provider creates a Service.
  2. The Provider enters:
    • Service name
    • Service duration
  3. The system stores the Service.
  4. The Provider defines recurring weekly Availability.
  5. The Provider selects a weekday.
  6. The Provider enters a start time and an end time.
  7. The system stores the Availability.
  8. The Provider can repeat this process for additional Services and Availability periods.

Result

The Provider has at least one Service and Availability configured.

Customers can now potentially book appointments through the Provider's public booking page.

2. Successful Appointment Booking

This is the main booking flow of the application.

Preconditions

  • The Provider exists.
  • The Provider offers at least one Service.
  • The Provider has configured Availability.
  • The selected date is in the future.

Example

Provider availability:

Monday: 09:00 – 17:00

Selected Service:

Haircut – 30 minutes

Flow

  1. The Customer opens the Provider's public booking page.
  2. The system identifies the Provider using the booking URL.
  3. The system displays the Provider's Services.
  4. The Customer selects a Service.
  5. The Customer selects a date.
  6. The system determines the Provider's Availability for the selected weekday.
  7. The system loads existing Appointments for the selected date.
  8. The system calculates available booking times using:
    • Provider Availability
    • Service duration
    • Existing blocking Appointments
  9. The system displays the available times.
  10. The Customer selects a start time.
  11. The Customer enters:
    • Name
    • Email address
    • Phone number
  12. The Customer confirms the booking.
  13. The system validates the booking again.
  14. The system calculates:

endTime = startTime + service.duration

  1. The system creates the Appointment.
  2. The Appointment receives the status BOOKED.
  3. The system confirms the successful booking to the Customer.

Result

A new Appointment exists with status BOOKED.

3. Booking Conflict

A booking time may become unavailable between displaying the available times and confirming the booking.

Example

Two Customers open the booking page at approximately the same time.

Both see:

10:30 – available

Customer A confirms the appointment first.

Flow

  1. Customer A selects 10:30.
  2. Customer B also selects 10:30.
  3. Customer A confirms the booking.
  4. The system validates the booking.
  5. The system creates Customer A's Appointment.
  6. Customer B confirms shortly afterwards.
  7. The system validates the requested time again.
  8. The system detects an overlapping Appointment.
  9. The booking is rejected.

Result

Only Customer A receives the Appointment.

Customer B is informed that the selected time is no longer available and must select another time.

4. Appointment Outside Availability

An Appointment must fit completely inside the Provider's Availability.

Example

Provider availability:

09:00 – 17:00

Selected Service:

Hair + Beard – 45 minutes

Customer selects:

16:30

Calculated end time:

17:15

Flow

  1. The Customer attempts to book 16:30.
  2. The system calculates the end time as 17:15.
  3. The system compares the Appointment period with the Provider's Availability.
  4. The system detects that the Appointment would end after 17:00.
  5. The booking is rejected.

Result

No Appointment is created.

The Customer must select another available time.

5. Overlapping Appointment

An Appointment must not overlap an existing blocking Appointment.

Example

Existing Appointment:

10:00 – 10:30

Selected Service duration:

45 minutes

Requested start time:

09:45

Requested period:

09:45 – 10:30

Flow

  1. The Customer requests an Appointment starting at 09:45.
  2. The system calculates the end time as 10:30.
  3. The system checks existing Appointments.
  4. The system detects an overlap with the Appointment from 10:00 to 10:30.
  5. The requested booking is rejected.

Result

No Appointment is created.

6. Booking an Appointment in the Past

Appointments cannot be created for a time that has already passed.

Flow

  1. The Customer attempts to book a past date or time.
  2. The system compares the requested start time with the current time.
  3. The system detects that the requested Appointment is in the past.
  4. The booking is rejected.

Result

No Appointment is created.

7. Provider Views Appointments

The Provider can view the Appointments associated with their Services.

Preconditions

  • The Provider is logged in.

Flow

  1. The Provider opens the Appointment overview.
  2. The system loads the Provider's Appointments.
  3. The system displays the Appointments.
  4. The Provider selects an Appointment.
  5. The system displays its details.

Appointment details include:

  • Customer name
  • Customer email
  • Customer phone number
  • Service
  • Start time
  • End time
  • Status

Result

The Provider can view the details required to manage the Appointment.

8. Provider Cancels Appointment

A Provider can cancel an existing booked Appointment.

Preconditions

  • The Provider is logged in.
  • The Appointment belongs to one of the Provider's Services.
  • The Appointment currently has status BOOKED.

Flow

  1. The Provider opens the Appointment.
  2. The Provider chooses to cancel it.
  3. The system verifies that the Appointment belongs to the Provider.
  4. The system changes the status from:

BOOKED → CANCELLED

  1. The Appointment remains stored in the system.

Result

The Appointment has status CANCELLED.

The cancelled Appointment no longer blocks the time period for future bookings.

9. Provider Completes Appointment

The system does not automatically assume that a past Appointment was successfully completed.

The Provider explicitly records the outcome.

Preconditions

  • The Appointment has status BOOKED.
  • The Appointment has taken place.

Flow

  1. The Provider opens the Appointment.
  2. The Provider marks the Appointment as completed.
  3. The system validates the status change.
  4. The system changes the status from:

BOOKED → COMPLETED

Result

The Appointment has status COMPLETED.

10. Customer Does Not Attend

If the Customer does not attend the Appointment, the Provider can record a no-show.

Preconditions

  • The Appointment has status BOOKED.
  • The Appointment time has passed.

Flow

  1. The Provider opens the Appointment.
  2. The Provider selects the no-show action.
  3. The system validates the status change.
  4. The system changes the status from:

BOOKED → NO_SHOW

Result

The Appointment has status NO_SHOW.

11. Cancelled Time Becomes Available Again

Cancelled Appointments do not block future bookings.

Example

Original Appointment:

14:00 – 14:30

Status:

CANCELLED

Flow

  1. A Customer selects the corresponding date.
  2. The system loads the Provider's Availability.
  3. The system loads existing Appointments.
  4. The system ignores CANCELLED Appointments when determining blocked periods.
  5. The system calculates the available booking times.
  6. The previously cancelled period can become available again.

Result

The time may be booked by another Customer.

Appointment Lifecycle

Appointments follow a simple lifecycle in V1:

BOOKED → COMPLETED

BOOKED → CANCELLED

BOOKED → NO_SHOW

A newly created Appointment always starts with status BOOKED.

The Customer cannot choose or modify the Appointment status.

The system does not automatically mark past Appointments as COMPLETED.