# Service-booking test worksheet

An editable worksheet from Overskill. These are proposed acceptance checks,
not completed Bookslot tests or a guarantee about your generated app.
Use an authorized test copy with sample data. Record Expected and Observed
separately; leave a check Unverified until you have evidence.

## Your test setup

App / version / preview URL:
Test date and person:
Business timezone:
Staff working hours and days off:
Services and eligible staff:
Service duration / cleanup:
Start-time grid interval:
Advance booking window:
Cancellation / rescheduling cutoff:
When a canceled slot becomes bookable:
Customer booking-management access method:
Payment model (in person / test provider):
Notification mode (disabled / test delivery):

Do not put passwords, access tokens, customer contact details, payment details,
or private booking-management links in a shared copy of this worksheet.

## Worked availability example

This is a fictional rule set, not an observed Bookslot implementation:

- Service duration: 30 minutes; cleanup: 10 minutes.
- Existing appointment: 10:00–10:30; staff occupied until 10:40.
- Candidate starts: every 15 minutes.
- 10:30 is invalid because it overlaps cleanup.
- 10:45 is a candidate only if that service and its cleanup fit within staff
  working hours and do not conflict with another booking or time off.
- For this example, cleanup must finish before closing.

Use Pass, Fail, Unverified, or Not applicable. Record a reason for Not applicable.
A visible screen or a local mock alone does not establish saved data, concurrent
reservation safety, message delivery, or a completed payment.

## Eight acceptance checks

| Check | Setup and action | Expected | Observed | Status | Evidence / follow-up |
| --- | --- | --- | --- | --- | --- |
| 1. Duration and cleanup | Give staff A a 10:00–10:30 appointment and 10-minute cleanup. Try a new start at 10:30, then 10:45. Repeat with a longer service and a closing-time boundary. | 10:30 is refused. 10:45 is allowed only when the new service plus cleanup fits all hours/conflicts. Longer services cannot overlap later occupied periods. | | Unverified | |
| 2. Competing submissions and retries | In two independent sessions, select the same staff and occupied period. Submit both nearly together. Retry an already accepted submission, including after a slow response. | Exactly one appointment is reserved for the conflicting period. The other session receives a conflict and refreshed options. Repeating the accepted request does not create another appointment. | | Unverified | |
| 3. Hours and timezone | Try a day off, a time outside working hours, and an appointment viewed from another device timezone. Include a daylight-saving transition relevant to the business timezone. | Closed periods cannot be reserved. Time labels identify their timezone and represent the same moment. Missing or repeated local times are handled explicitly, without a shifted or duplicate booking. | | Unverified | |
| 4. Save and return | Complete a sample booking in your test copy. Record a non-sensitive reference. Refresh, sign out, and return through the intended authorized lookup or sign-in path in a new session. Compare the owner's agenda. | One saved appointment retains service, assigned staff, time, price, and status. The customer and authorized owner's views agree. Success is not shown for a failed save. | | Unverified | |
| 5. Reschedule conflict | Create an appointment, then try moving it to an occupied time. Next choose a valid replacement and retry that change. Include a request after the policy cutoff. | A failed move preserves the original appointment. A valid move reserves the replacement and releases the old time as one change. One appointment remains; retries and cutoff behavior are correct. | | Unverified | |
| 6. Cancellation | Cancel within the stated cutoff, refresh both views, and repeat the request. Attempt another cancellation after the cutoff. Recheck slot availability. | History retains the canceled appointment. The slot reopens according to the stated policy. Repeat requests do not recreate a booking or repeat side effects. Late changes follow the published contact/cutoff rule. | | Unverified | |
| 7. Two-client privacy | With test clients A and B, try A's private booking from B's session through lists, a direct address, and attempted edits/cancellation. Repeat signed out. Check staff scope separately. | Unauthorized people cannot read contact details or change the appointment. Checks are enforced on the server, not only through hidden controls. Authorized customer/staff access still works. | | Unverified | |
| 8. Confirmation and optional payment | Verify the saved confirmation without enabling external actions first. If messages are enabled, use a controlled test recipient and exercise failed delivery/retry. If payment is enabled, use supported test mode for success, failure, duplicate notice, and expired slot hold. | Confirmation matches the saved record. Enabled messages reach only intended recipients and retries do not duplicate promised actions. Payment and appointment states remain consistent. In-person payment never claims an online charge. | | Unverified | |

For check 8, record each enabled subcase separately below. Mark an intentionally
disabled feature Not applicable with a reason; do not call its implementation tested.

- Saved confirmation observed:
- Message delivery / failure / retry observed:
- Payment success / failure / duplicate / expired hold observed:
- Disabled features and reasons:

## Pilot decision

- Failed or unverified checks that block customer use:
- Next correction, owner, and retest date:
- Small pilot scope and consenting participants:
- Completed bookings (separate from page views or account creation):
- Customer-reported confusion:
- What will remain outside this pilot:

Source guide: https://www.overskill.com/learn/build-a-service-booking-app
Inspect the starter: https://www.overskill.com/templates/bookslot
Open the remix page: https://www.overskill.com/remix/exYLEN
General launch checks: https://www.overskill.com/learn/ai-app-launch-checklist