01
Executive summary
Connect the seat, the service and the intelligence loop.
The proposed functionality gives guests a mobile, venue-branded map from which they can select an exact table or seat for a future visit, a same-day visit or a high-demand event. In sports-oriented venues, the map can recommend seating based on which televisions will show a selected game and how well each table can view those screens.
Owners and managers decide which inventory is exposed, establish party-size and deposit rules, configure special-event policies, assign games to television zones, plan staff sections and retain authority over every live seating decision. Hosts, servers and support staff receive role-specific tasks from arrival through table reset.
The capability is strategically useful only if it remains connected to The Where’s core intelligence loop. Seating choice, game interest, arrival, service behavior and response become permissioned signals that can improve future guest recognition, room understanding and experience recommendations.
02
Product intent + boundaries
Useful control without overpromising the first build.
Objectives
- Give guests confidence and control when location materially affects the experience.
- Protect high-demand inventory with deposits, booking windows and cancellation rules.
- Give the host stand a time-aware view of reservations, availability and table readiness.
- Coordinate staff response without replacing human hospitality or creating alert noise.
- Capture permissioned preference and presence signals for guest and room intelligence.
- Support visibly distinct venue branding without separate codebases.
Explicit non-goals
- Do not select final architecture, APIs, schema, vendors, threat model or compliance approach in this brief.
- Do not imply that demo payments, refunds, orders, messages, controls or personal data are transmitted.
- Never expose guest identities or private notes on a public floor map.
- Never auto-release a late party without configured policy and authorized staff action.
- Do not become a full POS or kitchen-display system merely to demonstrate seat selection.
03
Experience model
Six users, one shared operating state.
| User | Primary responsibility |
|---|---|
| Guest | Find the right table or seat, understand the policy, reserve or check in, and use the visit portal. |
| Host | Control the floor, confirm arrivals and live seat requests, resolve conflicts, move parties and approve releases. |
| Server | See newly seated parties, relevant guest notes and service requests for assigned tables. |
| Support staff | Receive table-configuration and turnover tasks; mark reset work complete. |
| Manager | Plan service, adjust inventory, manage exceptions, rebalance staff and approve sensitive actions. |
| Owner / corporate | Set venue rules, configure permissions, review performance and compare locations. |
Guest journey A · advance booking
- Select date, time and party size.
- Select general dining, a game or a special event.
- Choose Best available or a specific table/seat.
- View only inventory released for that experience.
- Review capacity, view, accessibility, duration, deposit and policy.
- Place a short hold, complete booking and receive confirmation.
- Use a confirmation link or QR code to check in.
Guest journey B · same-day / in-venue
- Enter through the venue site/app or entrance QR.
- Choose I’m here now, party size and desired game.
- View inventory staff have released as available now.
- Select a location and submit a seating request.
- Receive host confirmation before proceeding.
- Move into the existing guest portal for approved visit functions.
Control rule
A public visitor may view simplified availability, but claiming a live table should require verified presence through an entrance QR code, host action or another approved check-in mechanism.
The guest map should show
- Guest-safe availability, selection, hold and unavailable states.
- Seating type, capacity, party minimum and adjacent-seat requirements.
- Best-view recommendations for a selected game or TV zone.
- Duration, deposit, cancellation/rescheduling terms and arrival grace before payment.
- Accessible seating information without unnecessary medical disclosure.
The guest map should never show
- Guest names, profiles, spending, reservation notes or unavailable reasons.
- Internal staff assignments, employee-only rooms, controls or notes.
- A promise that an illustrative integration, payment, order or message was transmitted.
04
Owner + manager experience
Configure before service. Retain authority during service.
A
Configure the physical venue
- Create/import rooms, zones, tables, seats, bars, booths, patios and bookable areas.
- Define capacity, minimums, seating type, accessibility and premium status.
- Create valid table combinations that block every underlying unit.
- Map television groups and operator-defined excellent, good or partial views.
- Create staff sections and shift templates with individual overrides.
B
Plan a service or event
- Choose exact inventory versus host-controlled inventory.
- Set booking windows, hold time, visit duration and turnover buffer.
- Set party, contiguous-seat, minimum-spend and deposit rules.
- Assign games to TV groups and publish seating recommendations.
- Override deposit, cancellation, transfer, arrival and no-show rules.
- Preview the guest experience before publishing.
C
Operate the live floor
- Monitor arrivals, live requests, late parties, holds and readiness.
- Check in, seat, move, split, combine or release with an audit trail.
- Reassign sections or tables as staffing changes.
- See time conflicts and future reservations before approving live requests.
- Create and verify turnover or modification tasks.
- Use manager override for authorized exceptions.
D
Learn from the room
- Measure demand by game, team, seating area and viewing zone.
- Compare arrival timing, dwell time, turns and no-shows by event or zone.
- Recognize repeated preferences for booths, bar seats or viewing experiences.
- Measure whether programming, seating or service changes improved response.
05
Staff workflows
Route the next action to the right role.
| Role | Workflow | Trigger | Expected action |
|---|---|---|---|
| Host | Arrival / seating | Reservation or walk-in checks in; exact-seat status and required host action are shown. | Confirm, assign, move, release or escalate. |
| Server | New table / request | A party is seated at an assigned table or sends an approved service request. | Acknowledge, respond and close the task. |
| Support | Turnover | Guest departure is confirmed or a future reservation requires a table modification. | Reset or reconfigure the table, then mark it ready. |
| Manager | Exception | Late arrival, floor conflict, staff imbalance, payment issue or operational override. | Resolve with reason, owner policy and audit trail. |
Critical status rule
A paid check does not mean the table is vacant. Staff must confirm departure before the table changes to Needs reset and support staff are alerted.
Orders versus service requests
The Where can directly manage simple service tasks such as Request a server, Need water or Report an issue. A true food or beverage order introduces menus, availability, modifiers, tax, payment, kitchen/bar routing and refunds. Production ordering should use an approved POS or ordering integration unless the CTO intentionally scopes a separate commerce layer.
Alert design principles
- Role-specific queues instead of every employee receiving every event.
- Priority and escalation for unacknowledged requests.
- In-app alerts first; SMS, push or other channels only when justified and permissioned.
- Quiet, clear changes usable one-handed during a busy shift.
- An activity log showing who changed a reservation, table, policy, assignment or override and when.
06
Shared floor + inventory model
Physical state, future inventory and live service are related—not identical.
A table may be occupied now, reserved later and still usable during a shorter interval. Availability must use time windows, expected duration and reset buffer rather than a single status flag.
| Layer | Representative entities |
|---|---|
| Physical | Venue, room, zone, table, seat, bar position, television, television group and access attribute |
| Configuration | Table combinations, view ratings, party limits, service durations, turnover buffers and staff sections |
| Inventory | Bookable window, released inventory, blocked inventory, soft hold, exact-seat promise and general allocation |
| Reservation | Party, organizer, contact, seat/table assignment, event/game, deposit, policy version and check-in status |
| Visit | Arrival, seating, requests, order or integration references, check status, departure and turnover |
| Intelligence | Permissioned preference, presence, room response, recommendation, operator action and measured result |
Reservation lifecycleSelecting → Soft held → Confirmed → Due → Arrived → Seated → CompletedAlternates: Expired hold, Canceled, Rescheduled, Late, Release eligible, Released or No-show.
Table lifecycleClosed / blocked → Ready → Held → Occupied → Departed → Needs reset → ReadyA current table session and future reservation may coexist.
07
Functional requirements registry
Requirements for estimation—not premature architecture decisions.
The identifiers below support discovery discussion and effort estimation. “Production dependency” identifies what must be validated before a live promise can be made.
Guest + booking
| ID | Requirement | Production dependency |
|---|---|---|
| G-01 | Support general reservations, paid exact-table reservations and seat-level selection where enabled. | Inventory model and reservation source of truth |
| G-02 | Filter availability by date, time, party size, event/game and seating rules. | Time-aware availability engine |
| G-03 | Display a touch-friendly, zoomable venue map with simplified guest-safe statuses. | Floor-plan renderer and accessibility QA |
| G-04 | Show table/seat detail, game visibility, duration, deposit and policy before confirmation. | Venue configuration and policy engine |
| G-05 | Create an expiring checkout hold that prevents conflicting purchases. | Atomic inventory lock and concurrency handling |
| G-06 | Allow Best available when the guest does not want to choose a specific location. | Allocation logic and host override |
| G-07 | Support entrance-verified I’m here now selection with host confirmation. | QR/check-in security and live sync |
| G-08 | Separate required transactional contact from optional marketing consent. | Consent records and identity model |
Owner + operations
| ID | Requirement | Production dependency |
|---|---|---|
| O-01 | Owners define rooms, tables, seats, combinations, television groups and view ratings. | Authoring workflow or import format |
| O-02 | Owners release only selected inventory by shift, event or time window. | Permissioned inventory controls |
| O-03 | Policies support venue defaults plus event-specific overrides. | Versioned policy engine |
| O-04 | Managers assign staff by section, table or individual seat with reusable templates. | Shift/role model and device permissions |
| O-05 | Hosts check in, seat, move, combine, release and override with an activity log. | Real-time state service and audit log |
| O-06 | Servers receive assigned-table and service-request tasks without duplicate alert noise. | Task routing, acknowledgement and escalation |
| O-07 | Support staff receive departure/reset and table-modification tasks. | Departure confirmation and task completion |
| O-08 | Managers see conflicts, late arrivals, delayed turns and section imbalance. | Forecasting rules and live telemetry |
Platform, data + integrations
| ID | Requirement | Production dependency |
|---|---|---|
| P-01 | One shared functionality layer supports venue-specific themes, copy, imagery, floor plans and terminology. | Multi-tenant configuration and design-token architecture |
| P-02 | The interface is usable on guest phones, an 11-inch iPad host stand and staff phones. | Responsive and touch QA |
| P-03 | Payments support deposit capture, refund/forfeit decisions and application to the final tab. | Processor and POS reconciliation design |
| P-04 | Sports/game data can be entered manually or supplied by an approved data source. | Licensing, API availability and cost |
| P-05 | Television assignments may remain advisory or connect to an approved control system. | AV vendor capability and hardware review |
| P-06 | All integrations disclose permissions, tested actions, rate limits, failure behavior and operating cost. | Vendor discovery and written integration matrix |
| P-07 | Guest signals follow retention, deletion, opt-out and identity-confidence rules. | Privacy/security design and legal review |
| P-08 | AHA insights show claim, evidence, recommendation, action and source; external actions require approval. | Explainability and authorization controls |
| P-09 | The system remains useful during degraded Wi-Fi or an integration outage. | Offline/degraded-mode requirements |
08
Venue-specific design
Make every restaurant feel distinct without forking the product.
CCSP is the first visual implementation, using its approved demo design. Functional components should remain separate from presentation so another restaurant can use identical behavior while feeling materially different.
Brand tokens
Logo, colors, typography, corner radius, borders, shadows, buttons and icons
Content tokens
Terminology, policies, events, games, help and confirmation language
Media
Photography, textures, map background, screens and decorative motifs
Floor data
Rooms, sections, table geometry, seats, TV groups, accessible paths and combinations
Interaction configuration
Booking modes, optional-step order, service requests and owner controls
- Do not fork the application for every restaurant.
- Keep business rules, state and interactions in shared components.
- Load venue presentation through documented theme/configuration architecture.
- Create uniqueness through typography, spacing, surfaces, geometry, imagery, icons and language—not only color.
- Preserve recognizable patterns so staff training and QA do not multiply.
- Validate illegible color combinations, missing assets and long labels.
Design objective
A restaurant should feel that the experience belongs to its brand, while The Where maintains one supportable product underneath.
09
Draft policy assumptions
Discussion values for the visual demo.
These values are not finalized restaurant policy or production requirements.
| Policy area | Draft assumption | Reason / qualifier |
|---|---|---|
| Checkout hold | 5 minutes | Temporary inventory lock while the guest completes booking |
| Advance exact-seat deposit | $20 per guest | Credited to the final check; configurable by venue/event |
| Arrival grace | 15 minutes | Late reservation becomes release eligible; host retains authority |
| Cancellation / move | 24 hours | Same cutoff initially to prevent policy circumvention |
| Inside cutoff | Nonrefundable when clearly disclosed | Owner/manager may waive by policy or exception |
| Deposit application | Organizer’s master check | Split allocation deferred unless POS support is confirmed |
| Live seat claim | Host confirmed | Requires verified in-venue presence |
| Seat-level scope | Bar, communal, sports and event inventory | Ordinary dining remains table-level by default |
| Turnover trigger | Confirmed departure | Payment alone does not release the table |
10
Technical discovery + cost drivers
The decisions that materially change scope.
| Area | Question for CTO | Why it changes effort / cost |
|---|---|---|
| System role | Native module, integration layer or event-specific product? | Determines scope, ownership and long-term maintenance. |
| Source of truth | Which system owns reservation and live table availability? | Prevents conflicting inventory and duplicate operator work. |
| Floor plan | Custom editor, imported plan or configured SVG/JSON? | Large effect on first-build complexity and onboarding cost. |
| Concurrency | How are soft holds and conflicting seat selections resolved atomically? | Required before accepting money for exact inventory. |
| Payments | Which processor captures deposits, refunds and forfeitures? | Introduces transaction fees, reconciliation, disputes and compliance. |
| POS credit | Can the deposit be applied automatically to the guest’s tab? | May require venue-specific integration or a manual fallback. |
| Reservation partners | Can current systems read/write exact table or only time, party and area? | Determines whether The Where supplements or replaces workflows. |
| Real-time sync | WebSocket, polling, event bus or another model? | Affects reliability, hosting and simultaneous staff/guest updates. |
| Sports data | Manual schedule versus licensed sports/TV feed? | May add recurring API cost and usage restrictions. |
| TV control | Advisory assignment or direct control of AV hardware? | Direct control may require hardware, installers and vendor APIs. |
| Notifications | In-app, push, SMS or a combination? | Adds channel costs, permission handling and alert-delivery risk. |
| Presence | Entrance QR, host code, geofence or other verification? | Impacts fraud prevention, privacy and guest friction. |
| Identity | How does booking identity join the Guest Relationship Record? | Must preserve confidence, consent and marketing separation. |
| Security | What roles, auditability, payment boundaries and retention are required? | Affects architecture, compliance and support obligations. |
| Degraded mode | What works if Wi-Fi, POS or the reservation integration fails? | Busy service cannot depend on a perfect connection. |
| Multi-venue | What configuration is shared versus location-specific? | Determines scalability, onboarding and support effort. |
Direct and recurring cost categories to identify
- Payment processing, refunds, chargebacks and deposit reconciliation.
- SMS, push, email and other communication services.
- Sports schedule, broadcast/channel and television-programming data.
- Reservation, POS, ordering and AV-control access or partner fees.
- Hosting, real-time connections, logging, backups and monitoring.
- Floor-plan onboarding, venue configuration and television/view mapping.
- Security, payment-scope, privacy/legal and accessibility review.
- Ongoing integration, venue-change and event-configuration support.
11
Recommended phased scope
Prove the riskiest assumptions before scaling.
0
Visual demo
Interactive simulated CCSP guest, owner and staff flows; configurable visual system; illustrative data only.
Validate story, usability and sales value before engineering commitment.1
Technical prototype
One venue floor, time-aware mock inventory, concurrent holds, role views, sandbox payment flow and integration spikes.
Prove highest-risk assumptions and produce credible effort/cost ranges.2
Limited pilot
One live venue, approved reservation/POS path, real deposits, check-in, staff tasks, audit log and production safeguards.
Measure operational fit and price the add-on from real delivery cost.3
Expansion
Multi-location configuration, advanced TV/game automation, deeper intelligence, additional integrations and operator analytics.
Scale only after pilot evidence and repeatable onboarding.Visual demo scope
- Guest chooses a game, party size and exact CCSP table or seat.
- Guest reviews the $20 deposit, five-minute hold and event policy, then receives simulated confirmation.
- On-site guest scans a QR, sees released inventory and receives host approval.
- Manager assigns TV zones, releases inventory and applies event policy.
- Host checks in a reservation and the assigned server sees the new table.
- Service request, departure, reset task and table-ready workflow are simulated end to end.
- Owner sees guest, presence, room and experience signals with an explainable AHA recommendation.
- Every transactional action remains labeled simulated until a tested integration exists.
Potential swap / packaging analysis
Compare implementation cost and perceived owner value against current capabilities for reservations, event conversion, QR engagement, guest recognition, live room intelligence, service workflows and retention automation. Consider a swap only when the new module provides comparable value without a larger support or integration burden.
12
Pilot success measures
Measure value, operational fit and reliability.
| Category | Candidate measures |
|---|---|
| Guest | Map-to-booking conversion; exact-seat adoption; abandoned holds; cancellation/no-show rate; check-in time |
| Operations | Host interventions; inventory conflicts; table-ready accuracy; request response time; turnover time; staff adoption |
| Business | Protected deposit value; event covers; premium-inventory utilization; booking revenue; support cost |
| Intelligence | Permissioned preference capture; game/zone demand; recommendation acceptance; measured response after action |
| Reliability | Sync failures; integration errors; payment reconciliation exceptions; alert-delivery failures; degraded-mode usage |
13
CTO review requested
Return a practical feasibility recommendation.
- Recommended product boundary and architecture direction.
- Difficulty/effort band for each phase and highest-risk assumptions.
- Essential pilot integrations versus optional enhancements.
- Expected one-time and recurring third-party costs.
- Payment, security, privacy, accessibility and reliability implications.
- The least expensive technical spike proving exact-inventory holds, live sync and themed reuse.
- What the sales demo can simulate without constraining production architecture.
- Current The Where capabilities of comparable cost/value that could be exchanged.
- Inputs Amanda needs for discovery, pilot and ongoing-support pricing.
Expected discovery output
A written feasibility recommendation, phased effort range, integration/vendor list, direct-cost estimate, risk register and recommended production boundary.
A
Appendix A
Market reference patterns
These references illustrate established interaction or operational patterns. They are not endorsements and do not establish final competitive positioning.
Ticketmaster · interactive seat maps, filtering, availability and checkout timersTock · deposits, prepayment, waitlists and table/service managementSevenRooms · live floor, guest alerts, table status and POS-connected operationsOpenTable + Square · deposit application, table status and guest-profile synchronizationUpSalt · guest-selected tables and minimum-spend inventorySimple Host · exact-table selection and operator floor controlsGameView · venue floor-oriented television programming controlPubtelly · sports-content scheduling and guest preference signals
B
Appendix B
Working terminology
| Term | Working definition |
|---|---|
| Exact table | A guaranteed physical table assignment made under the venue’s published rules. |
| Exact seat | A specific seat, stool or position within enabled bar, communal, sports or event inventory. |
| General reservation | A date/time/party reservation for which the restaurant retains seating assignment flexibility. |
| Soft hold | A short-lived inventory lock while a guest completes a booking or payment. |
| Arrival grace | The period after reservation time before the booking becomes eligible for staff release. |
| Table session | The live operational record from seating through departure and reset. |
| Television group | One or more screens managed as a programming/viewing unit. |
| View rating | Operator-configured quality of a table or seat’s view of a television/group. |
| Known Guest | A recognized guest record; recognition does not itself equal marketing consent. |
| AHA | AI-generated interpretation presented with claim, evidence, recommendation, action and source. |