This Dashboard Runs an Entire Restaurant. Here's Every Screen.

Most restaurant dashboards are glorified spreadsheets with a coat of paint. They show you numbers. They don't tell you what to do about them. We built something different. Here's a full walkthrough of every screen in Nexara's operations dashboard — the one that actually runs restaurants across the Middle East.

Why Most Restaurant Dashboards Fail

Walk into any restaurant using a legacy POS system and ask the manager what their repeat customer rate is. They'll shrug. Ask them which payment method has the highest average ticket. Another shrug. Ask which hour of the day loses them money on delivery. They'll look at you like you're speaking a foreign language.

The data exists. It's buried in transaction logs and delivery app exports and end-of-day receipts. What doesn't exist is a system that aggregates it, surfaces what matters, and connects insight to action.

This is the gap. Most restaurant dashboards are built by people who think "analytics" means showing a line chart of daily revenue. That's not analytics. That's decoration. A useful dashboard answers three questions in real time: What's happening right now? What happened today compared to yesterday? What should I do next?

The Three Tabs That Run Everything

Nexara's dashboard is organized around three tabs: Sales, Operations, and Customers. This isn't arbitrary. It maps to the three things a restaurant operator cares about at any given moment: money, execution, and people. Each tab is lazy-loaded — the Customers tab, which runs heavier aggregation queries, doesn't fire its PostgreSQL queries until you actually click on it. That keeps the initial page load under 1.2 seconds even on 3G connections.

Tab 1: Sales

The Sales tab opens with the number that matters most: today's total revenue, compared to the same day last week, expressed as both an absolute figure and a percentage change. Below that, four KPI cards: total orders, average order value, revenue per labor hour (if labor data is connected), and gross margin.

