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 type
Row ID (same request/booking ID)
Day (optional for request)
Anonymous clinician
Anonymous physical room
Service (booking/request)
Start HH:mm (optional for request)
Duration minutes
Room turnover minutes (booking)
Eligible services (availability; | or *)
availability
A1
Mon
Clinician A
09:00
480
Speech|OT
availability
A2
Mon
Clinician B
09:00
480
OT
availability
A3
Mon
Room A
09:00
480
Speech|OT
protected block
Documentation
Mon
Clinician A
10:00
30
request
Visit 1
Mon
Speech
45
request
Visit 2
Mon
OT
45
request
Visit 3
Mon
Speech
30
booking
Visit 1
Mon
Clinician A
Room A
Speech
09:00
45
15
booking
Visit 2
Mon
Clinician B
Room A
OT
09:45
45
10
booking
Visit 3
Mon
Clinician A
Room A
Speech
10:00
30
10
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.