Pre-release Documentation for Ascent Direct Booking. Not yet approved for commercial release. View availability details
Change requests and waitlists
Staff decisions, conflicts, and what a waitlist has not been shown to do.
A second decision on the same request left the visit at its original time. The pilot does not show automatic approval. Waitlist sending was not re-verified on 1.2.104.
If a change request is decided twice, the second decision conflicts and the visit stays at the original time.
New pilot result on 1.2.104
On the fresh pilot, request 1 for appointment 2 returned a conflict on the second decision. The visit stayed at 26 October 2026 10:45. The owner list showed the unmoved visit. A browser click of Accept was not required for that result.
Before you start. An existing change request. Customer acceptance of a counter-proposal was not the fresh check.
Limit. The system does not approve a request by itself. A conflict does not notify the customer in this result. Do not describe the customer’s accept button as proved on 1.2.104.
Technical details
Why it matters. Two people cannot both believe they moved the same appointment.
Example. One decision is stored. A later conflicting decision does not move the visit again.
Who uses it. The business owner. The owner request list.
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.
Owner approval, decline, and a counter-proposal were proved on earlier candidates. The fresh 1.2.104 check was the conflict that keeps the original time.
Not determined
An earlier installer accepted an owner counter-offer and stored the new time. The 1.2.104 row did not click Accept and did not show a customer response.
Before you start. Unresolved for 1.2.104 beyond the conflict behaviour.
Limit. A proposal is not an automatic reservation in any evidence cited here. Do not say the customer can accept a counter-offer on 1.2.104.
Technical details
Why it matters. Customers need to know whether a proposed time is reserved. This guide will not say that it is.
Example. The owner suggests a new time and the customer accepts it. Treat the customer response on 1.2.104 as unverified.
Who uses it. The owner proposes. The customer response is unresolved on this candidate. The request screens.
Status: Not determined. Origin: Not determined. Candidate 1.2.104 is not an accepted commercial release. Not verified for this guide. Described as unresolved rather than as an available feature.
Waitlist signup and notification were not re-verified on 1.2.104.
Not determined
Earlier proofs mention claimed waitlist rows and an uncertain send that must not be sent again. The 1.2.104 ledger does not repeat them. Nothing cited here says a waitlist row reserves a time.
Before you start. Unresolved.
Limit. Do not say a waitlist reserves a slot, sends automatically, or is included in 1.2.104.
Technical details
Why it matters. A full day sometimes needs a waiting list. This candidate’s guide does not claim one.
Example. A customer asks to be told if a time frees. Do not promise a message or a held slot.
Who uses it. Unknown. Unknown on this candidate.
Status: Not determined. Origin: Not determined. Candidate 1.2.104 is not an accepted commercial release. Not verified for this guide. Described as unresolved rather than as an available feature.
Frequent-reschedule tracking was not separately retested. The fresh change-request result is a second decision that conflicts and leaves the original time. That result is not a count or a warning about customers who reschedule often.