venue-intelligence-dashboard

Real-Time Intelligence Dashboard: Implementation Spec for Small Hospitality Venues

Executive Summary

This document provides implementation-ready specifications for upgrading a small hospitality venue’s intelligence dashboard across six domains: advanced KPIs, data visualisation, revenue intelligence, event benchmarking, staff cost optimisation, and anomaly detection. Each section specifies data requirements, calculation methods, thresholds, and operator actions. The target venue is a Melbourne bar/live music space doing $15–25k/week across Square POS bar sales, TryBooking ticketed events, and Deputy-managed staff.

---

1. KPI Best Practices for Small Hospitality Venues

Beyond Basic Revenue: The Metrics That Separate Best-Run Venues

The best-run bars and live music venues track metrics that most operators ignore entirely. Independent venues operate on razor-thin margins — the UK’s grassroots music venues recorded a collective profit margin of just 0.5% in 2024, with nearly half losing money (Ticket Fairy). These advanced KPIs surface problems weeks before they hit the P&L.

1.1 Customer Lifetime Value (CLV)

What it measures: Total revenue a customer generates across all visits over their lifetime as a patron.

Data needed:

• Customer identifier (email from TryBooking, loyalty card, or Square customer profile)
• All ticket purchases linked to that customer
• Bar spend per visit (where identifiable via card-on-file or tab)
• First and most recent transaction dates

Calculation:

[ \text{CLV} = \text{Avg Revenue per Visit} \times \text{Visit Frequency per Year} \times \text{Avg Customer Lifespan (years)} ]

Implementation:

• Match TryBooking emails to Square customer profiles where possible
• Calculate visit frequency as distinct transaction dates per customer per rolling 12 months
• Customer lifespan = months between first and last visit (active customers: use current date)
• Segment into tiers: Top 10% (VIPs), Next 20% (Regulars), Next 30% (Occasionals), Bottom 40% (One-timers)

Benchmarks:

• Dialled-in event timing can lift CLV by 25–95% through higher purchase frequency and longer customer relationships (AnyRoad)
• Most venues see strongest results at 4–6 events per customer per year
• A low-spend customer who attends 20 times is more valuable than a one-time high spender (Financial Models Lab)

Thresholds & Actions:

CLV Tier	Revenue Range	Action
VIP (Top 10%)	>$800/year	Priority event invitations, first access to limited tickets
Regular (Next 20%)	$300–800/year	Targeted re-engagement if no visit in 45 days
Occasional (Next 30%)	$100–300/year	”We miss you” campaigns after 90 days of inactivity
One-timer (Bottom 40%)	<$100/year	Post-first-visit follow-up email within 48 hours

1.2 Repeat Attendance Rate

What it measures: Percentage of attendees at current events who have attended at least one previous event.

Data needed: TryBooking customer email matched across events.

Calculation:

[ \text{Repeat Rate} = \frac{\text{Attendees with } \geq 1 \text{ prior event purchase}}{\text{Total attendees}} \times 100 ]

Benchmarks:

• Venues hosting live performances see a 20% higher return customer rate than those without entertainment (Opus Artists)
• Target: 30–40% repeat attendance is strong for a mixed-programming venue
• If <15%, the venue is churning through audiences and relying on one-off visitors (Ticket Fairy)

Actions:

• Track by event type (comedy regulars vs. live music vs. trivia)
• Alert if repeat rate drops below 25% for 3 consecutive weeks
• Cross-reference: which event types produce the highest return visit rate within 60 days?

1.3 Revenue per Available Seat-Hour (RevPASH)

What it measures: How effectively seating capacity generates revenue across time.

Data needed:

• Hourly revenue from Square POS
• Venue capacity (or seated capacity for different configurations)
• Operating hours per day

Calculation:

[ \text{RevPASH} = \frac{\text{Total Revenue}}{\text{Available Seats} \times \text{Operating Hours}} ]

Implementation: Calculate by hour-of-day to identify under-monetised time windows. A bar with 120 capacity open 6pm–2am (8 hours) producing $4,000 = RevPASH of $4.17. If the 6–7pm hour only produces $200, that’s $1.67/seat-hour — a candidate for happy hour pricing or early-doors programming (GoAudits).

1.4 Drink-to-Food Ratio & Beverage Mix

What it measures: Revenue composition by category and margin contribution.

Data needed: Square POS item-level sales data, categorised by: spirits, beer, wine, cocktails, non-alcoholic, food.

