Weekly schedule feasibility checker

Validate a proposed timetable against clinician and room windows, service eligibility, protected blocks, room turnover and entered requests.

How to use this tool

Use this schedule feasibility checker to explore whether an entered appointment scenario fits declared clinician and room constraints.

  • Use availability and protected block rows to enter clinician and room windows, service eligibility and protected time.
  • Add request and booking rows with matching IDs. Requests can have optional timing and resource restrictions; bookings need start times, durations and turnover. A booking with the same request ID meets that request.
  • Review each conflict or unmet request and revise the scenario before exporting.

Fictional example and how to read the result

Two simultaneous appointments cannot use the same room. A turnover buffer can also create a conflict even when visit times do not overlap.

The checker tests the entered constraints only. It does not book appointments, confirm real availability or certify staffing and supervision requirements.

Check the constraints of an actual proposed timetable

Create one availability row for each clinician or physical room window. Add protected breaks, documentation or other blocks. Enter each proposed booking with a service, clinician, room, start, duration and room turnover.

Requests describe required service and duration plus any optional day, start, clinician or room restrictions. A valid booking with the same ID meets that request. The fictional example intentionally contains conflicts to demonstrate the checks.

  • Eligible service names must match booking service names; separate them with | or enter * for all.
  • Turnover consumes the room after a visit. Enter clinician preparation or documentation time as explicit protected blocks.
  • Adjacent visits are allowed at a shared endpoint only when room turnover and protected blocks permit them.
  • An unmet request means it is unmet in this timetable. The checker does not place visits, find an optimal schedule or prove infeasibility of all possible schedules.

What to enter in each field

  • Row type: Availability defines a clinician or room window; protected block reserves resources; booking is a proposed visit; request states a visit needed. The tool checks your proposal and does not create a timetable.
  • Row ID (same request/booking ID): Use a unique anonymous ID for each booking and each request. A booking meets a request with the same exact ID when the entered constraints are satisfied.
  • Day (optional for request): Select Mon–Sun for availability, protected blocks and bookings. A request may leave this blank when any day is acceptable.
  • Anonymous clinician: Availability needs exactly one clinician or room. Bookings need both. For a request this is optional and restricts the accepted clinician when entered; use anonymous labels consistently.
  • Anonymous physical room: Enter an anonymous physical room label. Room availability is separate from clinician availability; requests may leave it blank when any eligible room is acceptable.
  • Service (booking/request): Required for bookings/requests: use a service name that matches availability eligibility. Leave blank for availability/protected blocks when not applicable.
  • Start HH:mm (optional for request): Enter 24-hour HH:mm, such as 09:00. A request may leave it blank for any start; all other timed rows need it. Duration and room turnover must end before midnight.
  • Duration minutes: Enter positive whole minutes for the window, block, booking or required visit, such as 45. Booking duration must match the request it claims to meet.
  • Room turnover minutes (booking): Booking rows only: enter whole room turnaround minutes after the visit, including 0 when none. It reserves the room; use protected blocks for separate clinician duties.
  • Eligible services (availability; | or *): Availability rows only: list exact eligible service names separated by |, such as Speech|OT, or * for all services. Both clinician and room windows must cover a booking.

Original fictional example and data fields

Use the editable blank CSV or local import to collect your own de-identified entries. The example below is fictional.

Weekly schedule feasibility checker
Row typeRow ID (same request/booking ID)Day (optional for request)Anonymous clinicianAnonymous physical roomService (booking/request)Start HH:mm (optional for request)Duration minutesRoom turnover minutes (booking)Eligible services (availability; | or *)
availabilityA1MonClinician A09:00480Speech|OT
availabilityA2MonClinician B09:00480OT
availabilityA3MonRoom A09:00480Speech|OT
protected blockDocumentationMonClinician A10:0030
requestVisit 1MonSpeech45
requestVisit 2MonOT45
requestVisit 3MonSpeech30
bookingVisit 1MonClinician ARoom ASpeech09:004515
bookingVisit 2MonClinician BRoom AOT09:454510
bookingVisit 3MonClinician ARoom ASpeech10:003010

Professional sources and permissions

Original worksheets and arithmetic support recording and planning. Follow the official publisher routes for standardized instruments.

Your browser, your entries

Entries are processed in this browser. These pages do not run marketing analytics or send entries to TherapyCRM. Download your work before leaving. Any optional device storage must be selected explicitly.