Bookings Workflow

Use this runbook when a workspace offers appointment or service booking through a Sophosic site.

Outcome

At the end:

Step 1: Configure Services

Console surfaces: Scheduling, Services.

For each service, configure:

• Name.
• Description.
• Duration.
• Buffer.
• Price.
• Location.
• Staff or resource assignment.
• Tiers.
• Add-ons.
• Waiver.
• Intake fields.
• Payment timing.
• Deposit amount.
• Publish state.

Verify on sites:

• /bookings lists the service.
• /bookings/{serviceSlug} loads.
• Pricing and duration read correctly.
• Disabled services are not bookable.

Step 2: Configure Availability

Console surfaces: Scheduling, availability editor, Settings > General.

Inputs:

• Business hours.
• Staff hours.
• Service duration.
• Buffers.
• Capacity.
• Overrides.
• Existing bookings.
• Calendar conflicts.

Verify on sites:

• Scheduler shows expected dates.
• Times are in the correct timezone.
• Unavailable times are hidden.
• Same-day or lead-time rules behave as expected.

Failure checks:

• If no times appear, inspect business hours, staff availability, duration, buffers, overrides, calendar sync, and site status.
• If times appear in the wrong timezone, check Settings > General.

Step 3: Configure Calendar Sync

Console surface: Scheduling > Calendar Sync.

Actions:

1. Connect Google Calendar or another supported provider.
2. Select the calendar.
3. Confirm sync status.
4. Test a conflict.
5. Confirm disconnect and reconnect behavior is understood.

Verify:

• Bookings create or sync calendar events as expected.
• External calendar conflicts block availability when configured.
• Sync status is visible in the console.

Step 4: Configure Booking Payments

Console surfaces: Payments, Scheduling, Settings > Checkout and Tax.

Choose one:

• No payment at booking.
• Deposit required.
• Final payment after service.
• Hosted invoice.
• Embedded checkout pay link.
• Manual payment only.

Verify:

• Public booking flow shows the intended payment step.
• Booking detail shows the correct payment action.
• Customer notification includes the right link.
• Refund and cancellation policy is visible.

Step 5: Configure Waivers And Intake

Console surfaces: Scheduling, Forms, Settings > Intake.

Actions:

• Add required waiver when needed.
• Add intake fields.
• Map fields to the booking.
• Decide whether unfinished intake can resume.

Verify on sites:

• Waiver step appears.
• Required fields block submission until complete.
• Intake data appears in booking detail.

Step 6: Create A Public Booking

Sites surfaces:

• /bookings.
• /bookings/{serviceSlug}.
• /bookings/{serviceSlug}/tier.
• /bookings/{serviceSlug}/schedule.
• /bookings/{serviceSlug}/book.
• /bookings/{serviceSlug}/waiver.
• /bookings/checkout.
• /bookings/confirmation/{bookingId}.

Test:

1. Pick service.
2. Pick tier if configured.
3. Pick date and time.
4. Pick staff if configured.
5. Add add-ons.
6. Complete waiver.
7. Enter customer details.
8. Pay deposit if required.
9. Land on confirmation.

Verify in console:

• Booking appears in Scheduling.
• Customer record is linked.
• Intake, add-ons, waiver, payment, and notification state are visible.
• Calendar sync state is visible if connected.

Step 7: Manage Booking Lifecycle

Console surface: booking detail.

Operator actions may include:

• Confirm.
• Start.
• Complete.
• Amend.
• Reschedule.
• Cancel.
• No-show.
• Send pay link.
• Create or manage invoice.
• Refund.
• Add internal notes.

Verify:

• Booking list placement matches lifecycle.
• Customer-facing manage page updates.
• Notifications are sent or intentionally suppressed.
• Payment state and booking state do not contradict each other.

Step 8: Test Customer Manage And Reschedule

Sites surfaces:

• /bookings/manage/{bookingId}.
• /bookings/manage/{bookingId}/reschedule.
• /bookings/pay/{bookingId}.
• /account/my-bookings.
• /account/my-bookings/{id}.

Test:

• Customer can open manage link.
• Customer can reschedule only when policy allows it.
• Pay link works only when balance is payable.
• Customer portal lists the booking.
• Authenticated customer cannot access another customer’s booking.

Step 9: Test Edge Cases

Run at least:

• Booking with no payment.
• Booking with deposit.
• Booking awaiting deposit.
• Reschedule.
• Cancel.
• No-show.
• Refund.
• Calendar conflict.
• Full availability day.
• Service with add-ons.

Use edge cases to prove the booking rules, not just the happy path. Record which console setting controls each result so the team knows whether a future booking failure belongs to availability, staff assignment, payment timing, intake, consent, or customer communication.

• Service with waiver.

Bookings Done Criteria

Use done criteria as the handoff gate between setup and daily operations. A booking workflow is not ready just because the service page loads; it is ready when customers can complete the path and operators can manage the resulting booking without guessing.

• Public service can be booked.
• Availability is trustworthy.
• Payments behave intentionally.
• Booking appears in console.
• Customer receives correct notification.
• Calendar sync is understood.
• Manage/reschedule works.
• Operator lifecycle actions are clear.