Calculation:

[ \text{Beverage Ratio} = \frac{\text{Beverage Revenue}}{\text{Total F&B Revenue}} \times 100 ]

Benchmarks:

• Bar-focused venues: 75–85% beverage ratio is typical
• Concession margins run 60–70% for beverages (Ticket Fairy)
• Non-alcoholic and alternative categories are growing quickly — venues that plan bar strategy show-by-show perform best (Opendate)

Track separately:

• Average drinks per head by event type
• Non-alcoholic percentage trend (8-week rolling)
• Cocktail vs. beer vs. wine split by event type (metal shows drive beer; comedy drives cocktails)

1.5 Weather Impact Correlation

What it measures: Revenue variance attributable to weather conditions.

Data needed:

• Daily revenue from Square
• Historical weather data from BOM (Bureau of Meteorology) API for Melbourne — temperature, rainfall, UV index
• Day-of-week and event type controls

Calculation method: Run a multiple regression:

[ \text{Revenue}_t = \beta_0 + \beta_1 \text{Temp}_t + \beta_2 \text{Rain}_t + \beta_3 \text{DayOfWeek}_t + \beta_4 \text{EventType}_t + \epsilon ]

Key findings from research:

• 90% of hospitality operators report weather impacts on sales (Liberty Interactive)
• Good weather days: +5.2% average sales increase; bad weather: -2.6% decrease
• Rain impact diminishes after a threshold — initial rain kills walk-ins, but heavy rain doesn’t reduce further (Tenzo)
• Extreme temperatures relative to seasonal norms cause the biggest deviations — not absolute temperature
• Academic research confirms weather has statistically significant effects on beverage sales specifically (Štulec, 2017)

Implementation:

• Pull BOM data daily via API
• Calculate deviation from 30-day temperature average (not raw temp)
• Add weather-adjusted forecast to morning briefing: “Today is 8°C below seasonal average — expect -12% walk-in traffic based on historical pattern”
• Threshold alert: >15mm rain forecast → trigger “Rain Day Protocol” (adjust staffing, push ticketed event marketing)

1.6 Cancellation & Refund Pattern Analysis

What it measures: Refund rates, timing patterns, and revenue leakage.

Data needed:

• TryBooking refund records (date, event, reason if captured)
• Square refund/void transactions

Key metrics:

• Refund rate per event = Refunds / Total tickets sold × 100
• Average refund lead time (days before event)
• Refund-to-weather correlation
• Void rate per staff member per shift

Thresholds:

• Healthy: <5% refund rate per event
• Watch: 5–10% (investigate — pricing issue? competing event?)
• Alert: >10% (immediate investigation — is the act underperforming vs. expectations?)

1.7 Event Conversion Rate

What it measures: Percentage of people who view event listings and purchase tickets.

Data needed: TryBooking page views and completed purchases (if API exposes this), social media link clicks, email open→click→purchase funnel.

Calculation:

[ \text{Conversion Rate} = \frac{\text{Tickets Sold}}{\text{Event Page Views}} \times 100 ]

Benchmark: 2–5% is typical for ticketed events. Track by marketing channel (email vs. social vs. direct) to optimise spend allocation.

---

2. Data Visualisation Patterns for Operational Dashboards

Design Philosophy: Decision Speed, Not Data Density

The dashboard serves a venue manager who checks it daily, often on mobile, often in a rush. Every visualisation must answer: what should I do differently today?

2.1 Layout Architecture

Primary reference: The Stripe Dashboard model — clean, calm, and founder-friendly. Key patterns from Stripe that apply directly (Stripe Dashboard UI):

Pattern	Stripe Implementation	Venue Dashboard Application
Customisable metric cards	Add/Edit/Reorder cards	Let operators choose top 5 KPIs
Stacked bar distribution	Payment type breakdown	Revenue split: bar / tickets / other
Delta badges	Green/red growth indicators	Week-over-week change on every metric
Zero-baseline charts	Gross volume sparkline	Daily revenue with spikes visible
Fail log with red pills	Failed payment surfacing	Refund/void alerts with staff ID and timestamp
High-value buyers	Top spenders ranked	Top 10 customers this week

Layout hierarchy (Smashing Magazine):

