Manage booking requests

Not every booking goes straight to the calendar. A page that uses Request approval, a service with Manual confirmation, or a service that takes payment first all create a request that waits for something: your decision, or the client's payment. The Booking Queue is where you see those requests and act on them.

Where requests appear

Open Settings → Scheduling & Tasks → Calendar Settings → Booking Pages and scroll to the Booking Queue at the bottom of the screen.

The queue has two tabs. Requests lists everything still waiting on a decision or a payment. Upcoming lists confirmed bookings that have not started yet, soonest first, fifty at a time with a Load more link; it is the place to check who is coming today and to cancel a confirmed booking you can no longer host.

Each request shows the service, the booking page it came through, the client's name and contact details, the assigned host, the requested time, and, for paid services, what is due now. Because the queue lives on the Booking Pages screen, it is visible to the workspace owner and admins.

Every booking, whether it waits here or goes straight to the calendar, also creates a client record in Clients, or links to the existing record that matches the client's email address, with the lead source Online booking. See Clients and CRM.

Request statuses

Once a request is confirmed, declined, or its hold expires, it leaves the queue. Confirmed bookings live on the calendar; the queue keeps no history.

When a page has Require email verification on, every request that reaches the queue came from a visitor who confirmed a 6-digit code sent to that email address, so you are never reviewing a request placed under an inbox nobody there could open.

Accept or decline a request

For a request that needs acceptance, choose Accept and add. The booking is added to the calendar, assigned to the host, and the client receives a "Booking accepted" email that includes a calendar invite and, when the service uses Google Meet, the meeting link. For a request that needs confirmation, the calendar event already exists, so the button reads Confirm and the tentative event becomes confirmed.

Choose Decline to turn a request down. You can add a reason, and the client receives a "Booking declined" email that includes it. If the client had already paid, the payment is refunded automatically; see Refunds below.

A request that is waiting for payment cannot be accepted; the button reads Waiting for payment until the client pays or the hold expires. You can still decline it.

Cancel a confirmed booking

Declining turns down a request nobody has agreed to yet. Cancelling calls off a booking that is already on the books, and there are two ways to do it.

From the Booking Queue. Choose Cancel booking on the request. You can add a reason, which the client sees, and when the client has already paid you choose whether to refund them; the refund is on by default. Cancelling is offered on confirmed bookings and on requests still waiting for acceptance, confirmation, or payment.

From the calendar. Delete the booking's event, or set it to cancelled. Workspace369 treats that exactly as it treats the queue action, with the refund on.

Either way the same things happen: the time is released so other clients can book it, the calendar invite the client is holding is withdrawn, and the client receives a "Your business cancelled your appointment" email with the original time in their own timezone, the reason if you gave one, and a link to book another time. When the service has Text message reminders on and the client's number carries a country code, they also get a text message. The assigned host is notified in the app and, when Email assigned teammate is on, by email. A client who paid is refunded in full unless you turned the refund off.

Cancelling is not reversible, and the client is told immediately. To move a booking rather than call it off, drag it on the calendar; see Change a booking from the calendar below.

Understand payment holds

When a service requires a deposit or full payment, the client's slot is held for 30 minutes while they pay. The request shows Waiting for payment together with the time the hold ends, and no other client can take the slot in the meantime.

Once the payment completes, the request takes one of three paths: it is confirmed, it waits for your acceptance on a page with Request approval, or it lands in Needs confirmation when the service uses Manual confirmation. If the hold expires first, the request is marked expired, the time is released to other clients, and the request leaves the queue; the client can start a new booking. A payment that arrives after the hold has already expired is refunded automatically.

Refunds

When a paid booking is canceled by the client within the service's cancellation policy, cancelled by your team from the queue or the calendar, declined by your team, or paid after its hold had already expired, the full payment is refunded automatically to the original payment method. The refund takes 5–10 business days to appear on the client's statement.

Refunds are all or nothing; there are no partial refunds. The one refund you control is a team cancellation: Cancel booking lets you turn the refund off for that booking.

What clients receive

• A confirmation email with a manage link once the booking is made. The manage page shows the appointment in the client's timezone, with the zone name.
• A "Booking accepted" or "Booking declined" email when your team decides on a request.
• A calendar invite (.ics attachment) and an "Add to Google Calendar" link in the confirmation, acceptance, payment received, and reschedule emails.
• Reminders at the times set on the service, 24 hours and 1 hour before by default, by email and, when the service has Text message reminders on, by text message.
• The ability to cancel or reschedule through the manage link, within the notice window set in the service's client policy. A change made through the link updates the calendar event and sends the client a confirmation of the change, such as the "Booking cancelled" email after a cancellation. The assigned host is notified in the app and, when Email assigned teammate is on, by email.

Every one of these — the confirmation, acceptance, decline, cancellation, and reschedule emails, the reminders by email and text, the verification code, and the calendar invite — arrives in the language the client booked in, one of 32; dates and times inside them follow that language and the client's own timezone. The business name, service name, host name, and anything your team typed pass through unchanged. Messages to your team, including the Booking Queue itself, stay in your workspace's language.

Client emails and reminder times are configured on the service; see Configure a service for online booking.

Change a booking from the calendar

An accepted booking is an ordinary calendar event. Open it on the calendar to move it, change the host, add notes, or cancel it, exactly as you would any other event.

Cancelling is the exception: deleting the event, or setting it to cancelled, notifies the client and refunds them, exactly as Cancel booking in the queue does. See Cancel a confirmed booking above.

Every other edit — moving the booking, changing the host, adding notes — is silent. It does not email the client, so tell them yourself if you move their booking there. To move a booking with the client's knowledge, send them their manage link instead.

Troubleshooting

Return to Online booking overview.

Cancelling a booking always reaches the client, whether you cancel it in the Booking Queue or delete the event on the calendar. Moving a booking on the calendar does not: tell the client yourself, or send them their manage link.