01 — Reservations + voice IVR · 2026

Chef Vola's

Private, phone-first reservations

Designed and built a private, phone-first reservation system for an exclusive Atlantic City restaurant — a cloned-voice phone line that takes requests, and a calm iOS app where chef Lou reviews availability and confirms every table by hand.

Product designer + design engineer + solo builder — strategy, domain modeling, backend, telephony, design system, and the iOS app, directing AI coding agents end-to-end.
Home — what needs the chef right now
Home — what needs the chef right now
The problem

An exclusive restaurant runs reservations as a relationship, not a transaction. There's no public booking widget — regulars call, and the chef decides. That intake is fragile: calls get missed, the room's real capacity lives in one person's head, and there's no record of who a guest is. The system had to answer gracefully, know whether a requested time can actually be seated, and let chef Lou decide fast — often one-handed, mid-service, in low light — without ever pretending a request is a confirmed booking.

What I designed & built

A cloned-voice phone line

The public number forwards into an automated Twilio line. Press 1 transfers to the front desk; Press 2 collects a future request — name (voice recording + transcription), cell, date, time, party size — plays a “request only, not confirmed until we call you” disclaimer, and writes a pending reservation. Greetings use cloned family voices so the automated line still sounds like the house.

Calm, branded auth
Calm, branded auth

A server-side availability engine

All capacity logic lives in SQL so the app and the IVR can never disagree. Rolling 40-minute seating slots, each capped and deliberately staggered so the kitchen isn't slammed. A requested time maps to the nearest slot; if it's full, the engine returns same-night alternatives, closest-to-requested first. Only confirmed reservations consume capacity — a pending request never holds a table.

Tonight — per-slot capacity
Tonight — per-slot capacity

The owner's daily tool

A two-second triage Home surfaces what needs the chef right now. The Requests inbox leads each card with the availability verdict — available, tight, or closed — then guest, party size, and requested time mapped to a slot. The decision screen adds a capacity meter, tappable alternative-slot chips, the caller's own name recording and transcript, and a sticky Book / Call / Cancel bar. Nothing auto-confirms; booking is Lou's deliberate act.

Home · two-second triage
Home · two-second triage
Requests · availability verdicts
Requests · availability verdicts
The decision screen
The decision screen

A discreet maître d's book

Guests carry a private 1–5 rating, free-text notes (allergies, “corner booth”), and visit history — presented with discretion, never like a credit score. Owner-only settings hold seating config, one-off closure and cap overrides, and staff roles. The whole system is a bespoke, dark-first “quiet luxury” token set built from the restaurant's monochrome brand.

Guests · a discreet book
Guests · a discreet book
Craft highlights
/

Domain-model first — hours, slot math, caps, and the reservation lifecycle were modeled in the database first, so the design expresses real business rules rather than invented happy paths.

/

One source of truth for capacity: availability is computed server-side in SQL and consumed identically by the app and the phone line.

/

Design that explains its verdict — the UI never just says “full,” it shows why (e.g. 38/40 committed) so the chef trusts the engine under time pressure.

/

Quiet luxury, one-handed — 44pt minimum targets, a 12px type floor, thumb-reachable primary actions, legible at arm's length on a dark floor.

Impact

Turned a fragile, phone-only intake into a reliable request pipeline that never loses a caller — while keeping the chef's personal-confirmation ritual intact.

Gave a non-technical owner a two-second read on the state of his room, replacing a single-number home screen.

Encoded the restaurant's real seating model into a server-side engine both the app and phone line obey — so availability is never ambiguous or contradictory.