• Top-left: 3–5 primary KPIs as large number cards with delta indicators and sparklines
• Each card shows: current value, percentage change (▲/▼), 7/30 day sparkline
• Middle: Revenue trend chart (line) with event markers overlaid
• Right panel: Alert feed (scrolling, colour-coded)
• Bottom: Upcoming events pipeline with pace indicators

2.2 Chart Type Recommendations

Metric	Chart Type	Why
Daily/weekly revenue	Area chart with event markers	Shows trend + isolates event impact
Revenue composition	Stacked bar (horizontal)	Quick scan of bar vs. ticket split
Hourly sales pattern	Heatmap (day × hour)	Reveals peak hour patterns across weeks
Saturday 8-week trend	Line chart with confidence band	Shows trajectory + expected range
Ticket velocity	Bullet chart (actual vs. target)	Instantly shows ahead/behind pace
Event P&L comparison	Grouped bar chart	Side-by-side event type comparison
Staff cost vs. revenue	Dual-axis line	Correlation at a glance
Weather impact	Scatter with colour	Temp/rain vs. revenue with event type encoding
Booking pipeline	Kanban-style cards	Pipeline with pace indicators per event

2.3 Interaction Patterns

Time period selector: Default to “This Week” with one-click toggles for Today / This Week / This Month / Last 8 Weeks / Custom range.

Drill-down: Every metric card should expand to a detailed view. Click “Revenue: $18,420” → reveals daily breakdown, then click any day → hourly breakdown.

Comparison mode: Toggle to overlay same period last year / last month / 8-week average as a faded reference line.

Mobile-first: Cards stack vertically on mobile. Sparklines become primary navigation. No horizontal scrolling.

2.4 What Leading Platforms Do Well (and What’s Missing)

Toast POS Analytics tracks four key areas on its weekly overview: sales, labor, guest counts, and menu performance (Toast). Strength: integrated labour-to-sales view. Weakness: no event attribution or weather overlay.

Square Dashboard excels at transaction-level detail and payment trends. Weakness: no concept of “events” — everything is flat transaction data with no time-window attribution.

Stripe Sigma allows SQL queries against payment data with AI assistance, plus one-click chart generation (Stripe). The ability to write custom queries against raw data is powerful for ad-hoc analysis.

What’s universally missing from commercial dashboards for venues:

• Event-attributed bar revenue (time-window matching)
• Ticket velocity vs. historical pace
• Weather-adjusted forecasts
• Cross-system views (POS + ticketing + rostering in one)
• Predictive event P&L based on current booking pace

This is exactly the gap a custom dashboard fills.

2.5 Real-Time Dashboard UX Principles

From research on hospitality-specific dashboard redesigns (Smashing Magazine):

• Data freshness indicators: Show “Last updated: 3 min ago” on every data card. Users lose trust when they don’t know if data is current.
• Cached snapshots: When real-time feed fails, show last known data with timestamp rather than blank cards.
• Animation budget: 200–400ms for value updates, <300ms for list reordering. Subtle pulse around changing metrics, not flashy transitions.
• Alert colours: Red/orange for critical, yellow/amber for warning, blue/green for positive. Always pair colour with shape/icon (1 in 12 men are colour-blind).
• Role-based views: A venue operator wants P&L and pipeline. A bar manager wants SPLH and stock levels. Build role presets.

---

3. Revenue Intelligence Techniques

Turning 8 Years of Square Data into Predictive Power

With 8 years of daily transaction data, the venue sits on a remarkably deep dataset. Academic research on hospitality forecasting consistently shows that exponential smoothing, pickup methods, and moving average models are the most robust approaches for this type of data (Heo et al., 2023; Cornell Hotel Forecasting Study).

3.1 Seasonal Decomposition (STL)

What it does: Separates your revenue time series into three components: trend, seasonality, and residual (noise).

Method: STL (Seasonal-Trend decomposition using LOESS) — the standard for retail/hospitality.

Implementation (Python):

from statsmodels.tsa.seasonal import STL
 
# daily_revenue = pandas Series with DatetimeIndex
stl = STL(daily_revenue, period=7, seasonal=13, robust=True)
result = stl.fit()
 
trend = result.trend        # Long-term direction
seasonal = result.seasonal  # Day-of-week pattern
residual = result.resid     # Unexplained variance (anomalies live here)

What each component tells you:

• Trend: Is the venue growing or declining? Flatten the noise to see the real trajectory. Alert if trend slope turns negative for >4 weeks.
• Seasonality: Quantifies your day-of-week pattern. Saturday is probably 3× Tuesday. Use this to set day-specific targets.
• Residual: Large residuals = something unusual happened. Event impact, weather shock, or operational issue.

