Sandbox VR Alpharetta runs on a stack most venues would recognize: one tool takes the money, another takes the bookings, three separate platforms run the ads, and the phone, the reviews, the inbox and the web analytics each live somewhere else again. We pulled all of it into a single gated operations platform, then built the tools that only become possible once the data sits together.
The problem
Nothing was missing. Every number existed somewhere, in a vendor dashboard built to answer that vendor's question. What did not exist was one place where the day's bookings, the money that actually landed, the ad spend that drove it, the calls nobody picked up and the reviews that followed could be read against each other.
Twelve logins
One question, twelve places
Payments, bookings, three ad platforms, phone, reviews, web analytics, email inquiries and organic social each had their own dashboard, their own definitions and their own date handling. Answering a single question about the business meant opening most of them and reconciling by hand.
Three ad platforms
No number that meant the same thing
Google, Meta and TikTok each report spend and conversions on their own attribution model and their own window. Read side by side without normalizing them first and the comparison is meaningless, which makes the budget decision a guess.
Nothing predictive
Every tool looked backwards
Vendor dashboards report what happened. None of them could say what next Tuesday looks like, how many staff it needs, or whether pausing a campaign actually cost anything rather than simply coinciding with bad weather and a school week.
The solution
A Cloudflare Worker pulls every source on a schedule and writes one normalized payload. A password-gated dashboard reads it. Everything below the first card only works because that layer exists: you cannot ask a question across the business until the business is in one shape.
A scheduled Worker ingests payments, bookings and availability, all three ad platforms, call and SMS records, Google reviews, session and channel analytics, event inquiries from the inbox, organic social, transactional email and local weather. Sources without a usable API are bridged by in-account scripts that push into the same pipeline. Everything lands normalized in KV, so every surface downstream reads one shape instead of twelve.
Stack: Cloudflare Workers, KV, cron triggers, Google Apps Script bridges for analytics, ads and inbox.
A question box that answers from the live operating payload rather than from training data. It carries prior turns, so a follow-up like "is that today or the total?" resolves against what was just asked instead of latching onto the first number it sees. Strictly read-only: it reports on the business, it never changes anything in it.
Stack: Workers AI running Llama 3.3 70B, grounded on the live payload, multi-turn context, read-only by construction.
The dashboard does not wait to be interrogated. On every scheduled refresh the Worker writes a short brief in plain language covering where the week stands, what moved and what needs attention, and serves it at the top of the dashboard. Opening the tab is enough. Nobody has to know which panel to check first.
Stack: Generated on the cron run, cached in KV, served read-only to the gated dashboard.
All three ad platforms normalized to a common shape and rendered as one blended view plus a per-channel breakdown, so the budget conversation happens against comparable numbers. Alongside it, a booking-source panel lays online purchases by acquisition channel next to the walk-in and same-day split, because attribution that ignores the guests who never touched a campaign flatters every campaign.
Stack: In-account ads script to Worker for one channel, normalized ingest for the others, GA4 channel feed on a six-hour cycle.
A model built on the things that actually move a venue day: day of week, local events, school and holiday calendars, and weather. It drives a staffing tier so labor is planned against expected demand rather than last week's feeling, and it was recalibrated against logged trading days, which cut walk-forward error by roughly a third. The same model powers an incrementality holdout: when spend is paused, the question is not whether bookings fell but whether they fell below what the model expected anyway.
Stack: Pure-function forecast model shared by the dashboard and the staffing view, walk-forward calibration, holdout comparison against expected demand.
The same guest arrives as a booking, a payment, a phone number, an inbox enquiry and a widget conversation, spelled differently each time. A contact graph resolves them into one record, so a name on the board carries everything that person has ever done with the venue rather than whichever fragment the tool in front of you happens to hold.
Stack: Identity resolution in the Worker across booking, payment, phone and inbox records, served password-gated to the dashboard.
Authentication runs in middleware ahead of any asset being served, so no financial figure reaches a browser unauthenticated. Beyond a single password, roles decide which lanes and panels a given person sees, and the parts of the board the team edits by hand are shared state, so what one owner marks as done is what the next one opens.
Stack: Pages Functions middleware with HMAC session cookie, role-scoped API responses, shared editable state in KV.
Vendor dashboards show you a window and forget it. Every trading day is written down here with the weather and the calendar it happened under, which is what makes the forecast trainable and the holdout test possible at all. It also means a question about a Tuesday in July has an answer, rather than depending on whether someone screenshotted it at the time.
Stack: Daily sales, weather and calendar history written by the refresh Worker to KV, served to the dashboard and read by the forecast calibration.
Built on the same data layer: the AI booking agent and the local outreach engine.
The results
The figures below are the operator's estimate of displaced manual work rather than instrumented measurement, itemized rather than asserted so they can be argued with. They cover the reporting layer only. The outbound and guest-facing systems built on the same data are counted on their own case studies so no hour is claimed twice.
12
Live sources in one payload
Payments, bookings, three ad platforms, calls, reviews, web analytics, the inbox, organic social, email and weather, refreshed on a schedule and normalized to one shape. The platforms without a usable API are bridged by in-account scripts pushing into the same pipeline.
Ask it
Answered from live data, not training data
Questions are typed in plain English and answered from the current operating payload, carrying prior turns so a follow-up resolves against what was just asked. A written brief is regenerated on every refresh, so opening the tab is enough.
~5.5 hrs
Weekly reporting recovered
Roughly 1.5 hours pulling three ad platforms into comparable shape, 2 on the daily read, 2 more working out why two sources disagree, and half an hour planning staffing off a spreadsheet. Outbound and guest-facing time is counted on the other two case studies.
Underneath: recalibrating the demand model cut walk-forward forecast error by roughly a third, which is what makes it usable for planning staff rather than interesting to look at. Zero exports are needed to answer a question, and 1,711 automated tests across the agent, the Worker and the dashboard run before every deploy. Access is role-gated, with authentication enforced in middleware ahead of any asset being served. Commercial figures for the venue are the venue's to publish, not ours.
Built for one venue. Replicable for yours.
If answering a straightforward question about your business means opening six tabs and a spreadsheet, the problem is not reporting, it is that nothing is joined up. We scope, build and hand off custom software for operators. Book a free 30-minute audit call and we will tell you exactly what we would unify first.
Book a Free Audit Call