What I built — and why I picked it.
Braden Auto Group's existing dashboard is a great command-center surface for raw KPIs. The gap is the second-order question every GM has at 7:00 AM: what should I actually do today? This feature closes that gap with personalized, AI-generated daily briefings — one per store, every morning.
The pitch in one paragraph
Why this is the right next move
A 12-store dealer group already has the data. The problem is that 12 GMs each spend 30+ minutes every morning translating spreadsheets into a plan for the day. That's 60+ hours a week of leadership time spent on a task an AI can do in 6 seconds — and do more consistently, with the same statistical rigor across every store. The briefing gives ownership a single, comparable view of how every GM is starting their day. That's the kind of leverage an AI Operations Builder is hired to ship.
Architecture
Why the math is in code, not the prompt
- Data layer. Deterministic mock generator (Mulberry32-seeded) produces 14 days of realistic KPIs per store. Same seed → same numbers, so screen recordings are stable. In production this swaps for a DMS / data warehouse adapter — the rest of the stack doesn't care.
- Signal computation. Pure TypeScript reads each KPI, computes z-score vs the 7-day baseline, ranks by severity, and builds a typed
Signalsbundle. Unit-tested. The LLM never does arithmetic — that's where it's least reliable. - Claude tool-use. Signals are formatted into a prompt and sent to Claude with a strict JSON tool schema (
submit_briefing). Claude's job is purely narration — pick a headline, write three sentences, propose three actions. The response goes through Zod validation before reaching the UI. - Graceful fallback. If there's no API key, or the LLM call fails, or its output fails schema validation, a deterministic templated briefing built from the same signals takes over. The demo is never broken.
- Streaming UI. The page shell renders synchronously with the store profile and KPI grid. The briefing streams in via React Suspense so navigation is instant — the LLM latency is hidden.
Make.com / n8n delivery
The dashboard isn't where GMs read briefings — their phones are
The JD's example is “GM daily scorecard delivered to every GM's phone every morning automatically” — not a website GMs have to navigate to. So the engine ships with a webhook endpoint built for Make.com / n8n.
GET /api/morning-broadcast returns all 12 generated briefings plus ready-to-send email (subject + HTML body) and Slack (mrkdwn blocks) payloads, addressed to each GM and pre-ranked by attention needed. A Make.com scenario is six modules: cron → HTTP → iterator → Gmail + Slack. Wire it once, it runs every weekday at 6:30 AM. Scenario blueprint and an importable n8n workflow are in automations/.
What I'd build next
The same engine, the JD's other named tools
The morning briefing is the kernel. Same Signal pipeline, same tool-use + Zod pattern, different narrator and delivery target — every other tool the JD calls out is a fork of this one.
- BDC response bot. Lead-arrival webhook → Claude drafts a personalized reply → CRM API in under 60 seconds. The 52% → 80%+ contact-rate move the JD is targeting.
- Inventory intelligence agent. Aged units + days-supply signals → Claude proposes price drops → Dealertrack feed. Chad stops managing the spreadsheet.
- Vendor invoice monitor. PDF/email ingest → extract → compare to contracted rates → flag overcharges in Slack. Catches the Dealertrack double-billing before two years pass.
- Acquisition underwriter. Deal-data form → IRR / payback / go-no-go memo → emailed to ownership in under five minutes.
- Platform Manager financial briefing. The same broadcast endpoint, group-rolled-up + bottom-three, delivered at 7 AM.
- Role-aware briefings. Sales Manager gets desk actions, Service Manager gets bay/RO actions, F&I Manager gets product-penetration coaching — one signal pipeline, three prompts.
- Action follow-through tracking. Did yesterday's actions move the metric? Loop the outcome into tomorrow's briefing as accountability — and as RLHF-style training data for the engine itself.
Why this is also a GOAT OPS kernel
The pattern that makes this a $3M ARR conversation in 18 months
Every dealer group in the country has the same problem at 7 AM — and is buying the same dashboards that don't solve it. The architecture here (deterministic data adapter → pure-TS signal compute → Claude tool-use narrator → multi-channel delivery) is brand-, DMS-, and group-agnostic.
Swap the data adapter for a different DMS, swap the store roster, swap the brand colors. The compute, the prompt scaffolding, the Make.com / n8n delivery, the fallback-never-breaks demo discipline — all of that is the product. Each net-new tool (BDC bot, inventory agent, invoice monitor) ships on the same kernel and licenses on the same contract.