But the cards are just the headline. Scroll down and you hit the payment method breakdown. In the MENA region, this matters more than most dashboards acknowledge. A typical Jordanian restaurant might process 40% cash, 25% CliQ (Jordan's instant payment system), 20% credit card, and 15% through delivery app wallets. Each method has different settlement timelines. Cash is immediate. CliQ settles in minutes. Card payments take 2–5 business days. Delivery app payouts arrive weekly, sometimes biweekly.

Notice something in that mock data? Delivery app orders have the lowest average ticket — JOD 15 versus JOD 23 for card payments. That's typical. Delivery platforms push discounts that shrink basket sizes. The dashboard makes this visible so operators can decide whether a Talabat promotion is actually worth the margin erosion.

Below the payment breakdown sits the hourly revenue heatmap. It's a 24-column grid where color intensity maps to revenue density. For most restaurants in Amman, you'll see a bright band from 12:00–14:00 (lunch) and another from 19:00–22:00 (dinner). The dead zones — typically 15:00–17:00 — are where operators should be running promotions or reducing staff. The heatmap makes the decision obvious without requiring any interpretation.

Tab 2: Operations

Operations is where the real-time capability earns its keep. This tab shows a unified stream of live orders from every channel: dine-in POS, delivery apps (Careem, Talabat, Deliveroo, Jahez), the restaurant's own website, and the call center. Six different sources, one stream, updated via WebSocket with no polling.

The technical architecture here is worth explaining. When an order comes in from any source, the NestJS backend writes it to PostgreSQL and simultaneously pushes an event through a Socket.io gateway. The React frontend maintains a persistent WebSocket connection and appends new orders to a local state array. No HTTP polling. No page refresh. A new Careem order appears on screen within 200 milliseconds of the webhook hitting the backend.

Each order in the stream shows its source (with a color-coded badge), status, items, customer name, and elapsed time. The status pipeline is the critical feature: orders move through New → Accepted → Preparing → Ready → Picked Up / Delivered. Each transition can trigger a thermal printer ticket via the Electron-based PrinterMaster app running on-premise. Kitchen gets a prep ticket when the order is accepted. The counter gets a packaging ticket when it's marked ready.

The operations tab also surfaces the orders-by-status breakdown as a simple pipeline visualization. If 12 orders are stuck in "Preparing" and only 2 are in "New," the kitchen is keeping up. If the ratio inverts — 15 new orders, 3 in preparation — you have a bottleneck. This is visible at a glance. No digging through reports.

For multi-location operators, a branch performance comparison table shows each location's current order count, average preparation time, and complaint rate side by side. A branch manager in Abdoun can see instantly that their Sweifieh location is taking 12 minutes longer on average prep time — and dispatch help or investigate.

Tab 3: Customers

The Customers tab is where most restaurant platforms have a blank page. Literally. Ask Foodics or POSRocket to show you a customer acquisition funnel and they'll point you to a third-party CRM integration. Nexara builds it in.

The tab opens with a website funnel visualization: visitors → menu views → cart adds → completed orders. Typical conversion rates for MENA restaurant websites sit around 2.8–4.1%. If your funnel shows 3,000 visitors but only 40 orders, the drop-off is in the cart. The funnel makes this visible without requiring Google Analytics expertise.

Below the funnel: repeat customer rate. This is the metric that separates surviving restaurants from thriving ones. Industry data from the MENA F&B sector shows that a 5% increase in customer retention can increase profits by 25–95% (the range depends on average ticket size and frequency). The dashboard tracks first-time versus returning customers daily and weekly, and plots the trend over 30, 60, and 90 days.

Then there's the blacklist management system. This is a feature nobody likes to talk about but every restaurant needs. Customers who repeatedly file fraudulent complaints, demand refunds after consuming full orders, or abuse promotional codes can be flagged and blacklisted. The system tracks the reason, the date, and requires a minimum-length justification to unblacklist. It's not punitive — it's protective. A single serial complainer can cost a restaurant hundreds of dinars per month in undeserved refunds.

The complaint tracking panel rounds out the tab. Every complaint is logged with its source (call center, delivery app, walk-in), category (food quality, delivery time, missing items), resolution status, and associated cost. Over time, this builds a pattern. If 60% of complaints in a given month are about missing items, the packaging process is broken — not the kitchen.

Under the Hood: The Technical Stack

The dashboard runs on a NestJS backend with dedicated analytics endpoints. When the Sales tab loads, it fires a POST request to /analytics/dashboard with a date range and branch filter. The backend runs PostgreSQL aggregation queries — SUM, GROUP BY, DATE_TRUNC — against the orders, payments, and customers tables. No pre-computed materialized views. The queries are fast because the schema is properly indexed (compound indexes on branchId + createdAt for the orders table, for example).

The Customers tab hits two separate endpoints: /analytics/customers-summary for retention metrics and /analytics/website-funnel for conversion data. These are lazy-loaded — the React 18 frontend uses dynamic imports so the Customers tab component and its dependencies don't ship in the initial bundle. First paint for the Sales tab happens without any customer data queries touching the database.

Real-time updates flow through Socket.io. The backend maintains a WebSocket gateway that broadcasts order events scoped by company and branch. When a manager is viewing the Operations tab for their Sweifieh branch, they only receive events for that branch — not the entire company's order stream. This scoping reduces bandwidth and keeps the frontend responsive even during peak hours when a busy restaurant might process 200+ orders per hour across all channels.

The Principle: Every Metric Is Actionable

There's a design philosophy embedded in every screen: if a metric doesn't suggest an action, it doesn't belong on the dashboard. Revenue by payment method tells you where to push digital payments. The hourly heatmap tells you when to run promotions and when to cut staff. The order pipeline tells you if the kitchen needs help right now. The complaint breakdown tells you which process to fix.

This sounds obvious. It isn't. Most dashboards are built by data teams who optimize for comprehensiveness — showing every possible metric. Nexara's dashboard is built by people who've stood behind a restaurant counter during a Friday dinner rush. The difference shows.

The top-selling products chart, for example, doesn't just show you what's popular. It shows you which items have the highest margin and which ones are ordered frequently but have declining satisfaction scores (derived from complaint data). A shawarma plate might be your #1 seller, but if it's also your #1 complaint source, that's a problem the dashboard surfaces before it becomes a review on Google Maps.

What Multi-Location Operators Actually Need

Single-location restaurants need a dashboard. Multi-location operators need a command center. The difference is branch comparison.

Nexara's branch performance table (visible across all three tabs) lets operators compare any metric across locations in real time. Revenue per branch. Average prep time per branch. Complaint rate per branch. Customer retention per branch. This isn't a report you generate at the end of the month — it's live data, updated with every order.

A chain operator with five locations in Amman told us that the branch comparison view alone changed how they staffed. They discovered that their Mecca Mall location had a 40% higher average prep time during lunch hours compared to their street-front locations. The reason: mall food court orders tend to have more modifiers (extra sauce, no onions, substitute fries) because customers are browsing the menu board while waiting. The solution was simple — add one more prep station during 11:00–14:00. They wouldn't have found the problem without seeing the branches side by side.

Built for the Region, Not Adapted for It

A brief note on localization that goes beyond language. The dashboard supports full RTL (right-to-left) layout for Arabic. But RTL support is table stakes. What matters more is that the financial models, payment method integrations, and operational assumptions are built for MENA from the ground up.

CliQ integration in Jordan. Benefit Pay in Bahrain. STC Pay in Saudi Arabia. Delivery app webhook formats for Careem, Talabat, Deliveroo, and Jahez — each with different payload structures, different status update conventions, different settlement schedules. The dashboard normalizes all of this into a single view. An operator doesn't need to know that Careem sends order status updates via webhook while Talabat uses polling. They see one unified stream.

Currency formatting respects locale conventions: JOD to three decimal places, SAR to two. Date formats follow regional norms. Tax calculations account for country-specific VAT rules. These are small details that Western platforms entering the market consistently get wrong because they're afterthoughts, not foundational decisions.