Case
Multi-Tenant MEO SaaS for Inbound-Heavy Retail
A two-layer SaaS — operator admin plus client-facing SPA — handles monthly insight reports, AI-drafted bilingual posts, AI review replies with low-rating alerts, and policy self-check, with a human approval queue between every AI step.
Client
- Name
- Multi-store retail / F&B operator
- Business
- GBP-managed local businesses (10+ locations)
- Location
- Tokyo / inbound-heavy districts
- Revenue
- Per-store monthly retainer model
- Staff
- One operator agency + N client stores
Demo
What was breaking
01
Posts are written one store at a time — no consistency across locations and no way to scale without hiring
02
Review replies pile up across multiple languages; same-day response is structurally impossible
03
Profile-policy violations slip through manual review; suspensions cost a month of visibility
04
Operator burns context-switching between tenants; no single approval queue
05
Tenant data lives in spreadsheets; no clean isolation when a client churns
Before / After
| Metric | Before | After |
|---|---|---|
| Post creation cycle | Manual per-store | 1 SPA / month |
| Review reply turnaround | Days, single language | Same-day, multilingual |
| Policy-violation risk | Manual review | AI self-check + human approval |
| Operator load | Per-store context-switch | Single approval queue |
| Tenant isolation | Spreadsheet-based | RLS-enforced per client |
Notes from the build
Context — Inbound-heavy retail and F&B operators sit on Google Business Profile real estate that decays the moment posting cadence slips. Manual operations don't scale past a handful of stores. The brief was to build a production SaaS that lets a single operator agency run dozens of stores without losing the human-in-the-loop discipline that keeps GBP listings from being suspended.
Architecture — Two interfaces, one shared backend.
The operator admin is the agency-side console: monthly insight reports auto-batch on day 1; AI-drafted posts and review replies queue here for approval; profile-improvement suggestions escalate from data analysis. Everything passes a human before it touches Google.
The client SPA is per-store: one URL per location, surfacing last month's results and this month's post setup on a single page. The client uploads photos, writes one short context paragraph, and the AI handles bilingual copy. No login fatigue, no admin burden on the merchant.
Underneath: Supabase with row-level security per tenant, n8n workflow group orchestrating GBP API calls, OpenAI / Claude for bilingual generation, and a multilingual auto-detect layer for incoming reviews.
The Two-Layer Decision — The temptation was to build a single admin app and onboard merchants directly. The two-layer split exists because the agency owner is the only person who should ever press "publish." Merchants see results and provide raw material; the agency runs operations at scale. The SaaS encodes that operating model into the product.
What Got Cut — No automated GBP onboarding (manual setup is a one-time cost the agency absorbs). No AI-only publishing (every post and reply is approved). No customer-facing analytics dashboard (the monthly insight email is enough). Each cut sharpened the product around the agency operator's actual job.