Operations & software / 2024–2026
A Python application for reservation coordinators to review booking exports, plan arrangements and prepare guest replies. I designed and built it from my experience at JOEY, with human review before commitments are made.
Python · NiceGUI · SQLite / Independent software prototype
Python for workflow checks, NiceGUI for the interface and SQLite for saved case records.
Workflow commands, typed records & deterministic rules
Case workspace, review controls & service handoff
Revision checks, atomic writes & audit history
Regression coverage & recorded browser journeys
00 / Project overview
Independent system / workflow & software
2024–2025 workflow developed and tested at JOEY
2026 software implementation
A guest’s request, an available table and an agreed booking are three different things. The workbench keeps them connected without treating them as interchangeable.
The challenge: The information needed to answer an inquiry was spread across messages, booking records and operational notes. A polished reply could still rely on an incomplete or outdated arrangement.
My contribution: I independently developed and tested the original workflow while coordinating reservations at JOEY, then designed and built the application’s interface, import handling, decision rules and audit controls.
The result: A working local prototype with visible next actions, source-linked records and checks that must be renewed when the facts they depend on change.
Actual application captures · one synthetic case · select a stage in the walkthrough below to inspect it.
Workflow / one case, four stages
The application organizes the evidence. The coordinator makes and verifies the commitments.
Select a stage to inspect its inputs, checks and decisions.
Guest messages, contact details and the intended visit.
Application / structure & checks
Preserve original wording; suggest source-backed fields; keep unknown values distinct from confirmed answers.
Coordinator / judgment & action
Confirm party size, timing, allergies, access needs and terms that need clarification.
A case with source evidence, confirmed requirements and unresolved questions.
Morgan requests six guests at 18:00. “No allergies” is confirmed for this visit, rather than inferred from past notes.
Decision boundaryMissing information stays visible. It is not silently converted into “none”.
The case, reviewed reservation exports, table configuration and operating policies.
Application / structure & checks
Check coverage and freshness, then assess capacity, overlap, access and allowed table groups.
Coordinator / judgment & action
Check live service flow, obtain guest acceptance and verify the booking in the external system.
A proposed plan with separate acceptance and verification records; a saved external allocation after verification.
Table B is occupied. Table A seats eight and fits Morgan’s six-person request. The snapshot supports the plan; the coordinator verifies reality.
Decision boundary“Potentially feasible” is planning support. It is not guest acceptance or booking confirmation.
The current plan, confirmed requirements, source messages and verification evidence.
Application / structure & checks
Track the saved response and whether its review still matches the wording and supporting record.
Coordinator / judgment & action
Review the exact text, send it externally and record that it was sent.
A saved response with a current review and an explicitly recorded sending action.
After the arrangement is accepted and verified, the coordinator reviews Morgan’s final confirmation before copying it to send.
Decision boundaryA saved draft is not a reviewed reply. A reviewed reply is not proof that it was sent.
The verified allocation, requirements, promises, open tasks and case owner.
Application / structure & checks
Assemble a date-specific service record and track whether a staff receipt matches its current contents.
Coordinator / judgment & action
Review the service record, acknowledge it by name and handle outstanding work.
A shared operational reference with explicit tasks and a named review receipt.
Morgan’s saved table and visit requirements are available for the next shift. Later changes make the prior staff receipt outdated.
Decision boundaryHandoff does not erase unfinished work. Changed commitments need a fresh staff review.
Changes return to the relevant checks
Reviews depend on the current record. A new time can reopen the plan; edited wording requires another response review; a changed handoff needs a fresh staff receipt.
Illustrated from the implemented coordinator workflow. Stages can be revisited; sending and external booking changes remain manual.
01 / The application
Follow a recorded application test from intake to handoff. All four views show the same synthetic case in the coordinator build.
Morgan’s request
Six guests · 18:00 · two hours
Table B is occupied; table A has eight seats.
01 / Request
Morgan asks for six guests at 18:00. The coordinator records contact details and confirms allergies, accessibility, minors, billing and occasion for this visit.
The record distinguishes “not asked” from a confirmed “none”.
Recorded application journey.
Synthetic guest and venue.
02 / Plan
Table B is occupied. Table A has eight seats and passes the conditional snapshot check. The operator checks live flow, verifies the external booking and records acceptance from a call.
Guest acceptance and external booking verification are separate records.
Recorded application journey.
Synthetic guest and venue.
03 / Reply
After acceptance and booking verification, the coordinator saves a final confirmation, reviews it and copies the approved text to send externally.
Saving, reviewing and reporting a sent response are distinct actions.
Recorded application journey.
Synthetic guest and venue.
04 / Handoff
The date-specific service record brings the saved allocation, requirements, promises and open tasks together. A named staff member records their review.
Later changes make the staff review receipt outdated.
Recorded application journey.
Synthetic guest and venue.
The coordinator works from one case record instead of reconstructing the arrangement from messages, templates and booking notes.
Source / original inquiry
“No allergies, no accessibility needs, no minors, one bill and no special occasion.”
Exact excerpt from the synthetic Morgan fixture.
Operator-reviewed field
The coordinator confirms the field. Pattern extraction can suggest source-backed values; it does not silently turn historical notes into current requirements.
02 / The operational problem
An inquiry could require several decisions before a reply: clarify the party’s needs, check seating and service flow, explain terms, record the booking and track acceptance.
The system began as a workflow I independently developed and tested while coordinating reservations at JOEY. Building on existing response templates, I connected structured information gathering, LLM prompts, booking notes, exception handling and follow-up steps.
During employment, I used LLM chat tools and checked bookings manually; there were no Python scripts or API integrations. I later built the Python application to keep those requests, decisions and commitments in saved records governed by testable rules.
My estimate for a typical complex inquiry in the original workflow, from interpretation and checks to the initial reply. Not a controlled study or a benchmark of this application.
Reconstructed from the documented manual workflow and implemented coordinator. External booking and guest contact remain manual. Download the workflow comparison
03 / The original conversations
Selected word-for-word excerpts from the reservation inbox, paired with the decisions and handoffs they document.
Original wording, including spelling, is preserved within each excerpt. Names, signatures and unrelated passages are omitted. These are selected passages, not complete emails or screenshots.
Thread #004 / Changing headcount / conditional seating
Would I be able to confirm this the day prior, or do you need the final number earlier?
Request
The guest wants to confirm later. The earlier exchange establishes a range of 10–15, not a fixed attendance.
We can absolutely wait until the day before to confirm your final headcount. However, just to be transparent, we’re unable to hold both seating options until then.
Plan + reply
The reply distinguishes flexibility on headcount from a promise to reserve two layouts. The alternative also depended on 11 or fewer guests and remaining availability.
Unless anything arises tomorrow, our final count is 13
Update
The guest supplies 13, with a caveat. That does not establish a move to the alternative layout.
Keep the requested change separate from the saved arrangement.
Inspect the relevant controlsThread #113 / Specialist handoff / fallback reservation
Do you have a contact I can speak to re-private dinning spaces?
Request
The private-room enquiry requires specialist confirmation. It is a separate request from the existing Lounge booking.
I completely understand your need to confirm availability for our Private Dining Room, and while I’m unable to confirm the PDR myself, I’m going to personally follow up with our private dining team right now to get you an answer as quickly as possible.
Reply
The guest-facing reply promises a follow-up, not a room. No availability is invented.
Would you mind touching base with her as soon as you’re able? I’ve kept their Lounge reservation in place for 22 guests just in case, but I think they’re hoping to finalize one way or another soon.
Handoff
The internal message records the 22-person fallback while requesting specialist action. The archive does not establish the private-room outcome.
Track the booking and the open escalation independently.
Inspect the relevant controlsThread #340 / Guest correction / later time change
Actually we are 10 persons not 11
Request update
A short follow-up supersedes the earlier party size. The whole conversation matters, not only the first form submission.
Otherwise, it looks like we have everything we need from you so I've gone ahead and confirmed your reservation.
Reply
The historical reply states that the reservation was confirmed. It is not an independent booking-system receipt.
Would it be possible to move our reservation to 4:45?
Plan update
A later time change requires a fresh decision; it is not already an agreed amendment.
I have changed your reservation starting to 4:45pm. You will have this table reserved until 7:15pm.
Reply + service
Another coordinator communicates the new start and end. The record needs to carry that agreement into service.
Re-check changes and preserve the latest communicated commitment.
Inspect the relevant controlsEvidence boundary. These emails document the historical coordination process. They do not establish which replies were LLM-assisted or show outputs from the later application. Workflow labels and diagrams are editorial analysis, not recovered AI logs.
Thread #224 / reconstructed
The correspondence documents an additional booking and cross-team confirmation tasks. Final attendance is not established.
Thread #353 / paraphrased only
Health-related guest correspondence is not reproduced.
Source: original Outlook text exports. Thread numbers refer to archive filename prefixes; line numbers refer to those files. Excerpts are chronological within each case, but intermediate messages are omitted. Full private threads are not published. Read the historical case notes
04 / Data integration
At the start of a shift, the coordinator uploads a reservation export and checks its column mappings, dates and coverage before applying it. The parser supports CSV and TSV files.
A CSV is a snapshot.
It assists planning; it cannot establish current availability.
Parse CSV or TSV rows, separators, headers and source values.
Review mappings, date order, venue, time zone and coverage.
Reject invalid rows or mixed venues; review warnings.
Replace the previous report and compare stable reservation IDs.
Correct the data or mapping and validate again. Partially valid rows do not become trusted context.
Missing is not cancelled. Added, changed and absent rows support reconciliation. Omission from an export never automatically cancels a booking.
Freshness is part of validity. Assessment requires complete declared coverage, matching time zones and a report no more than four hours old.
Reading the result
The same six-person request can produce a different result depending on the evidence and selected table. These are source-derived illustrations of the assessment rules.
01 / Evidence incomplete
Missing coverage, stale data or an unknown overlapping table prevents a reliable comparison.
02 / Arrangement conflicts
With usable context, the selected arrangement fails an overlap, capacity, accessibility or grouping check.
03 / Snapshot supports plan
The selected arrangement satisfies the configured constraints against the reviewed snapshot.
Illustrative states, not new application screenshots. “Potentially feasible” is conditional planning support, not a booking confirmation.
05 / System architecture
NiceGUI calls workflow commands that check the supporting evidence and the record version. SQLite then saves the change and its audit event together.
A plausible response does not prove that a booking exists. The application records the evidence for each decision separately.
Reviewed inputs
Original wording, contact and visit requirements
Mapped rows, declared coverage and freshness
Tables, allowed groups, occupancy assumptions and policies
Local application
Workflow commands
Snapshot conflicts · evidence fingerprints
Completion gates · revision checks
Atomic update + audit event
Coordinator authority
No automatic email sending or booking-system writes.
Original workflow
Chat tools helped interpret requests and prepare replies during employment.
Current coordinator
Source-backed pattern suggestions support intake. Models do not determine booking validity.
Separate demo
Anthropic structured output, validation and bounded retries. Live-model evaluation has not been run.
Download the architecture diagram · Read the implementation notes
06 / Reliability by design
An approval applies to particular facts, not to the case forever. Changing the plan, contact details or response text invalidates only the evidence that depends on it.
Explore three kinds of change.
This is a source-derived rule illustration, not a live reservation tool.
Change-impact explorer
Linked to seating, time, duration and terms.
Linked to the plan, guest record and policy.
Linked to the saved wording and source evidence.
The arrangement, external verification and saved response all match their reviewed evidence.
A request to change the time does not overwrite the previously verified booking. It remains visible until the operator verifies the external update.
Design decisions
Exports support planning, rules check the saved record, and the coordinator verifies live conditions. Each choice adds review work in exchange for a clearer basis for decisions.
| Decision | Why it fits the problem | Tradeoff |
|---|---|---|
| Reviewed exports before direct integration | Make source coverage, mappings and freshness explicit before using booking data. | Snapshots can age. A coordinator still checks live availability and reconciles discrepancies. |
| Separate assistance from authority | Suggestions help prepare the case; explicit rules and human review determine what can be confirmed. | More review steps, and no autonomous sending or booking. Model suggestions do not remove accountability. |
| Local persistence with revision checks | Keep a durable case history and reject stale actions across ordinary browser tabs. | The prototype serves a local operator workflow. Shared production use needs authentication, roles and recovery controls. |
Handling interruptions
A coordinator may reopen a case while another tab still shows old information. The workbench checks the record revision before accepting the action.
The command supplies the version the operator saw. If a newer version is already saved, the command rejects the action before changing the record.
A SQLite transaction saves the updated record, increments its revision and appends the before/after event. A failure rolls back the operation.
Browser-specific buffers recover unfinished wording after reload. Recovered text still needs to be saved and reviewed against the current case.
A fingerprint of the arrangement links the acceptance record to the current plan. If the plan changes, the fingerprints no longer match.
Exact logic from coordinator/workflow.py, reformatted for readability.
def accepted(c):
return bool(
c["acceptance"]
and c["acceptance"]["plan_hash"]
== plan_hash(c)
)07 / Evidence & next steps
The release includes automated regression tests and recorded browser journeys using synthetic data. They check specific prototype behaviours, including stale updates, failed writes and renewed reviews.
Application release 3.0
October 2026
Historical workflow estimates are reported separately.
45 coordinator cases and 153 retained regressions in the release log.
Coordinator, import, demo workflow and interface capture scripts.
1440, 820 and 390 px. Chromium checks using synthetic records.
| Failure or change | Expected behaviour | Why it matters |
|---|---|---|
| Requested time changes | Renew relevant reviews; preserve the saved allocation | A new request does not silently replace a booking |
| An older tab submits an action | Reject its stale revision before writing | Old information cannot overwrite a newer record |
| A command fails validation | Keep the record and audit history unchanged | A failed action leaves no partial mutation |
| An overlapping table is unknown | Return “Cannot assess” | Missing context is not treated as free capacity |
| No guest answer / a hold expires | Create follow-up or manual-release work | Silence does not become acceptance or cancellation |
| The handoff record changes | Mark the staff review as outdated | The next shift can identify unreviewed changes |
Supporting evidence
Open the repository for source code and setup instructions, or inspect the documented decisions and release evidence below.
Independent project. The original workflow was developed and tested during my work at JOEY; the later software prototype was not deployed there. Neither JOEY nor OpenTable endorses the project. The application uses synthetic examples and does not send email or modify external bookings. The hero is an illustrative composition; the walkthrough shows actual application screenshots. Application productivity, live-model performance and real-user usability remain unmeasured.
