TableAgain

Turn restaurant cancellations into confirmed bookings with an AI WhatsApp assistant that understands waitlist preferences, handles changes by reply, and keeps owners in control.

Comment

Inspiration

A restaurant can have an empty table and a waiting guest at the same time. Connecting them still takes work: checking availability, understanding the guest's constraints, confirming the details, and handling another change of plan.

TableAgain grew from that coordination problem. A guest might say, “Either Friday or Saturday at six works, but I need at least an hour's notice.” When a table opens, their plans may have changed again.

The goal was to let guests express those needs naturally in WhatsApp and turn the conversation into a reservation the restaurant can honor, while keeping the owner in control.

What it does

TableAgain is an AI reservation and waitlist assistant on WhatsApp, paired with a visual dashboard for restaurant staff.

Its two core features work together:

1. Confirmed waiting conditions

Guests describe their preferred dates, sitting time, party size, and minimum notice period in natural language. TableAgain asks for missing information and presents the exact conditions for confirmation before adding them to the waitlist.

When a cancellation creates an opening, server rules select the first eligible waiting party and issue an offer with an expiration time.

2. Changes by reply

A guest can reply to an offer with a change such as, “Saturday at eight instead of Friday at six.”

TableAgain checks the alternative and presents new terms for acceptance. When the guest releases the original opening, it can pass to the next eligible waiting party. Each guest must explicitly accept their own current offer before a booking is confirmed.

In the demonstrated workflow, Guest A moves to an available alternative, and Guest B accepts the original opening: two confirmed reservations and one cancelled slot recovered.

Owner control

Staff can create phone bookings, seat walk-ins, edit visit times, move tables, cancel reservations, and track arrivals, departures, overdue visits, and cleanup time.

Requests requiring human judgment can be handed to the owner, with an email notification through Amazon SES. Human takeover pauses automated booking changes for that conversation.

How it was built

The application uses TypeScript across the booking engine, backend services, React interface, and AWS CDK infrastructure.

  • AWS End User Messaging Social connects the WhatsApp conversation to the application. The backend uses the AWS SDK's SendWhatsAppMessage operation to send text and interactive replies.
  • Amazon Bedrock with Amazon Nova Lite interprets natural-language requests into structured intents. Schema validation and server rules check those intents before any booking action.
  • AWS Lambda, Amazon SNS, and Amazon SQS process incoming events and queued work.
  • Amazon DynamoDB stores the shared authoritative ledger for reservations, waiting conditions, offers, and operational history.
  • Amazon SES sends owner exception notifications through the SES v2 SendEmail operation.
  • React and Vite, hosted through Amazon S3 and CloudFront, provide the web interfaces. Amazon Cognito authenticates owners and judges, with authorization enforced again on the server.

AI handles language interpretation. Deterministic rules handle availability, FIFO order among eligible guests, offer expiration, and reservation commits.

Database transactions protect table allocation. Offer-specific acceptance and idempotent commands protect against stale buttons and duplicate requests. A transactional outbox tracks outgoing messages separately from booking status.

The WhatsApp channel, owner interface, and judge rehearsal share the booking engine.

Challenges

Understanding a change precisely. A message can contain both the date a guest wants and the date they are rejecting. Early testing exposed schema errors and ambiguous date handling. Structured validation, date grounding, and clarification behavior helped make those requests actionable.

Keeping conversations consistent with the ledger. Guests can reply late, delivery events can repeat, and owners can change availability while an offer is open. Expiring holds, transactional checks, and explicit acceptance tie each confirmation to the correct current terms.

Handling restaurant time correctly. The restaurant uses America/New_York independently of the AWS deployment region. Date interpretation, daylight saving transitions, offer deadlines, and cleanup periods needed consistent treatment.

Controlling the complete workflow's cost. Model calls are only part of the work. Database operations, queues, retries, delivery tracking, and recovery also consume resources. The implementation checks budgets before admitting work and records usage afterward, with bounded processing and recovery paths.

Accomplishments

The complete cancellation-and-rebooking workflow was verified with two real WhatsApp test accounts. Both guests confirmed their waiting conditions, received their respective offers, accepted, and received booking confirmations. All nine outbound replies in that controlled scenario reached READ status, and the durable reservations matched the owner dashboard.

Separate checks verified SES delivery to the owner's mailbox and owner operations including check-in, overdue handling, checkout, and the ten-minute cleanup interval.

Verification for the deployed judging version included:

  • 182 Vitest tests and six Playwright browser journeys.
  • A fixed, human-reviewed 30-case AI evaluation that passed all defined cases with zero defined safety violations.
  • Local cost tests with 0, 1,000, and 100,000 historical records, plus a deployment gate that rejected an intentionally expensive regression.

These results describe the tested scenarios; broader language accuracy and restaurant operating results still need field validation.

What was learned

Useful conversational automation needs a clear connection between what a guest says, what they agree to, and what the restaurant records.

Explicit confirmation makes that connection visible. Separating language interpretation from booking authority lets the conversation remain flexible while the reservation rules stay predictable.

Testing also reinforced the value of measuring the complete outcome: the guest's acceptance, the stored reservation, message delivery, and the owner's view must agree.

How to experience the project

The submitted video combines a guided rehearsal, recorded real WhatsApp test evidence, and owner controls.

The hosted judge rehearsal uses real Amazon Bedrock inference and the shared booking engine with an isolated synthetic ledger. It sends no WhatsApp messages or emails and does not modify live reservations. Judges can explore the workflow, duplicate acceptance, and offer expiration through the supplied testing instructions.

What's next for TableAgain

The next step is a small restaurant pilot to measure cancellation recovery, time to confirmation, and staff effort against a form plus a rules-based waitlist.

Further work includes broader language evaluation, WhatsApp templates for messages outside the customer service window, and additional delivery-failure and recovery testing.

The product goal remains focused: help a restaurant turn a cancellation into a confirmed booking while respecting guest preferences and owner decisions.

Share this project:

Updates

Submission history