Five decisions to settle before quoting this booking portal
Quote-risk review · One workflow family · Source-linked questions and acceptance examples
Synthetic demonstration, not a customer case. This review examines the invented initial brief S01–S08 below. No savings, avoided defects or customer outcomes are claimed. The later acceptance baseline A01–A06 is deliberately excluded from this earlier review.
Revision 1.0 · October 21, 2026 · Source: synthetic booking portal brief, Part 1, version 1.0 · Scope: booking lifecycle only
Executive reading
The brief establishes a useful starting scope, but it does not support a clean fixed-price commitment yet. Resolve the cancellation contradiction and choose how capacity changes, duplicate submissions and notifications behave. The following questions identify decisions; they do not choose the client's policies or certify the estimate.
Resolve before fixed-price scopeS04 permits cancellation until 24 hours before start; S05 promises cancellation any time before a session.
Potential scope consequence: different UI states, boundary cases and customer communications. The brief also does not define the time zone, exact cutoff boundary or the meaning of “promptly” for restored places. These are unanswered questions, not proven implementation defects.
Client question: which policy should govern? Is cancellation exactly 24 hours before start allowed, which stored time determines the boundary, and when are places released?
Options: apply a 24-hour cutoff and change sales copy; or allow cancellation until start and revise S04. Document one rule across screens and messages.
Draft acceptance example, subject to approval: if the client chooses an inclusive 24-hour cutoff, a session at 12:00 UTC tomorrow can be cancelled at 12:00 UTC today, but not at 12:00:01. A successful cancellation restores capacity once.
2 · Last-place concurrency and duplicate requests
Define the expected resultS02 requires bookings to remain within capacity. S03 describes confirmation but does not state how overlapping requests or a repeated submission are resolved.
Potential scope consequence: server transaction behavior, duplicate protection, rejection messages and repeatable test fixtures may be needed. Merely disabling the submit button would not define the expected server outcome.
Client question: should simultaneous requests for the last place produce exactly one confirmation? When a browser retries, should the existing booking be returned rather than another created?
Draft acceptance example: with one remaining place, two distinct one-place requests produce one confirmation and one rejection. Repeating a confirmed request ID returns its original booking.
3 · Capacity changes and existing commitments
Name the exceptionS07 permits capacity changes and “exceptional cases”; S02 prohibits bookings above remaining capacity.
Potential scope consequence: allowing capacity reductions below committed places may introduce customer reassignment, cancellation or override workflows. None is described in the current brief.
Client question: can a manager lower capacity below the number of confirmed places? Which exact exceptional actions are in the first release?
Minimal option: refuse such reductions with an explanatory message. Handle exceptional customer changes outside the application in this release. The client must approve this exclusion.
Draft acceptance example: with four confirmed places, reducing capacity from five to three is refused and changes no bookings.
4 · Branch and customer visibility
Make scope testableS06 limits managers to their own branch and says customer information stays private, but does not define reassignment, cross-branch access or permitted fields.
Potential scope consequence: a multi-branch dashboard or delegated manager role would add behavior beyond a single assigned branch. The privacy statement alone is not an acceptance criterion or legal assessment.
Client question: is each manager assigned exactly one branch? Which customer fields can that manager see? Is cross-branch access ever permitted?
Draft acceptance example: a North manager can open a North booking but receives a refusal when navigating directly to a known South fixture record. This is a limited functional role test, not a penetration test.
5 · Confirmation email and failure handling
Bound the integrationS03 requires on-screen and email confirmation; S08 includes notifications and setup without identifying a sender service or failure rule.
Potential scope consequence: sender verification, authorized test mail, retries and support visibility may be required. None of their costs or effort can be inferred from the brief.
Client question: who supplies the sender account and domain setup? If mail fails, is the booking still confirmed? What retry and failure display are included?
Draft acceptance example: if the chosen policy keeps the booking confirmed when mail fails, a controlled delivery failure leaves the booking intact and exposes a defined retry state. Email tests remain blocked until an authorized test mail sink is available.
Client-ready decision list
Choose one cancellation policy, cutoff boundary and time basis.
Approve outcomes for last-place races and duplicate requests.
Choose capacity-reduction behavior and list excluded exceptions.
Confirm the single-branch manager model and visible customer fields.
Assign notification setup ownership and approve failure handling.
Once answered, update the quotation assumptions and acceptance criteria. This sample does not infer hours saved, calculate a project price, or recommend signing a contract.
Initial synthetic source excerpts
S01: Multiple branches; customers book sessions; branch managers manage sessions and bookings. These are the two roles.
S02: Customers choose a session and number of places. A session has a maximum capacity. A booking must not exceed the places remaining.
S03: Confirm successful bookings on screen and by email. Customers should see their bookings in their account.
S04: Customers can cancel bookings until 24 hours before the session. Cancellation should release the places promptly.
S05: The sales page will say “Cancel any time before your session.” Payment and refunds are excluded from the first release.
S06: Managers can see and manage bookings for their own branch. Customer information should remain private.
S07: Managers can change a session's capacity. It should be easy to handle exceptional cases.
S08: Desktop browsers; fixed-price quote requested for the portal, notifications and setup. The estimate must state exclusions.
What the service includes
Quote-risk review: proposed $249 pilot, then $499 standard. Up to 20 readable pages, one workflow and one proposed quote; source-linked issues, questions and draft acceptance examples, with one bounded revision. Legal opinions, complete BA consultancy, implementation and commercial estimate approval are excluded.
David leads this service with AI assisting analysis and drafting. Human involvement is agreed for each project. A buyer should compare its usefulness with their existing review process. No source-backed review can recover business intent the client has not provided.