# Historical reservation cases: evidence notes

The conversation reader contains ten literal excerpts from historical JOEY correspondence in threads #004, #113 and #340. Each excerpt was checked against its cited line in the original Outlook text export. Wording and spelling inside the excerpts are unchanged; surrounding passages, names, signatures, contact metadata and event dates are omitted. These are selected passages, not full transcripts. Full private threads are not published.

The adjacent workflow labels, diagrams and interpretations are editorial analysis. Supporting examples #224 and #353 remain paraphrased. None of these materials establishes current company policy or represents a run of the later Reservation Workbench application.

## Source and scope

The historical review covered 394 indexed conversation-thread exports, dated November 2024 through August 2025. Threads can repeat quoted messages, so the count is not a count of unique inquiries, reservations or software executions. The review prioritized 13 cases. This page uses three primary cases and two supporting design lessons.

Source basis: the original `Outlook_Search_Threads.zip` and the supplied historical evidence review. Thread numbers are the three-digit filename prefixes in the archive. The reader cites original text-file line numbers. Intermediate messages are omitted; displayed excerpts follow chronological order within each case.

## Case 01: changing requirements | #004

The guest initially estimated 10–15 people and preferred an alternate seating configuration. The coordinator explained the limitation on holding two layouts and the conditional availability of the alternative. A later guest message confirmed 13 people.

Established: the count changed, and the seating alternative was conditional.
Not established: that the preferred alternative was ultimately reserved.
Design implication: distinguish updated requirements from changes to a verified booking.

## Case 02: escalation with a fallback | #113

A private-dining enquiry remained unanswered. The coordinator restored the original 22-person booking, reassured the guest about that reservation, and followed up with the specialist team.

Established: the fallback booking was restored and specialist follow-up occurred.
Not established: the final private-room decision.
Design implication: retain a confirmed fallback alongside an open request; make the next action and owner visible.

## Supporting example: linked reservations | #224

Two groups of 25 and 15 required related reservation records. The coordinator checked availability, entered an additional booking, and sought clarification of large-party conditions. Events management requested confirmation and relevant department involvement.

Established: an additional reservation was entered and operational coordination was requested.
Not established: final attendance or fulfillment of every event requirement.
Design implication: preserve the relationship between allocations, outstanding conditions and staff tasks. This historical example does not claim automated linked-booking support in the prototype.

## Human verification | #353

A historical conversation involved changing attendance, accessibility, allergies and physically fixed tables. Staff proposed an accessible alternative; the coordinator clarified allergy versus preference and explained limits on moving tables.

The public page retains only the kinds of requirements and the associated verification principles. It omits identifiable guest details and exact sensitive circumstances. These principles do not establish medical or allergen safety, or automated resolution by the application.

## Case 03: correcting the record | #340

The guest corrects the party size from 11 to 10. Cameron later communicates confirmation. In a subsequent exchange, the guest requests a 4:45 start; another coordinator replies that the reservation has changed to 4:45–7:15. Attribution distinguishes Cameron's message from the later coordinator's reply. The emails establish the communicated decisions, not independent booking-system receipts.

Verbatim source locations: guest correction at line 61; Cameron's confirmation at line 41; later time request at line 28; later coordinator reply at line 15. The last excerpt appears within the exported message preview.

## Additional intake lesson | #340

A website notification used a no-reply sender, and the thread contained a delivery failure. This supports separating the notification source from the guest contact and verifying the reply recipient. It is a design lesson, not evidence of implemented inbox integration.

## Distinct evidence categories

- Historical correspondence demonstrates operational complexity and documented coordinator actions.
- The approximately 45-to-5-minute handling-time figure is Cameron's firsthand estimate for the original workflow, not a measurement established by these threads.
- The current application's separately labeled captures and regression reports demonstrate specific prototype behavior on synthetic records.

The archive does not establish which replies were LLM-assisted, AI-caused guest satisfaction, application productivity gains or current-model extraction accuracy. No historical case on this page is presented as a replayed application test.