Operator action: If trend component shows >10% decline over 8 weeks, trigger a programming review. If residuals consistently spike on event nights, the event attribution model needs calibration.

3.2 Moving Averages for Trend Detection

8-week rolling average (already implemented) is solid for weekly comparison. Add:

• 4-week weighted moving average (recent weeks weighted higher): (\text{WMA} = 0.4 \times W_0 + 0.3 \times W_{-1} + 0.2 \times W_{-2} + 0.1 \times W_{-3})
• Year-over-year same-week comparison: Compare this Saturday to the same Saturday last year (week number match), adjusted for Easter/public holiday shifts
• Exponential smoothing (Holt-Winters): Captures both trend and seasonality in one model — research shows it’s among the most accurate for daily hotel/venue demand (Ampountolas, 2021)

Implementation for declining trend detection:

# Flag if 4-week WMA is declining and below 8-week SMA
four_week_wma = calculate_weighted_ma(revenue, weights=[0.4, 0.3, 0.2, 0.1])
eight_week_sma = revenue.rolling(window=8).mean()
 
if four_week_wma.iloc[-1] < eight_week_sma.iloc[-1] * 0.95:
    alert("Revenue trend declining: 4-week WMA is 5%+ below 8-week average")

3.3 Cohort Analysis

What it reveals: How different groups of customers behave over time.

Cohort definitions for a venue:

• Acquisition cohort: Month of first visit. Track: what % of Jan 2024 first-timers returned in Feb, Mar, Apr…?
• Event-type cohort: First event type attended. Do “comedy-first” customers convert to live music? Do “trivia-first” become regulars?
• Spend cohort: Segment by initial visit spend quartile. Do high first-visit spenders become loyal, or are they tourists?

Data structure:

Cohort Month	Month 1 Retention	Month 2	Month 3	Month 6	Month 12
Jan 2024	100%	35%	22%	15%	8%
Feb 2024	100%	38%	25%	18%	10%

Action: If retention is dropping cohort-over-cohort, something systemic changed (venue experience, competition, pricing). If a specific event-type cohort retains better, programme more of that genre.

3.4 Demand Forecasting Model

Recommended approach: Hybrid model combining statistical baseline with manual override — research confirms this outperforms either approach alone (Tenzo, Ramsi).

Inputs:

1. Historical daily revenue (8 years from Square)
2. Day of week
3. Month/season
4. Event type (if scheduled)
5. Weather forecast (BOM API)
6. Public holidays / school holidays
7. Competing events (manual flag or scraped from competitor venue calendars)

Formula approach (for morning briefing):

[ \text{Forecast}_t = \text{Baseline}_t \times (1 + \text{Weather Adjustment}_t) \times (1 + \text{Event Multiplier}_t) \times (1 + \text{Holiday Adjustment}_t) ]

Where:

• Baseline = 8-week same-day-of-week average
• Weather adjustment = regression coefficient × deviation from seasonal norm
• Event multiplier = average revenue lift for this event type vs. non-event same-day
• Holiday adjustment = historical public holiday impact factor

Accuracy check: Track forecast vs. actual daily. Smart forecasting algorithms outperform manager intuition by 25–50% over time, though managers may catch one-off events the model misses (Tenzo).

3.5 Dynamic Pricing Signals

Ticket pricing optimisation using historical data:

• Pace-based pricing: If ticket sales for an event are running 20%+ ahead of historical average at the same days-out mark, raise the next price tier early. If 20%+ behind, trigger promotional pricing or social push.
• Day-of-week elasticity: Test small price variations for the same event type across different nights. Measure: does a $5 increase on Saturday reduce ticket sales?
• Early-bird yield: Calculate: what % of total tickets sell at early-bird pricing? If >60%, the early-bird price is too low.
• Demand-based algorithms can adjust prices in real-time based on velocity — platforms like Ticket Fairy offer this natively for nightclub/venue tickets (Ticket Fairy)

Bar revenue optimisation signals:

• Identify which 30-minute windows have highest RevPASH → focus upselling training on those windows
• Track average transaction value by hour → if it drops sharply after midnight, consider adjusted menu/pricing
• Calculate drinks per head by event type → programme genres that drive highest beverage spend

---

4. Event Performance Benchmarking

