seatkit

SeatKit - Business Domain Model

Restaurant Operations Analysis & Requirements Context: Japanese-Venetian Restaurant (Koenji) - 18-20 seats total Last Updated: 2025-10-25

🏪 Restaurant Operations Overview

Physical Layout

Koenji Restaurant Layout:
┌─────────────────────────────────┐
│  DINING ROOM (14 seats)         │
│  ┌─┐ ┌─┐ ┌─┐ ┌─┐              │
│  │2│ │2│ │4│ │2│  Tables        │
│  └─┘ └─┘ └─┘ └─┘              │
│  ┌─┐ ┌─┐                       │
│  │2│ │2│                       │
│  └─┘ └─┘                       │
│                                 │
│  COUNTER BAR (4-6 seats)        │
│  ████████████████████           │
│  Counter with sake/wine         │
└─────────────────────────────────┘

Total Capacity: 18-20 guests
Peak Times: Lunch (12:00-14:00), Dinner (19:00-22:00)

Business Characteristics

👥 User Personas & Workflows

1. Host/Hostess - “The Traffic Controller”

Role: Manages incoming reservations, seating decisions, guest experience

Daily Workflow:

08:00-10:00  Review day's reservations, spot conflicts
10:00-11:30  Take phone reservations for lunch
11:30-15:00  LUNCH SERVICE - seat guests, manage waits
15:00-18:00  Take dinner reservations, prep for evening
18:00-23:00  DINNER SERVICE - seat guests, manage flow
23:00-24:00  Review day, enter any final changes

Key Pain Points:

Success Metrics:

2. Server - “The Table Manager”

Role: Manages assigned tables, guest requests, service timing

Key Interactions with System:

Critical Needs:

3. Manager - “The Operations Optimizer”

Role: Oversees service, handles complex situations, analyzes performance

Key Workflows:

Authority Levels:

4. Owner - “The Business Strategist”

Role: Understands business performance, makes strategic decisions

Analytics Needs:

🎯 Core Business Entities

Reservation Entity

The heart of the system - represents a guest booking

interface Reservation {
	// Identity
	id: string;

	// Guest Information
	name: string;
	phone: string;
	numberOfPersons: number;

	// Timing
	dateString: string; // "2025-10-25"
	startTime: string; // "19:30"
	endTime?: string; // "21:00" (calculated or manual)

	// Classification
	category: 'lunch' | 'dinner' | 'noBookingZone';
	type: 'walkIn' | 'inAdvance' | 'waitingList';

	// Status Management
	status:
		| 'pending'
		| 'confirmed'
		| 'canceled'
		| 'noShow'
		| 'showedUp'
		| 'late'
		| 'toHandle'
		| 'deleted';
	acceptance: 'confirmed' | 'toConfirm' | 'na';

	// Special Information
	specialRequests?: string;
	dietaryRestrictions?: string;
	language?: 'italian' | 'english' | 'japanese';

	// Visual/UX
	colorHue?: number; // For visual distinction

	// System Metadata
	createdAt: Date;
	lastEdited: Date;
	editedBy?: string;
}

Business Rules:

Table Entity

Physical restaurant tables with capacity and positioning

interface Table {
	// Identity
	id: string;
	name: string; // "Table 1", "Bar Seat 3"

	// Capacity
	minCapacity: number; // Minimum comfortable seating
	maxCapacity: number; // Maximum possible seating

	// Physical Properties
	position: { row: number; column: number };
	isVisible: boolean; // Can be hidden for maintenance

	// Relationships
	adjacentTables?: string[]; // Can be combined for larger parties
	cluster?: string; // Tables that work together

	// Metadata
	notes?: string; // "Window table", "Near kitchen"
	type: 'dining' | 'bar' | 'private';
}

Table Assignment Logic:

  1. Best Fit: Match party size to table capacity (avoid waste)
  2. Time Optimization: Consider turnover and next reservations
  3. Guest Preference: Window seats, bar vs dining, accessibility
  4. Operational Efficiency: Server stations, kitchen proximity

Sales Entity

Financial tracking for business performance

interface SaleCategory {
	id: string;
	date: string;
	type: 'lunch' | 'dinner';

	// Core Sales Metrics
	letturaCassa: number; // Cash register reading
	fatture: number; // Invoice total
	yami: number; // Food waste (cost)
	yamiPulito: number; // Net waste (after adjustments)

	// Service-Specific Metrics
	bento?: number; // Lunch special sales (lunch only)
	cocai?: number; // Dinner cocktails (dinner only)
	persone?: number; // Guest count (lunch only)

	// Calculated Fields
	totalSales: number; // Computed from core metrics
	averageSpend?: number; // Total / guest count (when available)

	// Metadata
	enteredBy: string;
	enteredAt: Date;
	modifiedBy?: string;
	modifiedAt?: Date;
}

Sales Business Rules:

Session Entity

Active user sessions for collaboration

interface Session {
	id: string;
	userId: string;
	userName: string;

	// Device Information
	deviceName: string;
	deviceType: 'mobile' | 'desktop' | 'tablet';

	// Activity State
	isActive: boolean;
	isEditing: boolean;
	editingEntity?: {
		type: 'reservation' | 'table' | 'sales';
		id: string;
	};

