Call analytics
Answered, missed, returned
Unified classification with hourly heatmaps, a monthly call calendar, operating-hours filters, and a missed-call follow-up panel.
Case study · Multi-venue restaurant & nightlife group
Four systems. One truth.
A hospitality intelligence platform that reconciles sales, reservations, phone coverage, and reviews into one screen — with a grounded AI analyst that never makes up a number.
01 / The problem
Four dashboards. Four logins. No shared key.
A multi-venue restaurant and nightlife group with an in-house call centre had its operational data scattered across four unrelated systems: a phone system (call logs), a point-of-sale (sales), a reservations platform (covers), and Google Business (reviews).
The systems shared no common identifier. No single screen could answer a question as basic as “How did this venue do yesterday — sales, reservations, and phone coverage?” Answering it meant four logins and manual spreadsheet reconciliation.
The build: one platform that reconciles everything behind a canonical venue registry, and a conversational AI analyst on top — grounded so completely in live data that every number in every answer comes from a tool call made in that turn.
0
systems reconciled behind one registry
0
commits over 15 months of development
0
serverless edge functions
0
grounded AI data tools
02 / Venue identity
The same venue, four different names.
Each system keys a venue its own way — and the mapping isn't even 1:1. Shared phone queues ring every venue at once, one venue owns several extensions, and each venue's corporate-events ledger is a separate entity that must never blend into its main numbers.
POS
Veloce
Sales, products, covers
location UUID
9f31c2…
9f31c2…
Reservations
SevenRooms
Booked & seated covers
venue_name
"Yoko Luna"
"Yoko Luna"
Phone
CDR / call logs
Calls & recordings
extension
104, 109
104, 109
Reviews
Google Business
Ratings & reviews
place / location ID
ChIJd8…
ChIJd8…
Try the venue registry.
A canonical registry joins all four systems, with typo-tolerant matching so a messy spelling still resolves to the right venue. Type something — or tap an example.
Identifiers shown are illustrative placeholders, not production keys.
The canonical record appears here.
03 / The hardest part
What even is “a missed call”?
Raw phone data arrives as one row per call leg — a single real call can be five or more rows. We encoded one defensible session model in a single Postgres function, so every dashboard and the AI agree on every number by construction. Watch it classify a call.
Raw CDR legs (one row each)
Classifier output — one row per session
Illustrative call data. The real classifier is a ~200-line SQL function with five CTE stages.
04 / The AI analyst
Ask anything. Every number is real.
The analyst answers plain-English questions through 12 purpose-built data tools. The rule is absolute: every figure, date, or name must come from a tool call made in the current turn — no invented numbers, no stale reuse, no blending corporate ledgers into venue totals.
Illustrative conversations — figures are placeholders, the tools and rules are real.
Always on, even when a provider isn't.
The engine runs as its own always-on service — serverless functions kill a streamed answer at ~26 seconds, so the browser streams straight from the engine instead. A three-tier model router keeps the analyst up when a provider is rate-limited. Try it.
Tier 1 · Claude
Subscription login — primary, no API key
Tier 2 · Gateway
Local OpenClaw gateway (OAuth)
Tier 3 · OpenRouter
API key — last resort
All tiers healthy — routing to Tier 1 (Claude). Every turn is traced to LangSmith with the router's choice tagged.
05 / The platform
Everything an operator needs, one login.
Business recap
Sales + calls + covers, by day
The flagship cross-system view that was impossible before the registry: every venue's day lined up across all four systems.
Calls list
Every call, playable
Venue-merged, channel-aware filtering over large datasets (virtualized), with notes, bulk operations, exports, and built-in recording playback.
AI call analysis
Transcripts & sentiment
“Aura” downloads recordings, transcribes them, and produces AI summaries and sentiment through an automated pipeline.
Reservations & reviews
Covers and reputation
Booked and seated covers reconciled to canonical venues, plus Google reviews that sync themselves every 15 minutes — with reply-from-the-dashboard.
Forecasting
Tomorrow, predicted
A Python/Prophet service trains per-venue sales and covers forecasts with plain-language explanations — readable by operators and by the AI analyst.
Under the hood.
Three separately-deployed runtimes around one Postgres core. Tap any component.
Web app
Core & runtimes
Reconciled sources
Frontend
- Next.js 16
- React 19
- TypeScript
- Tailwind CSS
- shadcn/Radix
- TanStack Query
- Recharts
- Framer Motion
Backend & data
- Supabase Postgres
- 44 Deno edge functions
- Postgres RPCs & RLS
- pg_cron
AI & ML
- Claude Agent SDK
- LangChain / LangGraph
- LangSmith tracing & evals
- Pinecone
- Python + FastAPI
- Prophet forecasting
Infrastructure & quality
- Netlify
- Render (always-on engine)
- Fly.io
- Docker
- Vitest + Testing Library
- Golden-question eval suite
06 / Why this was hard
Plausible-but-wrong is the enemy.
In a BI tool, a wrong number is worse than no number. The deepest work went into correctness.
01
No shared keys across systems
The central problem wasn't wiring APIs — it was defining what a “venue” even is across four systems that disagree, including corporate-ledger separation and shared phone queues.
02
The data model of a call is non-trivial
Turning per-leg phone rows into one defensible session model — with callback reconciliation and venue attribution — and forcing three surfaces plus an AI to agree by construction.
03
Grounded AI over messy operational data
An assistant provably backed by live data: venue-ID scoping, no stale-number reuse, an engine-side grounding guard, and a golden-question eval harness that catches regressions automatically.
04
Serverless streaming constraints
The ~26-second ceiling on streamed responses forced a real architectural split: an always-on engine, direct browser streaming, a prepare/persist token flow, and three-tier model failover.
05
Production hardening under real usage
A long tail of subtle correctness bugs — silent date-range truncation, RLS policy recursion, channel-only outbound extensions — each producing plausible-but-wrong numbers that had to be hunted down.
07 / Outcome
Four logins became one question.
A single platform where an operator — or an AI asked in plain English — can see, for any venue and any day, a reconciled picture of sales, reservations, phone coverage, and reputation, with forecasts and AI call summaries layered on top.
What previously required four logins and manual spreadsheet reconciliation is now one grounded question.
✦
The client group is not named in this write-up; venue names appear as they do in the build and are used with permission. Figures and identifiers in the interactive demos are illustrative placeholders — the architecture, tools, and rules described are the real build.
Start here
Drowning in dashboards that don't agree?
If your numbers live in systems that can't talk to each other, this is the problem we love. Let us show you what one reconciled picture of your business would look like.