A Framework for Comparing Apples to Oranges

Different event types have fundamentally different economics. A sold-out comedy show with a $500 act fee has a completely different margin profile than a live music night with a $3,000 guarantee. The IAVM (International Association of Venue Managers) provides the standard framework for normalised event comparison (IAVM Handbook).

4.1 Core Event Metrics (Calculate for Every Event)

Metric	Formula	Purpose
Net Event Income	(Ticket revenue + Attributed bar revenue + Door sales) − (Artist fee + Production costs + Marketing spend + Allocated staff costs)	True profitability
Revenue per Attendee (RPA)	Total event revenue ÷ Attendance	Normalises across event sizes
F&B Per Cap	Net bar revenue during event window ÷ Attendance	Bar monetisation per head
Capacity Utilisation	Tickets sold ÷ Venue capacity × 100	Fill rate
Event Yield	Sum of net income across all events of a type ÷ Number of events of that type	Average profitability per event type (IAVM)
Marketing Cost per Ticket	Total marketing spend ÷ Tickets sold	Acquisition efficiency
Gross Margin %	Net event income ÷ Total event revenue × 100	Percentage profit

4.2 Bar Revenue Attribution

The critical implementation detail: How to attribute bar revenue to a specific event when the bar runs all night.

Method: Time-window attribution with baseline subtraction.

1. Define event window: doors open → 1 hour after event ends
2. Pull Square revenue for that exact time window
3. Subtract baseline: average same-day, same-hour revenue on non-event weeks
4. Result = event-attributed bar revenue

Example:

• Friday live music event, doors 7pm, show 8pm–11pm
• Attribution window: 7pm–midnight (5 hours)
• Friday 7pm–midnight non-event average: $2,400
• This Friday 7pm–midnight actual: $4,100
• Event-attributed bar revenue: $1,700

4.3 Normalisation Framework

To compare events fairly, normalise for these variables:

Day-of-week adjustment: Calculate a day-of-week index from 52-week revenue averages:

Day	Avg Revenue	Index
Monday	$1,200	0.56
Tuesday	$1,400	0.65
Wednesday	$1,800	0.84
Thursday	$2,200	1.02
Friday	$3,100	1.44
Saturday	$3,400	1.58
Sunday	$1,900	0.88

Avg = $2,143 (index 1.0)

Normalised event revenue = Actual revenue ÷ Day-of-week index

A Tuesday comedy night generating $2,800 (normalised: $2,800 / 0.65 = $4,308) outperforms a Saturday comedy night generating $4,000 (normalised: $4,000 / 1.58 = $2,532).

Weather adjustment: Apply the regression coefficients from Section 1.5.

Competing events: Flag when major competing events are on (AFL finals, festivals, other venue headliners). Build a binary “competition flag” and measure average revenue impact.

Marketing spend normalisation:

[ \text{Marketing-Adjusted RPA} = \frac{\text{Revenue per Attendee} - \text{Marketing Cost per Attendee}}{\text{Revenue per Attendee}} \times 100 ]

4.4 Event Type Scorecard

Build a rolling 3-month scorecard comparing event types:

Event Type	Avg Attendance	Avg Utilisation	Avg RPA	Avg F&B Per Cap	Avg Margin	Repeat Rate	Normalised Yield
Comedy	85	71%	$42	$28	35%	45%	$850
Live Music	110	92%	$38	$22	15%	30%	$620
Drag	95	79%	$52	$35	40%	55%	$1,100
Trivia	70	58%	$32	$24	60%	65%	$780
DJ Night	120	100%	$30	$25	20%	20%	$450

(Sample illustrative data)

Actions based on scorecard:

• If a genre’s normalised yield is declining over 3 months, re-evaluate booking strategy
• If utilisation is consistently <60%, the event type isn’t drawing — consider replacing or changing night
• If F&B per cap is low relative to attendance, investigate bar service speed, pricing, or menu for that audience
• High repeat rate + moderate yield = loyalty engine — protect these events
• High margin + low repeat = cash cow but not building audience — OK in moderation

4.5 Pro Forma / Offer Sheet

For every prospective event, build a pre-event P&L projection:

Projected Revenue:
  Ticket revenue = (Capacity × Target fill rate × Avg ticket price)
  Projected bar revenue = (Attendance × Historical F&B per cap for this event type)
  Door revenue = (Walk-in estimate × Door price)

