Pre-release Documentation for Ascent Direct Booking. Not yet approved for commercial release. View availability details

Customer booking

What a customer can do on the booking page in the local evidence.

A signed-in booking on the fresh pilot stored one visit and captured confirmation mail locally. The guest form on that pilot stopped an invalid email. A completed guest visit was proved on an earlier candidate.

Follow the advanced setup booking walk. It uses labels from an isolated 1.2.104 fixture and does not add a catalogue record.

On this page

  1. Signed-in booking New pilot result on 1.2.104
  2. Guest booking checks New pilot result on 1.2.104
  3. Completed guest visit Shown on an earlier local candidate, not repeated on 1.2.104
  4. One visit when two bookings race Shown on an earlier local candidate, not repeated on 1.2.104
  5. Narrow booking screens New pilot result on 1.2.104

Signed-in booking

A signed-in customer can book a published service and the pilot stored one visit.

New pilot result on 1.2.104

The fresh pilot command stored appointment 3 at 16 November 2026 10:00, with one linked answer row and one notification attempt. Two confirmation subjects were captured locally. The owner and customer views showed the visit.

Before you start. Published booking, an active service, an eligible practitioner, and a time that fits the rules. The pilot used a synthetic customer.

Limit. Local capture is not inbox delivery. This does not take payment. An interrupted command in the fixture stayed running and was not turned into a second success.

Technical details

Why it matters. The business receives a confirmed appointment with a time on the business clock and a captured confirmation record.

Example. A signed-in customer chooses a service, a free time, and confirms. The diary shows that visit once.

Who uses it. A customer with an account. The owner can see the result. The public booking page.

Status: Cited local evidence. This is not commercial acceptance. Origin: New result recorded on the 1.2.104 local pilot. This guide did not re-run that pilot. Candidate 1.2.104 is not an accepted commercial release. R11 local-pilot ledger, record dated 2026-10-24. This guide did not re-run the pilot. Candidate 1.2.104 is not an accepted commercial release.

Related. Guest booking checks, Booking confirmation email

How-to. How a customer books, Your first working booking

Guest booking checks

Guest booking is off until the business opts in. On the fresh pilot the guest form rejected an invalid email and focused that field.

New pilot result on 1.2.104

The guest confirmation step was used for the invalid-email correction and did not create another appointment. Correcting the email then focused the empty phone. A completed guest visit that stored an appointment was proved on an earlier candidate, not added again here.

Before you start. The owner must opt in. Phone can be required by the installation’s setting. The fresh pilot did not finish a new guest visit after the correction.

Limit. Do not say every guest attempt stores a booking. Do not say guest booking is on for a new business. Account sign-in remains the path that stored the fresh pilot visit.

Technical details

Why it matters. A mistyped email is caught before a visit is stored.

Example. A visitor types a sentence instead of an email. The form marks the email field and does not create a booking. After a real address, the phone field is next.

Who uses it. A visitor, only if guest booking is turned on. Otherwise the page asks them to sign in. The public booking page.

Status: Cited local evidence. This is not commercial acceptance. Origin: New result recorded on the 1.2.104 local pilot. This guide did not re-run that pilot. Candidate 1.2.104 is not an accepted commercial release. R11 local-pilot ledger, record dated 2026-10-24. This guide did not re-run the pilot. Candidate 1.2.104 is not an accepted commercial release.

Related. Signed-in booking, Completed guest visit

How-to. How a customer books

Completed guest visit

An earlier candidate stored guest bookings, including one with a blank optional phone.

Shown on an earlier local candidate, not repeated on 1.2.104

That earlier proof completed guest and signed-in bookings. Two concurrent attempts for one practitioner stored one visit. The 1.2.104 fresh pilot did not add another completed guest visit.

Before you start. Guest booking must be enabled. Phone rules follow the setting under test.

Limit. Not repeated as a stored visit on the fresh 1.2.104 pilot. A guest record is not the same as a claimed account.

Technical details

Why it matters. A business that has opted in can let a customer finish without an account, on the candidate where that was proved.

Example. A guest enters a name and a valid email, leaves the optional phone blank, and the earlier candidate stored the visit.

Who uses it. A visitor, when guest booking is enabled. The public booking page on that earlier candidate.

Status: Earlier local evidence. Not a new 1.2.104 result. Origin: Shown on an earlier local candidate and not repeated on 1.2.104. Candidate 1.2.104 is not an accepted commercial release. Earlier local candidate. Not repeated in the 1.2.104 pilot ledger. This guide did not re-run it.

Related. Guest booking checks

How-to. How a customer books

One visit when two bookings race

On an earlier candidate, two concurrent bookings for one practitioner stored one visit.

Shown on an earlier local candidate, not repeated on 1.2.104

The earlier recovery proof recorded one stored visit from two concurrent attempts. The fresh 1.2.104 pilot did not repeat the race.

Before you start. Not repeated on 1.2.104.

Limit. This is not a promise about overlapping different services, shared rooms, or a second practitioner. A running interrupted command in the fresh fixture occupied a slot and was left as a fixture, not cleaned up into a pass.

Technical details

Why it matters. The same person and time are not given away twice when that lock is the one under test.

Example. Two browsers confirm the same practitioner and time together. One visit remains.

Who uses it. Customers, with the owner able to see the single result. The booking writer on that earlier candidate.

Status: Earlier local evidence. Not a new 1.2.104 result. Origin: Shown on an earlier local candidate and not repeated on 1.2.104. Candidate 1.2.104 is not an accepted commercial release. Earlier local candidate. Not repeated in the 1.2.104 pilot ledger. This guide did not re-run it.

Related. Signed-in booking

How-to. How a customer books

Narrow booking screens

The fresh pilot’s customer, owner, and booking screens had no horizontal page overflow at 390 and 320 pixels.

New pilot result on 1.2.104

Skip-to-content took focus and Tab moved on. An invalid guest email focused the email field and set it invalid. Escape on a native disclosure did not close it, and that was left as browser behaviour.

Before you start. The pages included in the 1.2.104 keyboard note. Not every owner screen was named.

Limit. No overflow in that check is not a promise about every future panel. It is not a native-app claim.

Technical details

Why it matters. A phone can be used for the checked screens without the page sliding sideways.

Example. On a narrow window the customer tabs from the skip link into the form, and the page stays within the screen.

Who uses it. Customers and owners on the checked pages. Those pages in the fresh pilot.

Status: Cited local evidence. This is not commercial acceptance. Origin: New result recorded on the 1.2.104 local pilot. This guide did not re-run that pilot. Candidate 1.2.104 is not an accepted commercial release. R11 local-pilot ledger, record dated 2026-10-24. This guide did not re-run the pilot. Candidate 1.2.104 is not an accepted commercial release.

Related. Guest booking checks, Colours, type, and reset

How-to. How a customer books