The data problem in restaurants today
The average restaurant generates more data per shift than a small e-commerce store: every ticket, every modifier, every void, every clock-in. Yet most operators check their numbers weekly with the accountant — too late to act on anything.
The gap isn’t a data gap. It’s a timing gap and a focus gap. Modern POS systems already capture everything you need; the question is whether you’re looking at the right metrics often enough to act.
The 8 metrics that actually matter
Most analytics dashboards bury the signal in noise. These are the eight numbers we’d run a restaurant on if we could only have eight:
Prime cost
Food cost + labor cost, as a percentage of net sales. The single most important number in restaurant operations. Track weekly. Target 55-65% for full-service, 60-67% for QSR. If prime cost creeps above 70% for two weeks in a row, something is broken — either you’re over-ordering, or labor scheduling is loose, or both.
Labor as a percentage of sales
Hourly target: 25-32% for full-service, 22-28% for QSR. The leverage point isn’t cutting hours — it’s scheduling to forecast. AI-powered scheduling tools cut labor 3-5% without service degradation by matching staffing to projected demand. See AI-driven staffing.
Item-level margin
Knowing your average margin is useless. Knowing each menu item’s margin is everything. The 80/20 of menu engineering: find the 20% of items driving 80% of profit, and feature them. Demote the high-cost, low-margin items. Most operators discover their highest-popularity item is actually their lowest-margin item.
Void and comp rates
Voids by server, by hour, by menu item. Comp rates the same. These are leak detectors — a server with a 5%+ void rate when the average is 1% has either a training gap or a theft problem. Real-time POS reporting catches this in days, not on next month’s P&L.
The other three — average ticket, table turn time, and customer lifetime value — round out the operating picture. See the full reporting and analytics breakdown for the methodology.
Real-time vs batch reporting
The decision rule: your reporting cadence should match your decision cadence.
- Daily/weekly batch — fine if you only adjust schedules and orders weekly with your accountant.
- Real-time — required if you want to cut a server at 7pm because sales are slow, or order more proteins on the fly when a menu item runs hot.
- Predictive (next 24-72h) — required for multi-location groups where you’re scheduling labor and ordering inventory across many sites.
More on this in the role of real-time reporting.
AI in restaurants — what's real, what's hype
Every POS vendor is now ‘AI-powered.’ Some of it earns its cost; most of it doesn’t.
AI use cases that actually work
- Demand forecasting. Next-week sales by daypart, with weather and events factored in. Drives prep volumes and ordering.
- Labor scheduling. Auto-suggests shift templates based on forecasted demand. 3-5% labor cost reduction is realistic.
- Inventory auto-reorder. Triggers POs based on usage patterns and lead times. Prevents 86’s and over-ordering. Read the breakdown.
- Customer segmentation. Identifies high-value customer cohorts and surfaces them for loyalty marketing. Drives 10-15% lift in repeat visits.
AI use cases that are mostly hype
- ‘AI menu engineering.’If a tool is recommending menu changes based on item-level margin, that's analytics, not AI. Marketing label, no value-add.
- AI chatbots for customer service. Frustrating in food/hospitality where the issue is usually emotional, not informational.
- ‘Personalised’ marketing emails. Mostly rules-based with an AI label. The lift over basic segmentation is marginal.
Multi-location data consolidation
Single locations can run on POS dashboards. Groups of 3+ locations need a different approach: consolidated reporting across the whole portfolio, with the ability to drill down to a single store.
The architecture choices:
- Native multi-location POS. All locations on one platform with consolidated reporting baked in. Simplest; works through the first 20-30 locations. Katalyst analytics ships with multi-location consolidation.
- Data warehouse. Snowflake / BigQuery ingesting POS data via API. Required if you have mixed POS systems across locations or need custom analytics beyond what POS dashboards expose.
- BI layer. Looker / Tableau / Metabase on top of the warehouse. Gives finance teams custom modeling. Adds engineering overhead — only justified at enterprise scale.
Restaurant intelligence vs analytics
These get used interchangeably but mean different things:
- Analytics = retrospective. ‘What happened last week?’ Dashboards, reports, KPIs.
- Intelligence = forward-looking + prescriptive. ‘What should I do tomorrow?’ Forecasts, recommendations, automated alerts.
Most restaurants have analytics. Few have intelligence. The shift from one to the other is what AI is actually delivering. Read the full distinction and why intelligence is the gateway.
Building your data tech stack
For 90% of restaurants, the right stack is simpler than you’d guess:
- POS with native analytics. Real-time dashboards, item-level margin, multi-location consolidation. This covers prime cost, labor %, item margin, void rates — the operating metrics.
- Loyalty / CRM data. Linked to POS so customer lifetime value rolls up automatically. See Katalyst loyalty.
- (Optional) Data warehouse. Only if you hit one of two triggers: 20+ locations, or mixed POS across locations.
- (Optional) AI scheduling and forecasting. Bolt on once basic reporting is solid. Premature optimisation otherwise.
Frequently asked questions
What are the most important metrics to track in a restaurant?
Eight metrics cover 90% of the value: prime cost (food + labor as % of sales), labor as a % of sales, food cost as a % of sales, item-level margin, void and comp rates, average ticket, table turn time (full-service), and customer lifetime value (loyalty-enabled). Anything beyond these is usually a vanity metric for most operators.
What is a good prime cost for a restaurant?
Prime cost (food cost + labor cost, divided by net sales) should run 55-65% for full-service and 60-67% for quick-service. Above 70% and you're operating at a loss after rent and overhead. Tracking prime cost weekly — not monthly — is what separates surviving operators from thriving ones.
Do I need real-time reporting or is daily/weekly enough?
It depends on your decision cadence. If you only review numbers weekly with your accountant, daily reporting is fine. If you want to send a server home when sales are slow at 7pm to protect labor cost, you need real-time. For multi-location operators, real-time is non-negotiable — you can't run 10 locations on day-old data.
Is AI actually useful in restaurants, or is it overhyped?
Both. AI is genuinely useful for: demand forecasting (next-week prep volumes), labor scheduling (staffing to forecasted demand), inventory ordering (auto-reorder triggers based on usage patterns), and customer segmentation (loyalty marketing). It's mostly hype for: AI-powered menu engineering, AI 'personalisation' that sends generic emails, and AI customer service chatbots that frustrate guests. Stick to the operational use cases.
How is restaurant intelligence different from restaurant analytics?
Analytics = retrospective ('what happened last week?'). Intelligence = forward-looking and prescriptive ('what should I do tomorrow?'). Intelligence layers AI/ML on top of analytics to give you decisions, not just data. The shift matters because most operators have analytics — dashboards and reports — but few have intelligence. See our deep-dive on the distinction.
How do I consolidate data across multiple locations?
Two paths: (1) cloud-based POS that natively reports across locations (Katalyst, Toast) — the simplest path; (2) data warehouse (Snowflake, BigQuery) ingesting from each location's POS via API — required if you have mixed POS systems or need custom analytics. For most operators, path 1 is sufficient through the first 20-30 locations.
Built into Katalyst
200+ restaurant KPIs in one dashboard
Real-time prime cost, item-level margin, labor scheduling forecasts, multi-location consolidation. All native to your POS — no warehouse engineering required.
