---
id: 8c4f1a72-6e3b-4d91-9f2a-3b7d1c6e5a88
name: Analyze kitchen performance
kind: OperationalAnalytics
cron: 0 0 8 * * *
analysis_window: 90d
comparison_periods: [7d, 28d]
---

Analyze **kitchen performance** to improve operational efficiency, reduce ticket times, and identify bottlenecks, recall-heavy workflows, and service inefficiencies.

The process should evaluate kitchen workflow across stations, employees, and service conditions using historical operational data from the last **90 days only**.

The output must contain **kitchen performance insights only**, without explanations or descriptions of methodology.

## Known Tables & Columns

### `curated.kitchen_orders`
- `guid` (varchar, PK) - order identifier
- `store_guid` (varchar) - which store/restaurant
- `preparation_time` (int, seconds, nullable) - total order preparation time
- `items_count` (int) - number of items in order
- `order_type` (varchar) - DINE_IN, TO_GO, DELIVERY
- `destination` (varchar) - Kitchen, Bar, Window, Expo
- `server_name` (varchar) - order taker or server name
- `done` (tinyint) - whether order is complete
- `is_deleted` (tinyint) - soft delete flag
- `create_time` (int, unix timestamp) - when order was created
- `update_time` (int, unix timestamp) - last update

### `curated.kitchen_order_items`
- `guid` (varchar, PK) - item identifier
- `order_guid` (varchar, FK) - parent order
- `name` (varchar) - menu item name
- `category` (varchar) - menu category for aggregation
- `device_id` (int) - KDS station identifier
- `is_priority` (tinyint) - item priority flag
- `preparation_time` (int, seconds, nullable) - item preparation duration
- `recall_time` (int, unix timestamp, nullable) - when item was recalled
- `is_deleted` (tinyint) - soft delete flag
- `create_time` (int, unix timestamp) - when item was created

### `curated.kitchen_item_status_events`
- `guid` (varchar, PK) - event identifier
- `item_guid` (varchar, FK) - parent item
- `status` (tinyint) - 0=pending, 1=prepared, 2=done
- `last_status` (tinyint, nullable) - previous status
- `prepared_local_time` (int, unix timestamp, nullable) - when item was prepared
- `done_local_time` (int, unix timestamp, nullable) - when item was completed
- `prepared_device_id` (int, nullable) - station that prepared item
- `done_device_id` (int, nullable) - station that completed item
- `is_deleted` (tinyint) - soft delete flag
- `create_time` (int, unix timestamp) - when status event was created

## Analysis Approach

### Stage 1 — Ticket Time Analysis by Menu Category
Extract completed order and item timing data from the last **90 days** using `curated.kitchen_orders` joined to `curated.kitchen_order_items`.

Aggregate:
- average order `preparation_time` per menu category
- average item `preparation_time` per menu category
- ticket time variability
- slowest categories contributing to delays.

### Stage 2 — Bottleneck Station Detection
Analyze station workload using `curated.kitchen_order_items` and, when useful, `curated.kitchen_item_status_events`.

Identify:
- stations (`device_id`) with highest average item preparation times
- stations causing queue buildup
- structural bottlenecks in workflow between stations.

### Stage 3 — Recall and Rework Analysis
Compute recall and rework signals using `curated.kitchen_order_items` and `curated.kitchen_item_status_events`.

Aggregate by:
- station
- category

Identify:
- highest recall rate stations
- menu categories with repeated rework
- correlation between workload and recalls or stalled status progression.

### Stage 4 — Rush vs Non-Rush Performance
Use order `create_time` to classify periods into service windows such as:
- rush
- non-rush

Compare:
- ticket times
- recall rates
- station throughput

Identify degradation during rush periods.

## Kitchen Optimization Insights

Kitchen Performance Dashboard:
- Average ticket time: 18 min (target: 15 min)
- On-time completion: 87%
- Recall rate: 3.2%

## Output Constraints

- Use historical data from the **last 90 days** only.
- Prefer aggregated summaries.
- Avoid more than **3 database queries** unless necessary.
- Return **kitchen performance insights only**.
- **Do not include explanations, reasoning, or methodology**.

## Output Format

Return structured kitchen performance results.

Example structure:

Kitchen Performance:
- Ticket Time:
  - Category: Burgers → 12.4 min avg
  - Category: Salads → 6.1 min avg

- Bottlenecks:
  - Grill Station → highest delay contribution
  - Fry Station → peak congestion periods

- Recall / Rework:
  - Grill Station → 3.2% recall rate
  - Fried Sides → highest rework concentration

- Rush vs Non-Rush:
  - Rush: +35% ticket time increase
  - Non-Rush: stable performance