	// Timestamps
	loginTime: Date;
	lastActivity: Date;

	// UI State
	currentView: 'timeline' | 'list' | 'layout' | 'sales';
	profileImageURL?: string;
}

Collaboration Rules:

Profile Entity

User accounts and preferences

interface Profile {
	id: string; // Apple ID or generated UUID

	// Personal Information
	firstName: string;
	lastName: string;
	email: string;
	phone?: string;

	// Role & Permissions
	role: 'staff' | 'manager' | 'owner';
	permissions: {
		canEditReservations: boolean;
		canDeleteReservations: boolean;
		canAccessSales: boolean;
		canEditSales: boolean;
		canManageUsers: boolean;
	};

	// Preferences
	language: 'italian' | 'english' | 'japanese';
	defaultView: 'timeline' | 'list' | 'layout';
	notifications: {
		reservationChanges: boolean;
		salesReminders: boolean;
		systemUpdates: boolean;
	};

	// Visual
	profileImageURL?: string;
	avatarColor?: string;

	// System
	devices: Device[];
	createdAt: Date;
	lastLogin: Date;
	isActive: boolean;
}

🔄 Business Processes

1. Reservation Lifecycle

graph TD
    A[Phone Call/Walk-in] --> B{Available Slot?}
    B -->|Yes| C[Create Reservation]
    B -->|No| D[Check Waitlist/Alternative]

    C --> E[Pending Status]
    E --> F{Guest Confirms?}
    F -->|Yes| G[Confirmed Status]
    F -->|No| H[Canceled Status]

    G --> I[Service Day]
    I --> J{Guest Shows?}
    J -->|Yes| K[Showed Up]
    J -->|No| L[No Show]
    J -->|Late| M[Late Status]

    K --> N[Table Assigned]
    N --> O[Service Complete]

State Transitions:

2. Table Management Process

graph TD
    A[Guest Arrives] --> B{Reservation Exists?}
    B -->|Yes| C[Find Reserved Table]
    B -->|No| D[Walk-in Process]

    C --> E{Table Ready?}
    E -->|Yes| F[Seat Guests]
    E -->|No| G[Find Alternative/Wait]

    D --> H{Available Table?}
    H -->|Yes| I[Assign Table]
    H -->|No| J[Waitlist/Decline]

    F --> K[Update Status: Seated]
    I --> K
    K --> L[Service Begins]
    L --> M[Update Progress]
    M --> N{Service Complete?}
    N -->|No| M
    N -->|Yes| O[Table Available]

3. Daily Operations Cycle

Pre-Service Preparation:

  1. Review day’s reservations
  2. Check for special requests/dietary needs
  3. Identify potential overbookings or gaps
  4. Brief staff on VIP guests or large parties
  5. Configure system for service period

During Service:

  1. Seat guests according to reservations
  2. Handle walk-ins and changes
  3. Monitor table turnover timing
  4. Update reservation statuses
  5. Coordinate with kitchen on timing

Post-Service Cleanup:

  1. Mark no-shows and late arrivals
  2. Enter sales data
  3. Archive completed reservations
  4. Review day’s performance
  5. Plan for next service

📊 Business Intelligence Requirements

Key Performance Indicators (KPIs)

Revenue Metrics:

Operational Metrics:

Guest Experience Metrics:

Reporting Requirements

Daily Reports (End of Service):

Weekly Reports (Management Review):

Monthly Reports (Business Planning):

⚡ Real-Time Collaboration Requirements

Multi-User Scenarios

High-Frequency Conflicts:

Conflict Resolution Strategy:

Real-Time Update Priorities

Critical (Immediate Propagation):

Important (Within 5 seconds):

Low Priority (Within 30 seconds):

🎨 User Experience Priorities

Mobile-First Design (Staff Phones)

Desktop Enhancement (Manager Stations)

Cross-Platform Consistency

🔧 Configuration Requirements

Restaurant Setup

interface RestaurantConfig {
	// Basic Information
	name: string;
	address: string;
	phone: string;
	email: string;

	// Operating Hours
	hours: {
		[day: string]: {
			lunch?: { open: string; close: string };
			dinner?: { open: string; close: string };
			closed?: boolean;
		};
	};

	// Reservation Settings
	reservationPolicy: {
		advanceBookingDays: number; // How far ahead to allow bookings
		minimumNoticeHours: number; // Same-day booking cutoff
		defaultDurationMinutes: number; // Standard reservation length
		maxPartySize: number; // Largest party without approval

		// Time Slots
		lunchSlots: string[]; // Available lunch times
		dinnerSlots: string[]; // Available dinner times

		// Policies
		allowWalkIns: boolean;
		requirePhone: boolean;
		requireEmail: boolean;
	};

	// Table Configuration
	tables: Table[];

	// Sales Categories
	salesCategories: {
		lunch: string[]; // What to track for lunch
		dinner: string[]; // What to track for dinner
	};

	// Staff Permissions
	defaultPermissions: {
		[role: string]: PermissionSet;
	};
}

Multi-Restaurant Vision

Future support for restaurant groups:

This domain model forms the foundation for all technical decisions and feature development. It represents the real-world complexity of restaurant operations while providing clear structure for the TypeScript implementation.

This site is open source. Improve this page.