A dashboard is a decision interface
A restaurant dashboard should shorten the path from a signal to a decision. A large number on a screen is not automatically useful. Before choosing charts, list the questions the owner and manager need to answer: are sales comparable with the plan, where is service pressure building, which commitments are overdue, and which data cannot yet be trusted?
Separate daily operations from weekly diagnosis and monthly financial reporting. The manager may need today’s reservations and staffing coverage. The owner may need trends, exceptions and unresolved risks. Combining all three layers on one screen creates noise. Start with a small view and add a metric only when someone can name the decision it supports and the action that follows.
Start with a decision
Write down the decisions the team makes daily or weekly: adjusting purchasing, changing a shift plan, following up on guest issues. Each dashboard block should help answer one of those questions.
Agree on definitions
Define the period, source, owner and refresh frequency for each metric. Separate gross sales from net revenue and scheduled hours from worked hours. Missing or stale data should be visible rather than silently replaced with zero.
Connect alerts to action
An alert needs a threshold agreed with the team, a recipient and a next step. Review whether alerts led to useful actions. Demonstration data is useful for discussing a layout, but cannot prove that a live integration or business result already exists.
A first scorecard and its formulas
For a restaurant, a first scorecard can include comparable net sales, transaction count, average spend, labour hours, food consumption, reservation outcomes and unresolved service issues. Average spend is sales divided by the matching transaction count. Revenue per labour hour is comparable sales divided by worked hours; it is a productivity indicator, not a complete measure of service quality.
For bookings, define confirmed, attended, cancelled and no-show before calculating rates. A no-show denominator should reflect the eligible reservations in that reporting period, with your cancellation rule explicit. Do not mix people, tables and reservations. For guest issues, show both new cases and unresolved age. A falling complaint count can reflect missing capture rather than improving service, so interpret it alongside other evidence.
Worked example: interpret a productivity change
Take a fictional week with THB 300,000 in comparable sales and 600 worked hours: revenue per labour hour is THB 500. The next week produces THB 330,000 with 550 hours, or THB 600 per hour. The indicator improves by 20%. That calculation is correct, but “we can cut more hours” does not automatically follow.
Check waiting times, overtime, errors, staff coverage and the mix of service channels. A large pre-booked group could explain the movement. So could understaffing whose damage appears later. Put the ratio next to its numerator and denominator and annotate unusual events. This makes it harder to optimise the chart at the expense of guests or staff. The example demonstrates arithmetic, not a target for every restaurant.
The metric passport: source, owner and freshness
For each metric, maintain its definition, source, time zone, refresh schedule, owner and reconciliation method. Mark whether it is preliminary or closed. A missing feed must appear as missing, not zero. Display the last successful update and the covered business period. A midnight calendar boundary may not match a venue whose evening service continues after midnight.
Agree how refunds, duplicate events and late corrections change the figures. Keep raw events or an auditable source where appropriate, and make transformations understandable. For a Koh Samui venue reporting to a remote owner, show the operating time zone and THB basis explicitly. If a presentation converts amounts into USD, distinguish that view from the original operating records.
Useful alerts need an owner and a next action
An alert rule needs a condition, recipient, action and closure rule. “Stock is low” is incomplete. A workable rule says which item crossed which agreed threshold, whether an order already exists, who checks it and when escalation occurs. The threshold should reflect lead time and operating demand, not a generic value copied from a demo.
Review false positives and duplicate notifications. If staff mute an alert channel, more alerts will not solve the problem. Group related signals and allow acknowledgement without pretending the underlying issue is resolved. Keep push and email preferences separate. In a demonstration, make it explicit that toggles illustrate behaviour and do not connect to live systems or send notifications.
Spreadsheet, dashboard or full integration?
A spreadsheet is a reasonable first step when volume is manageable and manual reconciliation is reliable. A dashboard helps when several people need the same current view. Integration becomes valuable when repeated copying causes delays or errors and the source systems expose dependable data. Automating an undefined metric makes mistakes faster, not decisions better.
Introduce the system in stages: agree definitions, reconcile a sample period, show the first view, test missing data and corrections, then add alerts. Can one screen replace financial reporting? No. Can an attractive demo prove a working connection? No. Judge readiness by observed data flow, permissions, recovery and the team’s ability to act on what the screen shows.
Sources and scope
ISO: quality management ↗
Process-management background. Formulas and numeric examples are explained in the article, not presented as industry benchmarks.