Projected Costs:
  Artist fee / guarantee
  Production (sound, lighting, tech crew)
  Marketing budget
  Allocated staff costs = (Projected labour hours × Avg hourly rate)
  Venue overhead allocation

Projected Net Income = Revenue − Costs
Breakeven attendance = Total Costs ÷ (Avg ticket price + Avg F&B per cap)

This is the IAVM standard approach for booking decisions (IAVM). The dashboard should auto-populate historical averages and flag when projections deviate significantly from the running event type scorecard.

---

5. Staff Cost Optimisation

Data-Driven Rostering Against Expected Demand

Labour is the largest controllable expense in hospitality. Going from no data-driven system to even a basic labour monitoring system can save up to 15%, with further 5–10% from advanced models (FSR Magazine).

5.1 Sales per Labour Hour (SPLH)

The core metric. Every rostering decision should flow from this number.

Calculation:

[ \text{SPLH} = \frac{\text{Net Sales}}{\text{Total Labour Hours}} ]

Benchmarks for bar/venue context (7shifts):

Venue Type	SPLH Range
Full-service bar/restaurant	$50–$80
Fast-casual	$80–$120
Quick-service	$100–$150+

For a Melbourne bar doing $15–25k/week across ~168 rostered hours/week, baseline SPLH would be approximately $90–150. Set initial targets based on 4-week historical average, then improve.

5.2 The Scheduling Formula

Work backwards from projected revenue:

[ \text{Max Labour Hours} = \frac{\text{Projected Sales}}{\text{Target SPLH}} ]

Example:

• Saturday projected revenue: $5,500
• Target SPLH: $85
• Max labour hours allowed: 65 hours
• If average shift is 6 hours, that’s ~11 staff for the night

By daypart (set different SPLH targets):

Daypart	Projected Revenue	Target SPLH	Max Hours
Setup/open (4pm–6pm)	$400	$45	9 hrs
Pre-event (6pm–8pm)	$1,200	$75	16 hrs
Event peak (8pm–11pm)	$2,800	$100	28 hrs
Late night (11pm–2am)	$1,100	$80	14 hrs

5.3 Role-Based Labour Modelling

Don’t treat all staff equally in the model (FSR Magazine):

• Bartenders: Correlated with transaction count / drink orders. Model: max drinks per bartender per hour (typically 40–60 simple serves, 20–30 cocktails)
• Security/door: Correlated with attendance, not revenue. Fixed minimum based on capacity regulations + scalable based on expected crowd
• Sound/tech: Fixed per event type. Comedy needs 1 tech; full band needs 2–3
• Floor staff/barbacks: Correlated with revenue intensity. Scale with bartender count (1 barback per 2–3 bartenders)
• Management: Fixed cost. 1 per shift minimum regardless

5.4 Deputy Integration for Real-Time Optimisation

Deputy’s AI-powered demand forecasting already analyses POS data to create demand forecasts (Deputy). The implementation should:

1. Feed Square POS data to Deputy for automated demand forecasting
2. Set SPLH targets by day/daypart as scheduling constraints
3. Compare projected labour cost vs. projected revenue before publishing roster
4. Build a “Labour Cost %” widget in the dashboard: Target 25–30% for a bar venue

Real-time adjustments during shift:

• If sales are running 20%+ below forecast by the midpoint of the night, send one staff member home
• If SPLH is spiking above target (understaffed), the bar queue is likely building — call backup
• Daily feedback: Every morning, review yesterday’s actual SPLH vs. target. Did it hit? Why not?

5.5 Intra-Week Re-Forecasting

The best predictor of Saturday is Friday. The best predictor of Sunday is Saturday (FSR Magazine).

Implementation:

• Monday: Publish roster for the week based on forecast
• Wednesday evening: Re-forecast Thu–Sun based on actual Mon–Wed performance + updated weather + ticket velocity
• Friday evening: Final adjustment for Sat–Sun based on Friday actuals
• Each re-forecast adjusts hours by ±10–15% to “win the weekend”

5.6 Key Dashboard Widgets for Labour

Widget	Data Source	Threshold
SPLH (current shift, real-time)	Square + Deputy	Below target: amber; >15% below: red
Labour Cost % (week-to-date)	Deputy costs / Square revenue	>32%: alert
Projected vs. Actual hours (today)	Deputy roster vs. clock-in	>10% over: amber
Staff cost per event	Deputy hours × rates during event window	Compare to event revenue
Overtime hours this week	Deputy	>5% of total hours: flag

