Week 3 Day 04 Hospitality Domain Generated by Gemini Code Assist

Integrated Service Request Architecture

Detailed operational flow and sequence diagram for the Guest-to-Staff closed-loop system.

Operational Flow Overview

The application flow is designed as a closed-loop system where a Guest's Input triggers a database Event, which updates the Staff's View, leading to an Action that returns a Status Update to the Guest.

1. Customer (Guest) Application Flow

The guest flow focuses on minimal friction: Select → Customize → Track.

1

Login & Dashboard (Home Screen)

  • Input: Guest opens the app.
  • System Action: Fetches Users profile data.
  • Screen Display: Welcome message (Users.name), Room Number, and Service Category Tiles.
  • Message Passed: Clicking a tile passes service_type (e.g., HOUSEKEEPING) to the request form.
2

Service Request Screen

  • Input: Guest selects Item, Quantity, and adds Notes.
  • Message Passed to Backend:
    { guest_id: "123", service_type: "HOUSEKEEPING", status: "PENDING", details: {...} }
  • Return Info: Database returns unique request_id (e.g., #REQ-101).
3

"My Activity" Tracking

  • Trigger: Auto-redirects after submission.
  • System Action: Queries Master_Requests for guest_id.
  • Real-Time Update: Listens for status changes (PENDING → IN_PROGRESS → COMPLETED).

2. Service Provider (Staff) Application Flow

The staff flow focuses on triage and execution: Filter → Review → Update.

1

Staff Operations Dashboard

  • System Action: Authenticates staff and identifies department.
  • Data Retrieval: Queries Master_Requests where status != COMPLETED.
  • Screen Display: List showing Room Number, Request Type, and Time Elapsed.
  • Message Passed: Tapping passes request_id to Detail View.
2

Task Detail Screen (Dynamic)

  • Input: System fetches data from Detail tables using request_id.
  • Screen Display: Guest Info, Specifics (2x Towels), Alerts.
  • Action: Staff clicks "Accept Task".
  • Message Passed: Updates Master_Requests status to 'ASSIGNED'.
3

Completion & Closure

  • Action: Staff delivers items and clicks "Mark Complete".
  • Message Passed: Updates Master_Requests status to 'COMPLETED'.
  • Result: Item removed from Dashboard; Push notification sent to Guest.

3. Visual Sequence Diagram (Message Flow)

The following diagram captures the exact messages passed between the Guest Screens, the Database (Backend), and the Staff Screens during a lifecycle of a request.

Google Cloud serverless architecture diagram
sequenceDiagram participant Guest as Guest User participant G_App as Guest App (Screens) participant DB as Backend Database participant S_App as Staff App (Screens) participant Staff as Service Provider Note over Guest, DB: PHASE 1: CREATION Guest->>G_App: Opens App (Dashboard) G_App->>DB: Get User Profile (Room 101) DB-->>G_App: Return {Name: "John", Room: "101"} Guest->>G_App: Selects "Housekeeping" Tile G_App->>G_App: Render Housekeeping Request Screen [2] Guest->>G_App: Input: {Item: "Towels", Qty: 2, Note: "Allergy"} Guest->>G_App: Clicks "Submit" G_App->>DB: WRITE Request
{type: "HOUSEKEEPING", status: "PENDING", details...} DB-->>G_App: Return success (request_id: #101) DB-->>S_App: Real-time Sync (New Document Created) Note over DB, Staff: PHASE 2: FULFILLMENT S_App->>DB: Query: status != COMPLETED & dept = HOUSEKEEPING DB-->>S_App: Return List: [{#101, Room 101, "Towels", Time: 1m}] S_App->>Staff: Render Dashboard List [4] Staff->>S_App: Selects Request #101 S_App->>DB: Fetch Details (Housekeeping_Details) DB-->>S_App: Return {Qty: 2, Note: "Allergy Alert"} S_App->>Staff: Render Task Detail Screen [5] Staff->>S_App: Clicks "Accept Task" S_App->>DB: UPDATE #101 SET status = "ASSIGNED" [6] DB-->>G_App: Real-time Update: status = "ASSIGNED" Note over Guest, Staff: PHASE 3: COMPLETION Staff->>S_App: Clicks "Mark Complete" S_App->>DB: UPDATE #101 SET status = "COMPLETED" [6] DB-->>G_App: Real-time Update: status = "COMPLETED" G_App->>Guest: Notification: "Your towels have arrived!" DB-->>S_App: Remove #101 from Dashboard View

Automated Hospitality Task Routing and Staff Assignment Logic

Based on the provided architecture and workflow documents, the app handles staff assignment through a hybrid model of automated departmental routing and individual self-assignment (claiming).

1. Automated Departmental Routing (The "Push")

Before a specific person is assigned, the system's business logic first routes the request to the correct team.

  • AI Categorization: When a request is generated (either by a guest or an IoT sensor), the system identifies the service_type (e.g., HOUSEKEEPING, MAINTENANCE).
  • Workflow Orchestration: AI agents route the ticket directly to the appropriate department's queue without human intervention.
  • Unified Inbox: AI-driven tools gather messages from all platforms (e.g., WhatsApp) into a central inbox for filtering.

2. Staff Dashboard & Task Claiming (The "Pull")

Once routed to the correct department, the application relies on a "pull" mechanism where staff members claim tasks.

  • Departmental Filtering: Staff Operations Dashboard filters Master_Requests (e.g., status != COMPLETED AND service_type == HOUSEKEEPING).
  • Visibility: Staff view a high-level list showing Room Number, Request Type, and Time Elapsed.
  • The "Accept Task" Action: Staff members open the Task Detail Screen and click "Accept Task" to assign it to themselves.

3. Database Logic & Status Updates

The assignment is formalized in the database the moment the staff member accepts the task.

  • Status Transition: Clicking "Accept Task" changes status from 'PENDING' to 'ASSIGNED'.
  • Identity Linking: Updates assigned_staff_id with the current user's ID, locking the task to that employee.
Stage Action System Status
1. Routing Guest/Sensor creates request. System tags service_type. status: PENDING
2. Triage Request appears on the Staff Dashboard of the relevant department. status: PENDING
3. Assignment Staff member reviews details and clicks "Accept Task". status: ASSIGNED / assigned_staff_id: [ID]
4. Execution Staff performs service and clicks "Mark Complete". status: COMPLETED

Hospitality Intelligence: Architecting Real-Time Service Urgency

Based on the architectural design and industry insights, the staff dashboard prioritizes urgent guest service requests through a combination of visual indicators, AI-driven routing, and severity classification.

1. Visual Urgency Indicators

Real-time visual cues based on Service Level Agreements (SLAs).

  • Time Elapsed: Counter displayed for every active ticket.
  • Traffic Light System: Green (< 10 mins) vs Red (> 30 mins).

2. Severity Classification

Classifying the nature of the problem to sort by importance.

  • Severity Levels: LOW, MEDIUM, HIGH (e.g., pipe burst vs loose handle).
  • Task Pinning: High-severity items pinned to the top.

3. AI-Driven Automated Routing

Bypassing general pools to route urgent items to specialists.

  • Direct Orchestration: Instantly creates tickets in specific department views.
  • Intelligent Escalation: Re-routes unassigned tickets past a threshold.

4. IoT & Automated Flags

Distinguishing machine-reported issues from human reports.

  • Automated Flags: Uses is_automated flag.
  • Proactive Alerts: Noise sensors or leak detectors generate instant, prioritized tickets.

5. Guest Status Prioritization (CRM)

Integrating with CRM to display guest profiles and loyalty status (e.g., "Elite" members) directly on the ticket for hyper-personalized triage.