Guest flow
- Menu and ordering
- Delivery and pickup
- Payment
- Support enquiries
Executive summary
1. What the review found
A restaurant runs on short cycles: a guest order, a table booking, a task for the chef, a closed bill, a closed shift. A mistake here costs not money on paper but an unhappy guest in the room — and it surfaces at the moment when it is already too late to fix.
The review found that front of house, kitchen and the till hold different views of the same order. The status the waiter sees, the status in the kitchen and the status on the bill are reconciled by voice. While the cycle is short this works; at peak load it breaks down exactly when the cost of error is highest.
The second layer is the price of a dish. Recipe, purchase prices and actual consumption do not form one model, so decisions about price and margin are made on instinct rather than on a calculation.
| Finding | Statement |
|---|---|
| Primary constraint | The order status exists in three places at once — with the waiter, in the kitchen and at the till — and is reconciled verbally. The discrepancy is discovered by the guest. |
| Recommended first step | Introduce a single order and booking record with shared statuses for front of house, kitchen and till, then connect the recipe to actual cost. |
| Expected effect | Fewer verbal checks at peak, a verifiable margin per dish, a shift that closes without manual reconstruction. Quantitative effect is assessed after rollout. |
Areas reviewed
Front of house
- Table availability
- Confirmations
- Guest history
- Changes and cancellations
Kitchen and till
- Task queue
- Acceptance and completion
- Closing the bill
- Walk-in guests
Back office
- Working hours
- Recipes and semi-finished items
- Cost and margin
- Reporting
Starting position
2. Baseline capture of current work
The capture is done across a shift, not from a written procedure. For each operation we record who performs it, how often, which carrier holds the data, and whether the same data is moved again. Everything else in this document rests on this table.
| Operation | Who performs it | Frequency | Where the data lives | Re-keyed |
|---|---|---|---|---|
| Taking an order in the room | Waiter | Per guest | Notepad, then the till | Yes — items go into the till and are called through to the kitchen |
| Passing the order to the kitchen | Waiter | Per order | Verbally or on a paper slip | Yes — the kitchen keeps its own queue |
| Taking an online order | Floor manager | Through the day | A separate intake channel | Yes — the order is entered into the till again |
| Table booking | Host or floor manager | Continuously | Booking book, phone, messages | Yes — table availability is checked by hand |
| Changing or cancelling a booking | Host | Several times a day | Correction in the book | Yes — a freed table does not return to availability automatically |
| Closing the bill | Cashier or waiter | Per order | Till | Yes — on a discrepancy the contents are checked against the kitchen |
| Recording working hours | Shift manager | Daily | Paper timesheet or spreadsheet | Yes — hours are transferred into payroll by hand |
| Costing a dish | Head chef and bookkeeping | When prices change | A separate recipe spreadsheet | Yes — purchase prices are entered again |
| Closing the shift | Shift manager | Daily | A roll-up from till, timesheet and notes | Yes — data comes from three sources |
What follows from thisIn nine operations out of nine the data is moved again. The key observation: the order is not an object. It exists as a set of views agreed between people, and each view lives on its own carrier.
Diagnostic panel
3. State of the operational system
Losses occur at the seam between front of house, kitchen and till — and between the operating day and the management decision about price.
49/100average process maturityManual reconciliation risk high
9points of re-keyingCandidates for removal
6critical data handoversNeed an owner
2priority pilot flowsOrder + booking
Process maturity
Expert assessment on a 0–100 scale. Higher means a more resilient process.
Structure of operational risk
Distribution of recorded observations by type.
16observations
40% — scattered data32% — losses at handover28% — unclear ownership
The numbers on this demonstration panel are illustrative. In a paid review the assessments are derived from interviews, shift observation, a sample of bills and bookings, and an agreed 0–100 scale.
Process map
4. Current process and handover points
The chain describes the typical path of a guest order. It is a process model, not a snapshot of any particular client system.
Order
The guest orders in the room, online, or books a table.
Confirmation
Payment or booking confirmation is recorded.
Kitchen
The task reaches the chef and is accepted.
Service
The dish is served or handed to delivery.
Closing the bill
Contents and amount are recorded at the till.
Closing the shift
Hours, till and exceptions are brought together.
Costing
Actual cost is compared against the price.
Reporting
Margin and occupancy reach the management report.
Risks at the handover points
| Handover | What can be lost | Consequence | Priority |
|---|---|---|---|
| Guest → waiter | Dish modifications, allergens, order of service | The kitchen cooks something other than what the guest expects | Critical |
| Waiter → kitchen | Order contents, urgency, changes after firing | Statuses diverge between the room and the kitchen | Critical |
| Online channel → till | Items, address, ready time | The order is entered again and the ready time slips | High |
| Booking → table availability | A change or cancellation | The table is taken in the book and free in the room | High |
| Kitchen → till | What was actually served | The bill differs from what the guest received | High |
| Shift → payroll | Actual hours, cover shifts, overtime | The timesheet is reconciled by hand and disputed | Critical |
Risk heatmap
| Area | Likelihood | Impact | Detection | Result |
|---|---|---|---|---|
| Order status diverges between room and kitchen | High | Critical | By the guest at the table | Critical |
| Booking change not reflected in availability | Medium | High | When the guest arrives | High |
| Dish price disconnected from current cost | High | High | At month end | Critical |
| Working hours reconciled by hand | High | Medium | At payroll | High |
| Online order loses its ready time | Medium | High | At handover | High |
Root causes
5. Why this happens
Verbal checks at peak, disputed timesheets and an unknown margin share the same structural causes.
A. The order is not an objectFront of house, kitchen and till work with their own views of the same order. Synchronisation rests on voice and memory, so process quality drops exactly as load rises.
B. The booking does not drive availabilityThe booking book and physical occupancy are two independent facts. A cancellation frees the line in the book but not the table.
C. Costing is not a modelRecipe, semi-finished items and purchase prices are not connected by versions. The price of a dish stops matching its cost the moment purchasing changes, and nobody finds out.
D. Exceptions are handled in conversationA shift swap, a returned dish, a booking change and overtime have neither a queue nor an owner. They are reconstructed at shift close from the memory of those involved.
Decision principleA restaurant cannot be automated screen by screen. First a single work object has to exist — order and booking with shared statuses — and only then do kitchen, till, hours and costing hang off it. The reverse order produces four systems that have to be reconciled by hand all over again.
Responsibility zones
6. Who does what — and how much of it is moving data
In a restaurant the roles overlap physically: waiter, kitchen and till work in the same room at the same tempo. Below is where work is duplicated and where a role does not decide anything but calls information across.
| Role | What it does today | How much of that is moving data | Review observation |
|---|---|---|---|
| Waiter | Taking orders, serving, answering the guest, closing the bill | Double entry: notepad, till, and calling through to the kitchen | The order is captured once; the role keeps the work with the guest |
| Host | Taking bookings, seating, checking occupancy | Manual reconciliation of the book against actual occupancy | Availability is computed by the system; the role keeps greeting and seating |
| Kitchen | Keeping its own queue, cooking, plating up | The parallel queue duplicates the order contents | The queue comes from the order; the role keeps cooking and quality |
| Shift manager | Coordinating room and kitchen, resolving exceptions, closing the shift | A substantial share of the shift is verbal status synchronisation | Coordination moves into statuses; the role keeps resolving exceptions |
| Head chef | Recipes, purchasing, yield control | Re-entering purchase prices into the costing spreadsheet | Cost is computed from the costing card; the role keeps menu and quality |
| Bookkeeping | Consolidating timesheets, payroll, reporting | Manual transfer of hours and reconciliation against the till | Hours and till come from the closed shift |
The organisational conclusion stays with the companyThe review shows which part of the work is moving data and which part is deciding. What happens with the time freed up — redistributing tasks, retraining people or changing the rota — is the owner’s call. In hospitality the time freed for waiters and shift managers usually goes back to the guest rather than being cut.
Peak load is the real testAny solution here must be tested not on a quiet weekday lunch but on a Friday evening. A process that demands one extra action from a waiter at peak will not be followed — and within a week the staff are back to calling orders across the room. That constraint outweighs any feature.
Target operating model
7. States, boundaries and rules
The order passes through explicit states, visible in the same way to front of house, kitchen and till. Each one defines an owner, the required data and the condition for moving on.
| State | Owner | Required information | Transition condition |
|---|---|---|---|
| Created | Waiter, guest online, or host | Items, modifications, table or address, time | Order saved with validated menu items |
| Confirmed | System or floor manager | Payment or booking confirmation, ready time | Guest and kitchen see the same confirmation |
| In the kitchen | Chef | Contents, modifications, queue and priority | Task accepted by the chef |
| Ready | Chef | Completion mark, deviations from the contents | Front of house notified without calling across the room |
| Served | Waiter | What was actually served | Discrepancies recorded with a reason |
| Closed | Till | Final contents, amount, payment method | The bill matches what was served |
Boundaries of automation
The system should determine
- Whether a table is free at the requested time
- Which items are available by stock and the 86 list
- Whether what was served differs from the bill
- Who performs the next action on the order
- What a dish actually costs at current prices
The system should not decide
- Whether to compensate a guest for a mistake
- Whether to accept a returned dish
- Whether to put an item on the 86 list
- Whether to change a menu price
- Who is put on a shift
Rules, deadlines and escalation target
In a restaurant the deadline is measured in minutes, not days. A rule without a deadline and an addressee does not work on the floor at all.
| Rule | Deadline | Escalates to |
|---|---|---|
| An order cannot be saved without a table or address and a time | At the moment of entry | Blocking rule, no escalation needed |
| Task not accepted by the kitchen | 3 minutes from confirmation | Sous chef, then shift manager |
| Dish ready but not served | 5 minutes from the ready mark | Waiter, then shift manager |
| Booking cancelled — the table returns to availability | At the moment of cancellation | Automatic, the host is notified |
| Return or replacement recorded without a reason | Before the bill is closed | Shift manager |
| Shift not closed: hours, till or exceptions outstanding | By the end of the working day | Shift manager, then general manager |
| Purchase price changed — costing not updated | 1 working day | Head chef, then general manager |
Priorities and sequence
8. What to do and in what order
The sequence is built so that each stage can be verified on a single shift and does not require the next one to be finished.
| No. | Recommendation | Why now | Acceptance criterion |
|---|---|---|---|
| 1 | A single order and booking record | Removes verbal synchronisation between room, kitchen and till | All three roles see one status without calling across the room |
| 2 | A kitchen queue with acceptance and completion | Makes kitchen load visible before the guest starts waiting | Every task has an acceptance time, a chef and a ready mark |
| 3 | Table availability derived from bookings | Removes manual reconciliation of the book against reality | A cancellation returns the table to availability with no human action |
| 4 | A versioned costing card | Ties the price of a dish to actual purchase prices | Margin per dish is computed at current prices without a hand-kept sheet |
| 5 | Shift close derived from data | Removes the daily assembly from three sources | Hours, till and exceptions come together without manual reconstruction |
| Later | Demand forecasting and purchase planning | Useful once shift data is reliable | Order history is fit for forecasting across an agreed horizon |
Do not start with the guest appThe temptation to start with a beautiful menu and online ordering is strong, but an online channel plugged into an unsynchronised room and kitchen increases the number of manual checks rather than reducing it. Shared order status first, guest interface second.
Rollout plan
These durations are indicative for a demonstration sample. A real estimate is formed after observing a shift and gaining access to the till, the booking book and the recipes.
| Stage | Duration | Outcome | Checkpoint |
|---|---|---|---|
| Shift capture and order model | 2–3 weeks | Order and booking states, roles, required fields, exceptions | General manager and head chef approve the model |
| Order core and kitchen | 4–6 weeks | Single record, kitchen queue, statuses for room and till | One shift runs without verbal status handover |
| Bookings and availability | 2–3 weeks | Tables, confirmations, changes and cancellations | The booking book is no longer kept in parallel |
| Hours and shift close | 2–3 weeks | Timesheet, exceptions, period close | The shift closes without manual assembly |
| Costing and reporting | 3–4 weeks | Recipes, price versions, margin, management report | The pricing decision is made from a calculation |
Measuring the outcome
9. Metrics, reporting horizon and next step
This sample claims no numeric effect. In a real review the baseline is recorded first across several shifts, then the metrics are compared after an agreed period of use.
| Metric | How it is calculated | How to capture the baseline | Direction |
|---|---|---|---|
| Share of orders with no verbal check | Orders completed without a check between room and kitchen / all orders × 100 | Observation of two shifts: a weekday and a peak | Up |
| Time from confirmation to kitchen acceptance | Mean across the orders in a shift | Manual timing on a sample of orders at peak | Down |
| Divergence between bill and what was served | Bill corrections after service / all bills × 100 | A sample of corrected bills over two weeks | Down |
| Variance between planned and actual cost | (Actual − planned) / planned × 100 per dish | Recalculating ten core dishes at current purchase prices | Down |
| Time to close a shift | Minutes from the last bill to a closed shift | Measured across five consecutive shifts | Down |
| Corrections after shift close | Number of corrections to hours and till after closing | The correction log for a month | Down |
Horizon: from the order to the annual report
A review does not end when the bill is closed. Shift data has to reach management and annual reporting without being entered again — otherwise decisions about the menu and prices are made blind.
| Level | What must arrive without manual assembly |
|---|---|
| Shift | Orders, deviations, staff hours, revenue and exceptions |
| Week | Occupancy by day and hour, cancelled bookings, 86 lists |
| Month | Margin by dish and category, working-hours volume, wastage |
| Quarter | Menu performance, seasonality, cost by supplier |
| Year | Management reporting for the venue on one data model |
If a menu change is decided on "how popular it feels", that almost always means shift data does not reach the management level without being reassembled by hand.
Questions to settle before development
- Who may change the contents of an order after it has been fired to the kitchen?
- Who puts an item on the 86 list, and on what basis?
- How do dish modifications enter the cost calculation?
- What rules apply to a cancellation on the day of the visit?
- What data does the accounting software accept, and in what format?
- Which operations must keep working when the internet drops on the floor?
Recommended next decisionObserve two shifts — a weekday and a peak — logging every verbal check between room and kitchen. Output: the order state model, an exception list, a role matrix and a pilot scope for one shift.
This document demonstrates the structure and level of detail of the deliverable of the “Process review” service. It is based on the mechanics of a delivered, anonymised platform for a restaurant, is not legal, tax, food-safety or industry advice, and contains no confidential client information. Maturity scores are illustrative. Recommendations for a specific venue depend on the capture, the jurisdiction, the contracts and the existing systems.