---

6. Alerting and Anomaly Detection

Beyond Velocity Alerts: A Comprehensive Alert Framework

The ticket velocity alerts already in place are a strong foundation. This section adds layers that catch problems the velocity model doesn’t see.

6.1 Statistical Foundation

Z-Score anomaly detection — the simplest method that works for daily venue data:

[ z = \frac{x - \mu}{\sigma} ]

Where (x) = today’s value, (\mu) = rolling mean (same day-of-week, 8 weeks), (\sigma) = rolling standard deviation.

Thresholds:

• |z| > 2.0: Anomaly flag (investigate)
• |z| > 3.0: Critical alert (immediate action)

Apply Z-score to: daily revenue, refund count, average transaction value, labour hours, F&B per cap.

STL Residual monitoring (from Section 3.1): Large residuals from the seasonal decomposition are anomalies by definition. Flag any residual > 2× the interquartile range of residuals. This automatically adjusts for day-of-week and seasonal patterns (Impact Analytics).

6.2 Alert Categories

Financial Alerts

Alert	Trigger	Data Source	Action
Revenue below forecast	Actual < 80% of forecast by shift midpoint	Square vs. model	Investigate: weather? low attendance? Adjust staffing
Unusual refund spike	Refund count > 2σ above daily average	Square + TryBooking	Check: staff theft? Product quality? Verify individual transactions
Average transaction drop	ATV drops >15% vs. same-day-of-week avg	Square	Menu issue? Payment terminal problems? Training gap?
Cost overrun	Event costs exceeding pro forma by >20%	Expense tracking	Review: unexpected production costs? Overtime?
Cash handling variance	Cash drawer variance > $50	Square cash reports	Audit: theft detection, till error review

Operational Alerts

Alert	Trigger	Data Source	Action
Bar queue building	Transactions-per-minute drops while attendance is high	Square + door count	Open additional service point, deploy barback
Stock depletion	Key SKU sales velocity × remaining stock < shift duration	Square inventory	Emergency restock or 86 the item
Labour cost exceeding target	Real-time labour % > 35% and rising	Deputy + Square	Send staff home, reduce deployment
No-show staff	Clock-in missing >15min after rostered start	Deputy	Activate backup list

Customer & Marketing Alerts

Alert	Trigger	Data Source	Action
Repeat attendance decline	4-week rolling repeat rate drops >5 percentage points	TryBooking	Investigate: pricing? quality? competition? Launch re-engagement
Ticket velocity stall	Sales pace <50% of historical for same days-out	TryBooking	Boost marketing, consider price adjustment or social push
Negative review spike	>2 negative Google/Facebook reviews in 24 hours	Review API or manual	Service recovery: respond immediately, investigate root cause
Social mention surge	Unusual volume of venue mentions (positive or negative)	Social monitoring	If positive: amplify. If negative: damage control within 15 min

Weather-Driven Alerts

Alert	Trigger	Data Source	Action
Rain day protocol	>70% rain probability for evening	BOM API	Reduce walk-in staffing by 15%, push ticketed event marketing
Extreme heat	Forecast >38°C	BOM API	Push “escape the heat” messaging, stock extra cold beverages
Unseasonable cold	Temperature >8°C below 30-day average	BOM API	Expect -12% walk-in traffic, consider adjusting open time

6.3 Alert Prioritisation & Routing

Three-tier alert system:

Priority	Colour	Delivery	Response Time	Example
Critical (P1)	Red	SMS + Dashboard	Within 15 min	Revenue 40% below forecast, refund spike >3σ
Warning (P2)	Amber	Dashboard + Morning briefing email	Same day	Labour cost trending above target, repeat rate declining
Informational (P3)	Blue	Dashboard only	Weekly review	Weather adjustment applied, minor forecast miss

6.4 Fraud & Loss Detection

Restaurant-specific loss patterns to monitor (Vyfoo):

• Void-after-close pattern: Voids processed after business hours → flag for review
• Discount clustering: Single staff member issuing >3× average discounts per shift
• Refund-without-receipt: Cash refunds without original transaction match
• Excessive over-pour: Spirits cost-of-goods rising without matching revenue increase (requires inventory tracking)

Implementation: Daily automated report: “Transactions requiring review” — voids, refunds, and discounts by staff member, sorted by deviation from average.

