Set up and verify end-to-end appointment booking in 6am

Launch one complete appointment-booking journey in 6am: a published calendar, a booking page on your website, a saved appointment and CRM contact, and private customer rescheduling or cancellation.

• Owner: Operations administrator responsible for the calendar, with a website editor responsible for the destination page.
• System: 6am dashboard and any website that permits an iframe, including HTML, Astro and WordPress.
• Done when: One synthetic visitor completes the entire journey, the dashboard agrees with the visitor confirmation, the private change link works, and the test is cleaned up.

Scope and prerequisites

This is the acceptance checklist for the booking family. Follow the detailed procedures below instead of creating separate calendars for each step:

You need access to the correct 6am company and permission to manage its calendars, appointments and contacts. To embed, you also need permission to save and publish HTML on the destination website. Prepare a synthetic name, a unique test email and two eligible future times. Never use a real customer to validate this setup.

Current scope is one host per calendar, immediate confirmation on the page, native 6am conflict protection and optional customer changes. It does not include confirmation/reminder emails, external calendar synchronization, automatic video links, payments, groups, round-robin allocation or approval queues. A successful booking must not be presented as proof that any of those integrations exists.

01. Decide the service and operating rules

Record these decisions before configuring the calendar:

The current system spaces candidate starts by the meeting duration; there is no separate start-interval setting. The buffer applies both before and after the meeting. Minimum booking notice and customer-change cutoffs solve different problems: one controls the time a visitor may select, the other controls changes to an existing appointment.

For example, a 30-minute consultation, Monday 09:00–17:00, 120-minute notice and a 30-day window are only suitable if the host can genuinely honor those hours. Choose values for the business rather than copying a test configuration. External commitments must be reflected manually in availability or closures until a separately verified integration exists.

02. Configure one calendar and its change policy

1. Select the company and follow SOP 077 to create or review the calendar. Check title, host, timezone, duration, buffers, availability, notice, booking window and privacy information.
2. Before accepting new bookings, follow SOP 079 on this same calendar. Enable the customer actions the business supports, choose their cutoffs and complete the organizer contact. If self-service is not offered, leave it disabled and tell visitors how to request assistance.
3. Save, then publish. Editing returns the calendar to draft; republish only after reviewing the new settings. Existing appointments retain their saved time and location.
4. Open the public URL as a visitor. Confirm that the service, timezone, location, privacy notice and change policy agree with the decisions above. Check an eligible day and a closed or unavailable day.

New appointments save their own change policy. New cutoffs do not rewrite older bookings. Disabling a customer action blocks it for existing appointments too. Legacy appointments without a saved change policy require staff assistance. Keep those distinctions in customer communication.

03. Place that calendar on the website

1. Follow SOP 078 and use Embed on a website on the published calendar. Copy its current snippet; do not create another calendar for the website.
2. Add the snippet to a normal HTML page, an Astro template or a WordPress Custom HTML block with permission to retain iframes. Other builders must support iframe HTML and allow the 6am origin in their security policy.
3. Keep the separate Open booking calendar in a new tab link beside the embed. Add a clear service heading and instructions to save the booking confirmation; no automatic email is sent.
4. Test the actual visitor page, not only the editor preview. Check narrow and desktop widths, internal scrolling, the date selector, submission buttons and fallback link. Record limitations if the actual CMS, theme or device has not been tested.

The standard iframe follows its container width and uses a configurable fixed height with internal scrolling. No plugin, host script, framework-specific component or automatic height resizing is required. Reloading the host page reloads its public booking URL: save the private management link from the confirmation before leaving.

04. Run one complete visitor journey

Use the same synthetic appointment for all steps:

1. From the embedded visitor page, choose an eligible date and time. Enter Your full name and Email and select Confirm booking. The current public form does not ask for phone or separate first/last names.
2. Save the confirmation reference and private Manage your appointment link when enabled. Verify time, timezone, UTC offset, duration and location. Do not wait for an email.
3. In Appointments, filter by the intended calendar and find that reference through Details. Confirm status and the linked CRM contact. An identity-review flag requires manual review; do not merge or overwrite contacts simply to clear it.
4. In a separate visitor tab, query the original date. The booked interval must be unavailable. Keep the private confirmation available in the first tab.
5. Through its private link, choose another eligible date/time and confirm the reschedule. Check the same reference and contact, new time and customer entry in Change history. The new interval must be occupied; the old interval returns only when current availability, notice and buffers allow it. The previous management link must no longer authorize changes. Save the updated link.
6. Use the updated link to cancel before its cutoff. Explicitly acknowledge cancellation and confirm. Verify cancelled status, the history entry and release of the occupied interval. The appointment and contact must remain recorded.
7. Open the website fallback link and confirm it reaches the same calendar. It creates new bookings; it does not manage the cancelled appointment.

Do not lower production cutoffs or remove buffers to make QA succeed. Use a separate synthetic calendar or eligible future times. If self-service is deliberately disabled, record that decision and verify staff cancellation and the published support route instead; do not claim customer rescheduling was tested.

05. Acceptance and exception handling

If a calendar edit or an expired form rejects a submission, reopen the current page and choose a current slot. A valid link does not bypass a passed cutoff. Cancellation through staff records a staff action; staff rescheduling is not provided by a dedicated editor in this delivery. For detailed recovery and eligibility rules, use SOP 079.

06. Clean up and hand over

Cancel all synthetic appointments and unpublish a QA-only calendar. Preserve history and the reference for reproducibility; do not delete evidence to make the dashboard look empty. For a business calendar, leave it published only after its acceptance checks pass.

Record the company/calendar, destination URL and platform, rules, test reference, original/new times, CRM outcome, history, fallback result, tested browser/device, reviewer and review date. Do not include the private management URL in a public report. Review the dashboard and incoming support requests according to the team's operating routine; this flow provides no automatic staff email alert.

Retest the affected checks after changes to the host, timezone, availability, policy, website theme, embed or security headers. Keep the last-reviewed date visible on the procedure, but distinguish an editorial update from testing a particular customer's account or every supported CMS.