ReviewReply — the spec

ReviewReply is a SaaS tool that automatically drafts Google review responses for solo business owners. It pulls in new reviews via Google's API, detects each review's sentiment, generates a tone-matched reply, scores the draft for quality, and surfaces everything in a single approval queue — so owners spend minutes, not hours, managing their online reputation.

---

Decisions locked

---

The core loop

1. Owner connects their Google Business Profile via one-click OAuth — no credentials stored, token only.
2. ReviewReply polls for new reviews and classifies each as positive, negative, or neutral.
3. The AI generates a draft response, applying the tone template the owner has set (warm, professional, or apologetic).
4. The quality scorer evaluates the draft and flags low-confidence replies with a suggested improvement.
5. Owner opens the approval queue, reads the drafts, edits any flagged ones, and approves the batch.
6. ReviewReply posts approved responses to Google on the owner's behalf via the API.

---

v1 scope

One-click Google Auth — OAuth 2.0 connects both Gmail identity and Google Business Profile in a single flow. Lives on the Onboarding screen; no manual API key entry required.

Sentiment Detection — each incoming review is automatically classified as positive, negative, or neutral using the review text. The label is displayed as a tag in the Approval Queue so owners immediately know what they're dealing with.

Tone Templates — three presets (Warm, Professional, Apologetic) configurable per business. The AI selects the appropriate template based on sentiment by default; owners can override per-review in the queue.

Response Quality Scoring — every AI draft receives a score (e.g. 0–100) based on relevance, length, and tone consistency. Drafts below threshold are flagged with a plain-English suggestion for improvement, shown inline in the Approval Queue.

---

Deliberately later

• Bulk approve without editing — useful once owners trust the AI's output quality; v1 earns that trust first.
• Review analytics dashboard per location — meaningful only after enough response history exists to surface trends.
• Scheduled posting at optimal times — adds posting-time complexity before the core reply workflow is validated.
• Competitor response benchmarking — requires a separate data acquisition layer; a v2 differentiator once retention is proven.

---

Data model sketch

• users — id, email, google_oauth_token, subscription_status, created_at
• business_profiles — id, user_id, google_location_id, business_name, default_tone_template
• reviews — id, business_profile_id, google_review_id, author_name, rating, body, sentiment_label, received_at, status (pending / approved / posted)
• response_drafts — id, review_id, draft_body, quality_score, score_feedback, tone_template_used, edited_body, approved_at
• tone_templates — id, name (warm / professional / apologetic), system_prompt_snippet
• api_sync_logs — id, business_profile_id, synced_at, reviews_fetched, errors
• subscriptions — id, user_id, plan, stripe_customer_id, stripe_subscription_id, status, current_period_end

---

Screens

• Onboarding / Connect — walks the owner through Google OAuth and confirms the Business Profile is linked.
• Approval Queue — the main working screen; lists pending reviews with sentiment tags, draft responses, quality scores, and edit/approve controls.
• Settings — Tone Templates — lets the owner choose default tone per sentiment class and preview how the prompt behaves.
• Account & Billing — manages subscription plan, payment method via Stripe, and invoice history.
• Review Detail — expanded single-review view for editing a draft inline and reading the full quality score feedback.

---

How to use this document

• Bring it into Mind Palace, where the guided platform and its AI coach pick up from exactly this document and build the product with you step by step.
• Hand it to a developer as the complete v1 brief — every scope decision, data model, and screen boundary is already resolved.
• Keep it as the single source of truth while you build, so any new feature request is measured against it before the scope moves.