6.5 Anomaly Detection Methods — Advanced

For the developer implementing this, three practical approaches ranked by complexity:

Level 1: Statistical (implement first)

• Z-score on all key daily metrics
• Rolling standard deviation bands on weekly trends
• Threshold alerts on absolute values

Level 2: Decomposition-based

• STL decomposition residual monitoring
• Seasonal-Hybrid ESD (S-H-ESD) algorithm for detecting both local and global anomalies in the presence of seasonality — available as the anomalize R package or can be implemented in Python (XenonStack)
• Changepoint detection (BOCD) for identifying when a metric’s underlying distribution has shifted — useful for detecting gradual decline rather than single-day spikes (Impact Analytics)

Level 3: Machine learning (future state)

• Isolation Forest for multi-dimensional anomaly detection (flags unusual combinations — e.g., high attendance + low bar revenue + high refunds)
• Autoencoders trained on “normal” operating patterns — reconstruction error identifies anomalous days
• These require sufficient training data (which 8 years of Square data provides) but add implementation complexity

6.6 Morning Briefing Enhancement

The existing AI-generated morning briefing should incorporate all alerts. Recommended structure:

📊 DAILY INTELLIGENCE BRIEF — [Date]

HEADLINE: [One sentence: "Strong Friday – revenue 12% above forecast, 
driven by sold-out comedy show"]

🚨 ALERTS (if any):
- [P1] Refund rate for Saturday's event at 8.2% — above 5% threshold
- [P2] Labour cost trending 33% WTD — above 30% target

📈 YESTERDAY:
- Revenue: $X,XXX (vs forecast: $X,XXX, vs last week: $X,XXX)
- Attendance: XXX (XX% capacity)
- F&B per cap: $XX.XX
- SPLH: $XX (target: $XX)

📅 TODAY'S OUTLOOK:
- Weather: 18°C, 30% rain — expect average walk-in traffic
- Events: [Event name] — [XX] tickets sold (XX% capacity, pace: 
  ahead/behind historical)
- Staffing: [XX] rostered hours, projected SPLH: $XX
- Forecast revenue: $X,XXX

🎯 ACTIONS:
- [Generated from alerts and thresholds — specific, actionable items]

📊 WEEKLY TRENDS:
- Saturday 8-week trend: [direction] 
- Top performing event this week: [name] (margin: XX%)
- Repeat attendance rate: XX% (trend: stable/rising/falling)

---

7. Implementation Roadmap

Phase 1: Foundation (Weeks 1–4)

• Implement SPLH tracking with Square + Deputy data
• Add weather data integration (BOM API)
• Build event P&L automation with time-window bar attribution
• Deploy Z-score anomaly detection on daily revenue and refund metrics
• Upgrade morning briefing with alert integration

Phase 2: Intelligence (Weeks 5–8)

• Build STL decomposition pipeline on 8 years of historical data
• Implement cohort analysis (customer matching across TryBooking + Square)
• Deploy the event normalisation framework and scorecard
• Add demand forecasting model to morning briefing
• Build real-time SPLH dashboard widget with Deputy integration

Phase 3: Optimisation (Weeks 9–12)

• Implement dynamic ticket pricing signals based on velocity
• Add weather-adjusted demand forecasting
• Build the full event pro forma / offer sheet calculator
• Deploy customer CLV segmentation and automated re-engagement triggers
• Add fraud/loss detection reporting

Phase 4: Advanced (Ongoing)

• Implement Isolation Forest multi-dimensional anomaly detection
• Build predictive event P&L models
• Add social media sentiment monitoring
• Test and refine pricing elasticity models
• Add competing events tracking

---

Appendix: Data Source Integration Map

Data Source	Key Data	API/Method	Refresh Rate
Square POS	Transactions, items, refunds, voids, customers	Square API	Real-time (webhook) or 15-min poll
TryBooking	Ticket sales, customer emails, event details, refunds	TryBooking API / CSV export	Hourly
Deputy	Rosters, clock-in/out, labour costs, timesheets	Deputy API	Real-time
BOM Weather	Temperature, rainfall, forecast	BOM API	6-hourly forecast, daily actuals
Google Reviews	Ratings, review text	Google Business Profile API	Daily
Social Media	Mentions, sentiment	Manual or tool (Agorapulse, Brandwatch)	Daily
Competitor Calendars	Competing events	Manual entry or web scraping	Weekly