System Requirements Document for no-show-appointments

1. Introduction

no-show-appointments is a production-ready Micro SaaS that protects revenue for appointment-based businesses — physiotherapy clinics, dental clinics, salons, tutors, coaches and similar service businesses — by reducing missed appointments and recovering cancelled time slots.

The product connects to a business's existing calendar or booking system, automatically sends appointment confirmations and reminders through SMS, WhatsApp or email, and gives each customer a one-tap link to confirm, reschedule or cancel. When a cancellation occurs the business is alerted immediately and can message a waitlisted customer to fill the emptied slot. Businesses may optionally collect deposits or store payment details to discourage no-shows.

The core value is direct revenue protection: fewer no-shows mean more completed appointments and higher monthly revenue. Automated reminders are widely reported to reduce missed appointments by roughly 20–50%.

Audience. Owner-operators and front-desk staff at small appointment-based businesses (targeting one niche first — physiotherapy clinics, dental clinics or salons), the customers those businesses serve, and the platform team that operates the SaaS itself.

Business model. Recurring SaaS subscription priced at $29–$99/month, with additional charges for high SMS/WhatsApp volume.

2. System Overview

no-show-appointments is delivered as a first-party web application with a public marketing surface, an application-owned identity surface, a public one-tap appointment response surface, a protected business workspace, and a role-restricted platform administration surface. A backend service provides REST APIs, persistence, calendar synchronization, scheduled reminder dispatch, cancellation alerting, waitlist messaging, Stripe subscription billing, analytics aggregation and platform oversight. Background automation (reminder scheduling, calendar sync, alert dispatch) runs server-side; every human-facing outcome is observable in a first-party page.

Actors.

• Business Owner / Practice Manager — runs the business, connects the calendar, configures reminders, reviews the no-show dashboard and analytics, manages the optional waitlist, and owns billing and settings.
• Front-Desk Staff / Appointment Coordinator — works cancellation alerts day to day and messages waitlisted customers to refill opened slots.
• Platform Administrator — operates the SaaS itself and oversees subscribing businesses, subscription status, and platform activity and errors.
• Appointment Customer (non-persona participant) — receives confirmation/reminder messages and responds through a one-tap link without an account.

External systems. Google Calendar (and other connected booking systems), SMS/WhatsApp/email delivery providers, and Stripe.

Current scope (MVP). Calendar integration, automated reminders, one-tap confirm/reschedule/cancel links, cancellation alerts, a simple no-show dashboard, an optional waitlist, optional deposit/payment-detail collection, Stripe subscriptions, authentication with Google Login and Email Login, analytics, admin dashboard, user settings, billing page, responsive design, dark mode, SEO, error handling and loading states.

Explicit exclusions from the current phase. AI-based no-show risk scoring, smart reminder timing, personalized messages and automatic waitlist offers are later-phase features and are not part of the MVP.

2a. Product Interpretation and Delivery Boundary

The product is a first-party application. Public visitors can read the landing page and pricing page without an account. Business owners and staff establish identity through a shared Login surface (Google Login or Email Login, with self-service enrollment) before reaching any protected business surface. The platform administrator authenticates through the same Login surface and is authorized for the role-restricted Admin dashboard. Appointment customers never create an account: they reach the Appointment Response page through a one-tap link embedded in a confirmation or reminder message.

Calendar connection, reminder configuration, waitlist management, billing and settings are owned by the business workspace. Cancellation alerts and waitlist messaging are owned by the Cancellations working surface. Platform-level oversight is owned exclusively by the Admin dashboard.

The product may initially be validated manually using n8n before the full software is relied upon; the delivered application is the production system of record. Later-phase intelligence features (risk scoring, smart timing, personalized messages, automatic waitlist offers) are documented in Section 11 and are excluded from current pages and acceptance.

2b. Source Content Inventory

The reference directive for https://www.capterra.com/p/159212/Appointment-Reminder/ declares domain_context and feature_reference uses only — it is not a content_source, so no content inventory is reproduced. Its domain and feature expectations are reflected as product context and feature expectations in Sections 2, 3 and 9 (calendar sync with Google Calendar/Outlook/Apple Calendar, SMS and email reminders, customizable message templates, mobile access, integrations, and the $29/month entry tier with 400 reminders). No Capterra listing copy, review text, vendor names or support claims are adopted as product content.

2c. Page Content and Component Coverage

Landing page

• Purpose & access. Public entry (no identity required). Explains the no-show recovery product, its audience and its value.
• Information/state. Hero headline "The 2pm that never showed just got filled."; subline describing revenue protection; proof band citing the commonly reported 20–50% reduction in missed appointments; feature band covering calendar integration, automated SMS/WhatsApp/email reminders, one-tap confirm/reschedule/cancel, cancellation alerts, no-show dashboard and optional waitlist; teal waitlist band; pricing teaser; live recovery ticker strip.
• Primary actions. "Start free for 14 days" (→ Login, enrollment), "See a 90-second demo" (in-page demo), "See pricing" (→ Pricing page), "Sign in" (→ Login).
• Supporting actions. Theme toggle (light/dark); anchor navigation to feature bands.
• Domain entities. Plan (teaser), recovery event (ticker items).
• Component responsibilities. Hero split 7/5 with coral colour block on "filled"; recovery ticker marquee (pauses on hover, static wrapped rows under reduced motion); illustrated feature cards with 4px ink outline and hard offset shadow; pricing teaser cards; footer with SEO metadata and links.
• States. Loading: skeleton for ticker and pricing teaser. Empty: ticker falls back to illustrative sample events labeled as examples. Success: full render. Error: if plan data fails, pricing teaser shows a retry control and a link to the Pricing page. Recovery: retry re-fetches without losing scroll position.

Pricing page

• Purpose & access. Public (no identity required). Presents subscription tiers priced $29–$99/month with additional charges for high SMS/WhatsApp volume.
• Information/state. Tier cards (name, monthly price, included reminder volume, overage rate for SMS/WhatsApp), feature comparison, FAQ on volume charges.
• Primary actions. "Choose plan" (→ Login if unauthenticated, then Billing page checkout); "Start free for 14 days".
• Supporting actions. Monthly/annual toggle if offered by plan data; theme toggle.
• Domain entities. Plan, price, included volume, overage rate.
• Component responsibilities. Tier cards with coral primary CTA on the recommended tier; comparison table; volume-charge explainer.
• States. Loading: card skeletons. Empty: not applicable (plans are seeded). Success: tiers render with current prices. Error: inline error with retry; CTA disabled until plans load. Recovery: retry.

Login

• Purpose & access. Public identity surface (no identity required to view). Supports Google Login and Email Login, self-service enrollment, and returning verification for Business Owner / Practice Manager, Front-Desk Staff / Appointment Coordinator and Platform Administrator.
• Information/state. Google Login button; email + password fields; enrollment (sign-up) mode; validation and error messages; post-login destination (Dashboard for business users, Admin dashboard for platform administrators).
• Primary actions. "Continue with Google"; "Sign in with email"; "Create account" (self-service enrollment).
• Supporting actions. Toggle between sign-in and enrollment; password visibility toggle; theme toggle.
• Domain entities. User identity, session, role (business user vs platform administrator).
• Component responsibilities. Auth form with inline validation; provider button; redirect handling for protected destinations.
• States. Loading: button spinner and disabled inputs during submission. Empty: initial form. Success: redirect to intended protected page. Error: invalid credentials, duplicate enrollment, provider failure — inline message with recovery path. Recovery: retry; password reset guidance.

Appointment Response

• Purpose & access. Public, account-free destination reached through a one-tap link in a confirmation or reminder message. The customer confirms, reschedules or cancels.
• Information/state. Appointment details (business, service, date/time, practitioner where applicable); current response state (awaiting, confirmed, reschedule requested, cancelled); confirmation of the recorded action.
• Primary actions. "Confirm", "Reschedule", "Cancel" — one tap each.
• Supporting actions. Choose a new time when rescheduling; view business contact.
• Domain entities. Appointment, response, reschedule request.
• Component responsibilities. Token-validated response panel; action buttons; reschedule time picker; result banner.
• States. Loading: appointment skeleton while token resolves. Empty: invalid/expired link message with business contact. Success: action recorded and confirmed on screen. Error: action failed — retry offered, original state preserved. Recovery: retry; link re-issue guidance.

Dashboard

• Purpose & access. Protected, role-restricted to Business Owner / Practice Manager. Simple no-show dashboard summarizing missed appointments and recovered slots.
• Information/state. "Revenue protected" display figure on a teal colour block; counts of upcoming appointments, confirmed, no-shows, cancellations, recovered slots; recent activity list; connection and reminder status.
• Primary actions. Drill into a no-show or recovered slot; navigate to Cancellations, Analytics, Integrations.
• Supporting actions. Date-range selector; theme toggle.
• Domain entities. Appointment, no-show record, recovered slot, revenue figure.
• Component responsibilities. Stat blocks with tabular figures; activity list; status banners for disconnected calendar or paused reminders.
• States. Loading: stat skeletons. Empty: onboarding prompt to connect a calendar when no data exists. Success: populated summary. Error: per-widget error with retry. Recovery: retry; link to Integrations when the calendar is disconnected.

Cancellations

• Purpose & access. Protected, role-restricted to Front-Desk Staff / Appointment Coordinator and Business Owner / Practice Manager. Working surface for immediate cancellation alerts and messaging waitlisted customers.
• Information/state. Chronological cancellation alerts (customer, appointment time, service, received-at); slot status (open, offered, filled); waitlist candidates matched to the slot.
• Primary actions. Open an alert; select a waitlisted customer; send a fill-slot message; mark slot filled or closed.
• Supporting actions. Filter by status; refresh; view customer response.
• Domain entities. Cancellation alert, opened slot, waitlist entry, outbound message.
• Component responsibilities. Alert feed; slot detail panel; waitlist candidate list; message composer with template selection; delivery status.
• States. Loading: feed skeleton. Empty: "No cancellations right now" with reassurance copy. Success: alert acknowledged and message sent with delivery status. Error: message send failure with retry and preserved draft. Recovery: retry; fall back to another candidate.

Waitlist

• Purpose & access. Protected, role-restricted to Business Owner / Practice Manager. Owner-managed optional waitlist of customers available to fill emptied slots.
• Information/state. Waitlist entries (customer name, contact channel, preferred service/practitioner/time window, added date, status); enable/disable state for the optional waitlist.
• Primary actions. Add entry; edit entry; remove entry; enable or disable the waitlist.
• Supporting actions. Search and filter; import sample entries.
• Domain entities. Waitlist entry, customer contact.
• Component responsibilities. Entry table; add/edit form; enable toggle; empty-state guidance.
• States. Loading: table skeleton. Empty: explanation that the waitlist is optional, with "Add first customer". Success: entry saved and listed. Error: validation or save failure inline. Recovery: retry; unsaved input preserved.

Integrations

• Purpose & access. Protected, role-restricted to Business Owner / Practice Manager. Connects the existing calendar or booking system and configures automated confirmation and reminder channels.
• Information/state. Connected calendar(s) with status and last sync; reminder schedule (confirmation timing, reminder timing); channel selection (SMS, WhatsApp, email); message templates; template customization.
• Primary actions. Connect Google Calendar (provider OAuth); disconnect; save reminder schedule; select channels; edit and save message templates; send a test message.
• Supporting actions. Re-sync now; view sync errors.
• Domain entities. Calendar connection, reminder rule, channel, message template.
• Component responsibilities. OAuth connect card; schedule editor; channel toggles; template editor with variable insertion; sync status panel.
• States. Loading: connection status skeleton. Empty: "Connect your calendar to start" prompt. Success: connected status, saved schedule confirmation, test-message delivery status. Error: OAuth failure, sync failure, template validation error — inline with retry. Recovery: reconnect; retry sync; revert unsaved template.

Analytics

• Purpose & access. Protected, role-restricted to Business Owner / Practice Manager. Reporting on no-shows and recovery performance.
• Information/state. No-show rate over time; reminders sent by channel; confirmations, reschedules, cancellations; recovered slots and recovered revenue; comparison to the commonly reported 20–50% reduction range as context.
• Primary actions. Change date range; change grouping (day/week/month); export report.
• Supporting actions. Filter by service or practitioner where data exists.
• Domain entities. Aggregated appointment outcomes, channel usage, recovered revenue.
• Component responsibilities. Trend chart; breakdown table; KPI headline in Sora 700 tabular figures; export control.
• States. Loading: chart skeleton. Empty: prompt to connect a calendar and send reminders when no history exists. Success: charts and tables render. Error: chart-level error with retry. Recovery: retry; narrow date range.

Billing page

• Purpose & access. Protected, role-restricted to Business Owner / Practice Manager. Manages the Stripe subscription plan, payment method, and usage-based SMS/WhatsApp volume charges.
• Information/state. Current plan and price; renewal date; payment method; SMS/WhatsApp usage this period and projected overage; invoice history.
• Primary actions. Choose or change plan; update payment method (Stripe); view and download invoices; cancel or resume subscription.
• Supporting actions. View usage detail; open Stripe customer portal.
• Domain entities. Subscription, plan, payment method, usage record, invoice.
• Component responsibilities. Plan summary; Stripe checkout/portal launch; usage meter; invoice table.
• States. Loading: summary skeleton. Empty: "No active subscription — choose a plan" with link to Pricing page. Success: plan and usage shown; Stripe redirect confirmation. Error: payment failure or portal failure with retry. Recovery: retry; update payment method.

User settings

• Purpose & access. Protected, role-restricted to Business Owner / Practice Manager. Manages account settings, authentication method, and optional deposit/payment-detail collection settings.
• Information/state. Business profile (name, niche, contact); account email; linked authentication method (Google and/or email); theme preference; deposit/payment-detail collection toggle and configuration.
• Primary actions. Save profile; link or unlink Google Login; change password; enable/disable deposit collection; save deposit settings.
• Supporting actions. Theme toggle; sign out.
• Domain entities. Business profile, user account, authentication link, deposit setting.
• Component responsibilities. Profile form; auth-method panel; deposit settings panel with clear optional labeling; save bar.
• States. Loading: form skeleton. Empty: defaults for a new account. Success: saved confirmation. Error: validation or save failure inline. Recovery: retry; unsaved changes preserved.

Admin dashboard

• Purpose & access. Protected, role-restricted to Platform Administrator. Platform-level oversight of subscribing businesses, subscription status, and platform activity and errors.
• Information/state. List of subscribing businesses with plan and subscription status; platform activity feed; error log summary; aggregate usage.
• Primary actions. Search and filter businesses; open a business record; review errors.
• Supporting actions. Change date range; refresh.
• Domain entities. Tenant business, subscription, platform event, error record.
• Component responsibilities. Business table; status badges; activity and error panels.
• States. Loading: table skeleton. Empty: no businesses yet. Success: populated oversight view. Error: panel-level error with retry. Recovery: retry; narrow filters.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts and observable acceptance.

FR-1 — Connect existing calendar or booking system (explicit) As a Business Owner / Practice Manager I should connect my existing calendar or booking system (e.g. Google Calendar) so that appointments flow into the product automatically.

• Trigger/input: owner selects "Connect Google Calendar" on Integrations and completes provider OAuth.
• Observable result: connection shows connected status with last-sync time; appointments appear in Dashboard.
• Access: protected, role-restricted to owner.
• Failure/recovery: OAuth or sync failure shows an inline error with retry and reconnect.
• Continuation: owner proceeds to configure reminders.

FR-2 — Automated confirmations and reminders via SMS, WhatsApp or email (explicit) As a Business Owner / Practice Manager I should configure automated appointment confirmations and reminders sent through SMS, WhatsApp or email so that customers are reminded without manual chasing.

• Trigger/input: owner selects channels and reminder timing on Integrations and saves; system dispatches on schedule.
• Observable result: saved schedule confirmation; test message delivery status; dispatch counts visible in Analytics.
• Access: protected, role-restricted to owner.
• Failure/recovery: template validation or dispatch failure surfaces an error with retry.
• Continuation: customers receive messages containing the one-tap link.

FR-3 — Customizable message templates (explicit, feature reference) As a Business Owner / Practice Manager I should customize message templates so that reminders match my business voice.

• Trigger/input: owner edits a template on Integrations and saves.
• Observable result: saved template used for subsequent dispatches; confirmation shown.
• Failure/recovery: validation error inline; unsaved edits preserved.
• Continuation: test message verifies the template.

FR-4 — One-tap confirm, reschedule or cancel (explicit) As an Appointment Customer I should confirm, reschedule or cancel my appointment with one tap from the message link so that I can respond without calling.

• Trigger/input: customer opens the one-tap link to Appointment Response and taps Confirm, Reschedule or Cancel.
• Observable result: the response is recorded and confirmed on screen; the business sees the updated appointment state.
• Access: public, account-free, token-validated.
• Failure/recovery: invalid/expired link shows business contact; failed action offers retry with original state preserved.
• Continuation: customer closes the page; business sees the outcome.

FR-5 — Immediate cancellation alert to the business (explicit) As a Front-Desk Staff / Appointment Coordinator I should be alerted immediately when a cancellation occurs so that I can refill the slot.

• Trigger/input: a customer cancels via Appointment Response (or the calendar reports a cancellation).
• Observable result: a new alert appears at the top of Cancellations with customer, time and service.
• Access: protected, role-restricted to staff and owner.
• Failure/recovery: if the feed fails to load, an error with retry is shown.
• Continuation: staff opens the alert to act.

FR-6 — Message a waitlisted customer to fill the slot (optional waitlist) (explicit) As a Front-Desk Staff / Appointment Coordinator I should message a waitlisted customer to fill the emptied slot so that recovered time becomes revenue.

• Trigger/input: staff selects a waitlist candidate on Cancellations and sends a fill-slot message.
• Observable result: message delivery status shown; slot marked offered, then filled when the customer accepts.
• Access: protected, role-restricted to staff and owner.
• Failure/recovery: send failure shows retry with draft preserved; staff may choose another candidate.
• Continuation: slot filled or closed.

FR-7 — Manage the optional waitlist (explicit) As a Business Owner / Practice Manager I should maintain an optional waitlist of customers available to fill emptied slots so that recovery has candidates.

• Trigger/input: owner adds, edits or removes entries on Waitlist, or enables/disables the waitlist.
• Observable result: entries listed with status; waitlist availability reflected on Cancellations.
• Failure/recovery: validation or save failure inline with retry.
• Continuation: candidates become selectable on Cancellations.

FR-8 — Optional deposits or stored payment details (explicit) As a Business Owner / Practice Manager I should optionally collect deposits or store payment details so that no-shows are discouraged.

• Trigger/input: owner enables deposit collection and configures it on User settings.
• Observable result: setting saved and reflected in the appointment flow.
• Failure/recovery: save failure inline with retry.
• Continuation: owner may disable at any time.

FR-9 — Simple no-show dashboard (explicit) As a Business Owner / Practice Manager I should see a simple no-show dashboard summarizing missed appointments and recovered slots so that I know whether revenue is being protected.

• Trigger/input: owner opens Dashboard.
• Observable result: revenue-protected figure, no-show count, recovered-slot count and recent activity.
• Failure/recovery: per-widget error with retry; disconnected-calendar banner links to Integrations.
• Continuation: owner drills into Cancellations or Analytics.

FR-10 — Analytics on no-shows and recovery performance (explicit) As a Business Owner / Practice Manager I should review analytics on no-shows and recovery performance so that I can judge the product's impact.

• Trigger/input: owner opens Analytics and selects a date range.
• Observable result: trend chart, channel breakdown, recovered revenue.
• Failure/recovery: chart error with retry; narrower range as fallback.
• Continuation: owner adjusts reminder configuration based on findings.

FR-11 — Stripe subscription at $29–$99/month with volume charges (explicit) As a Business Owner / Practice Manager I should subscribe through Stripe at a $29–$99/month tier with additional charges for high SMS/WhatsApp volume so that billing matches my usage.

• Trigger/input: owner chooses a plan on Pricing page or Billing page and completes Stripe checkout.
• Observable result: active subscription shown on Billing page with renewal date and usage meter.
• Failure/recovery: payment failure shows retry and payment-method update.
• Continuation: owner manages plan and invoices.

FR-12 — Pricing page presenting tiers (explicit) As a prospective Business Owner / Practice Manager I should see subscription tiers on the Pricing page so that I can choose a plan.

• Trigger/input: visitor opens Pricing page.
• Observable result: tier cards with prices and volume-charge explanation.
• Failure/recovery: inline error with retry; CTA disabled until plans load.
• Continuation: visitor selects a plan and proceeds to Login.

FR-13 — User authentication with Google Login and Email Login (explicit) As a Business Owner / Practice Manager, Front-Desk Staff / Appointment Coordinator or Platform Administrator I should sign in with Google Login or Email Login so that I reach my protected surfaces.

• Trigger/input: user opens Login and chooses Google or email; new users enroll self-service.
• Observable result: authenticated session; redirect to Dashboard (business users) or Admin dashboard (platform administrators).
• Failure/recovery: invalid credentials or provider failure show inline error with retry.
• Continuation: user proceeds to protected work.

FR-14 — User settings (explicit) As a Business Owner / Practice Manager I should manage account settings and authentication method so that my account stays accurate and secure.

• Trigger/input: owner edits profile, links/unlinks Google Login, changes password on User settings.
• Observable result: saved confirmation; auth method reflected.
• Failure/recovery: validation or save failure inline with retry.
• Continuation: owner returns to Dashboard.

FR-15 — Billing page (explicit) As a Business Owner / Practice Manager I should manage my subscription, payment method and usage charges on the Billing page so that billing stays current.

• Trigger/input: owner opens Billing page and changes plan, updates payment method, or downloads invoices.
• Observable result: updated plan and usage shown; Stripe portal confirmation.
• Failure/recovery: portal or payment failure with retry.
• Continuation: owner returns to Dashboard.

FR-16 — Admin dashboard for platform oversight (explicit) As a Platform Administrator I should oversee subscribing businesses, subscription status, and platform activity and errors so that the service stays healthy.

• Trigger/input: administrator signs in via Login and opens Admin dashboard.
• Observable result: business list with plan/status, activity feed, error summary.
• Failure/recovery: panel error with retry.
• Continuation: administrator reviews a business record or errors.

FR-17 — Responsive design and dark mode (explicit) As any user I should use the product on mobile and desktop with a dark mode so that it fits my working context.

• Observable result: layouts reflow at 375px, 768px and 1280px; theme toggle persists preference; readable text and controls stay whole.
• Failure/recovery: theme preference falls back to light if unavailable.

FR-18 — SEO for public pages (explicit) As a prospective customer I should find the product through search so that I can evaluate it.

• Observable result: Landing page and Pricing page carry titles, descriptions, canonical URLs and structured metadata.

FR-19 — Error handling and loading states (explicit) As any user I should see clear loading and error states so that I always know what is happening and can recover.

• Observable result: every data surface has loading, empty, success, error and recovery states as specified in Section 2c.

FR-20 — Database, REST APIs, deployment configuration, environment variables, README and sample data (explicit) As the delivery team I should ship a database schema, REST APIs, deployment configuration, environment variables, README and sample data so that the product is production-ready.

• Observable result: documented schema, versioned REST endpoints, docker-compose deployment, .env template, README, and seeded sample data.

FR-21 — Self-service enrollment and returning verification (required_inference) As a Business Owner / Practice Manager I should enroll or sign in before reaching protected business surfaces so that my business data stays private.

• Trigger/input: visitor selects "Start free for 14 days" or "Sign in" and completes Login.
• Observable result: authenticated session bound to the correct business.
• Failure/recovery: enrollment conflict or credential error with recovery path.
• Continuation: redirect to Dashboard.

FR-22 — Platform administrator authorization (required_inference) As a Platform Administrator I should be authorized for the Admin dashboard after signing in through the shared Login surface so that platform oversight is restricted.

• Observable result: Admin dashboard accessible only to the administrator role; business users are redirected to Dashboard.

FR-23 — Calendar connection prerequisite (required_inference) As a Business Owner / Practice Manager I should connect a calendar before automated reminders can run so that reminders reference real appointments.

• Observable result: reminder dispatch is gated on a connected calendar; Dashboard shows a connect prompt until connected.

FR-24 — Plan selection prerequisite (required_inference) As a Business Owner / Practice Manager I should select a Stripe plan before billing and usage charges apply so that the subscription is valid.

• Observable result: Billing page shows "No active subscription" until a plan is chosen.

FR-25 — One-tap link entry (required_inference) As an Appointment Customer I should reach Appointment Response through the one-tap link in my message so that I can respond without an account.

• Observable result: token-validated page loads the correct appointment.

4. User Personas

Business Owner / Practice Manager

Runs a physiotherapy clinic, dental clinic, salon, tutoring or coaching practice and is personally accountable for revenue lost to no-shows. Their context is a small team, an existing calendar or booking system, and customers who book by phone, WhatsApp or a basic scheduling app. Their primary goal is fewer unfilled slots and higher monthly revenue without adding administrative work.

Distinct responsibilities: connecting the existing calendar or booking system (FR-1); configuring automated confirmations and reminders across SMS, WhatsApp or email and customizing templates (FR-2, FR-3); reviewing the no-show dashboard and analytics (FR-9, FR-10); managing the optional waitlist (FR-7); enabling optional deposits or stored payment details (FR-8); owning the Stripe subscription, billing page and user settings (FR-11, FR-14, FR-15); and enrolling or signing in before protected work (FR-13, FR-21, FR-23, FR-24).

Inputs and decisions: which calendar to connect, which channels and timing to use, whether to enable the waitlist and deposits, which plan to buy, and how to interpret recovery performance. Interactions: hands day-to-day cancellation response to Front-Desk Staff, receives cancellation alerts alongside them, and relies on Appointment Customers responding through one-tap links. Observable success: a dashboard showing recovered slots and protected revenue, and analytics showing a lower no-show rate.

Front-Desk Staff / Appointment Coordinator

Handles day-to-day schedule recovery inside the business. Their context is a busy front desk where cancellations arrive unpredictably and every open slot is lost income. Their primary goal is that every cancelled slot is refilled or rescheduled quickly without manual chasing.

Distinct responsibilities: monitoring immediate cancellation alerts on Cancellations (FR-5); selecting waitlisted customers and sending fill-slot messages (FR-6); observing customer responses recorded through Appointment Response (FR-4); and marking slots filled or closed. Inputs and decisions: which candidate to offer a slot to, which channel to use, and when to close a slot. Interactions: works alongside the Business Owner (who maintains the waitlist and configuration) and depends on Appointment Customers accepting offers. Observable success: alerts acknowledged promptly and slots moved from open to filled.

Platform Administrator

Operates the SaaS itself rather than a customer business. Their context is platform health across many subscribing businesses. Their primary goal is that the service stays healthy for all tenants.

Distinct responsibilities: signing in through the shared Login surface and being authorized for the Admin dashboard (FR-13, FR-22); overseeing subscribing businesses and their subscription status; monitoring platform activity and errors (FR-16). Inputs and decisions: which business to inspect, which errors to prioritize. Interactions: observes business subscriptions created through Stripe (FR-11) and platform events generated by reminder and alert automation. Observable success: a clear oversight view with no unresolved platform errors.

5. Core User Flows

Flow A — Owner enrolls and connects the calendar (Business Owner / Practice Manager)

1. Visitor lands on Landing page and selects "Start free for 14 days".
2. Login opens in enrollment mode; owner chooses Google Login or enters email and password.
3. On success the owner is redirected to Dashboard, which shows a connect-calendar prompt because no calendar is linked (FR-23).
4. Owner opens Integrations and selects "Connect Google Calendar", completing provider OAuth.
5. Integrations shows connected status with last-sync time; appointments appear on Dashboard.
6. Failure path: if OAuth fails, an inline error offers retry and reconnect; the owner remains on Integrations.
7. Continuation: owner configures reminders.

Flow B — Owner configures reminders and templates (Business Owner / Practice Manager)

1. On Integrations the owner selects channels (SMS, WhatsApp, email) and reminder timing, then saves.
2. Owner edits a message template and saves; validation errors appear inline with unsaved edits preserved.
3. Owner sends a test message and sees delivery status.
4. Continuation: automated confirmations and reminders dispatch on schedule to customers, each containing the one-tap link.

Flow C — Customer responds with one tap (Appointment Customer)

1. Customer receives a confirmation or reminder and opens the one-tap link.
2. Appointment Response loads the appointment details via the token.
3. Customer taps Confirm, Reschedule (choosing a new time) or Cancel.
4. The response is recorded and confirmed on screen; the business sees the updated appointment state.
5. Failure path: an expired link shows business contact details; a failed action offers retry with the original state preserved.

Flow D — Staff recovers a cancelled slot (Front-Desk Staff / Appointment Coordinator)

1. A customer cancels via Appointment Response; the calendar reflects the cancellation.
2. A new alert appears at the top of Cancellations with customer, time and service (FR-5).
3. Staff opens the alert and reviews waitlist candidates matched to the slot.
4. Staff selects a candidate and sends a fill-slot message; delivery status is shown.
5. When the customer accepts, staff marks the slot filled; otherwise staff offers another candidate or closes the slot.
6. Failure path: a send failure shows retry with the draft preserved.

Flow E — Owner manages the optional waitlist (Business Owner / Practice Manager)

1. Owner opens Waitlist and enables it (or leaves it disabled).
2. Owner adds entries with contact channel and preferred time window; validation errors appear inline.
3. Entries are listed with status and become selectable on Cancellations.
4. Continuation: staff can offer slots to these candidates.

Flow F — Owner reviews the no-show dashboard and analytics (Business Owner / Practice Manager)

1. Owner opens Dashboard and sees the revenue-protected figure, no-show count, recovered slots and recent activity.
2. Owner drills into Analytics, selects a date range and reviews no-show rate, channel breakdown and recovered revenue.
3. Failure path: a widget or chart error offers retry; a disconnected calendar banner links to Integrations.
4. Continuation: owner adjusts reminder configuration on Integrations.

Flow G — Owner subscribes and manages billing (Business Owner / Practice Manager)

1. Owner opens Pricing page (or Billing page) and selects a $29–$99/month tier.
2. If unauthenticated, Login intervenes; after sign-in the owner returns to checkout.
3. Stripe checkout completes; Billing page shows the active plan, renewal date, payment method and usage meter for SMS/WhatsApp volume.
4. Owner may change plan, update payment method, download invoices, or cancel/resume.
5. Failure path: payment failure shows retry and payment-method update; Billing shows "No active subscription" until resolved (FR-24).

Flow H — Owner manages settings and deposits (Business Owner / Practice Manager)

1. Owner opens User settings and updates business profile.
2. Owner links or unlinks Google Login or changes password.
3. Owner optionally enables deposit collection or stored payment details and saves.
4. Saved confirmation appears; changes take effect in the appointment flow.

Flow I — Administrator oversees the platform (Platform Administrator)

1. Administrator opens Login and signs in with Google Login or Email Login.
2. Authorization routes the administrator to Admin dashboard (FR-22); business users would be routed to Dashboard instead.
3. Administrator reviews subscribing businesses with plan and subscription status, the platform activity feed and the error summary.
4. Administrator opens a business record or prioritizes errors.
5. Failure path: a panel error offers retry; filters can be narrowed.

6. Visuals Colors and Theme

Muse and headline. Haraldur Thorleifsson — big-hearted boldness for the empty chair. The visual language turns revenue protection into something warm, human and glad to open each morning, without abandoning modern SaaS clarity.

Colour tokens (light mode).

• Background / page ground: #FFF6E9 (cream)
• Surface (cards, tables, forms): #FFFFFF
• Text: #1B1B2F (ink)
• Primary / action: #FF5A36 (coral) — primary buttons, recovered-slot highlight, the one number that matters; ≤ ~10% of any view
• Accent / secondary signal: #1FB6A6 (teal) — confirmed appointments, recovered revenue
• Muted / metadata: #6E6A63
• Illustration fills: sunflower #FFC24B, soft lilac #C9B8FF

Colour tokens (dark mode). Ground #14131C, surfaces #1F1E2A, text #FFF6E9; coral #FF5A36 and teal #1FB6A6 remain identical so the brand survives the theme switch.

Typography.

• Headings: Sora 600–700, tracking −0.02em, short line lengths, sentence case, never all-caps.
• Body: Outfit.
• Scale: 1.25 modular — 40/32/24/20/17/15 body; display ramp clamp(2.5rem, 7vw, 6.5rem) for the hero, clamp(2rem, 4.5vw, 3.5rem) for section openers, 28px card titles, 15px table text.
• Numbers in stats and dashboard use Sora 700 with tabular figures.

Shape language. Chunky rounded rectangles (20–28px radii); signature 4px ink outline on illustrated cards with a hard 6px offset shadow in coral or teal (no blur); full-bleed colour blocks with straight edges; pill buttons, pill toggles, pill badges; illustration characters built from the same rounded vocabulary.

Layout. Colour-blocked horizontal bands: cream hero → coral full-bleed proof band → white feature band → teal waitlist band → pricing on cream. 12-column grid, 24px gutter, hard 8pt spacing scale. Landing uses asymmetry (7/5 splits, illustrations bleeding off the right edge); the app shell is a strict left rail plus content column. Mobile collapses every band to a single column with illustrations below the copy, never behind it.

Imagery. Custom flat vector characters and spot illustrations in coral, teal, sunflower and lilac on cream: a phone with a one-tap confirm bubble, an empty salon chair with a waitlisted customer sliding into it, a calendar with a slot snapping shut, a smiling physiotherapist. Bold iconography on the same rounded grid; colour-blocked UI mockups of the reminder message and dashboard. No stock photography, no gradient blobs.

Accessibility. Readable text and controls stay whole at 375px, 768px and 1280px; imagery may bleed or overlap but never covers readable text or controls. Contrast meets WCAG AA for body and control text.

7. Signature Design Concept

"The 2pm that never showed just got filled." The public entry is a warm cream full-bleed hero split 7/5, not centred. On the left, an oversized Sora headline at clamp(2.5rem, 7vw, 6.5rem) stacks over three lines, with the word "filled" sitting on a solid coral colour block that runs to the column edge. Beneath it a 15px ink subline and two pill CTAs — solid coral "Start free for 14 days" and outlined ink "See a 90-second demo". On the right, a large flat-illustration composition: a phone showing a one-tap confirm message, a coral "Recovered" chip, and a waitlisted customer character sliding into an empty chair, bleeding off the right and bottom edges. A thin coral ticker strip pinned to the bottom of the hero scrolls live recovery events ("2:15pm — Priya confirmed · 3:40pm — slot filled · 4:10pm — waitlist offered") as a marquee that pauses on hover and wraps into static rows under reduced motion. The concept recomposes only accepted content — the one-tap response, cancellation recovery and waitlist offer — and introduces no new behaviour.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject. The flat-illustration composition of a phone with a one-tap confirm bubble, a coral "Recovered" chip, and a waitlisted customer character sliding into an empty chair.
• Input → transformation → outcome thesis. As the visitor arrives, the recovery ticker begins scrolling real slot events; when a recovered-slot counter ticks up, the character illustration blinks or waves once and the coral "Recovered" chip pops — showing that an empty chair becomes a filled appointment.
• Motion vocabulary. Entrance animations of 400–600ms with gentle overshoot on cards and characters; a coral underline that draws in under section headings; hover pops of 1.04 scale on interactive cards; no parallax, no drifting gradients.
• Composed first frame. Cream hero, headline with "filled" on the coral block, subline and two pill CTAs, illustration bleeding off right and bottom, coral ticker strip pinned at the bottom.
• Reduced-motion state. All motion renders the final state immediately; the ticker becomes a static wrapped list of events, each fully readable.

9. Non-Functional Requirements

• NFR-1 — Production readiness (explicit). Everything ships production-ready: real persistence, error handling, loading states, environment configuration and deployment.
• NFR-2 — Responsive design (explicit). Usable at 375px, 768px and 1280px; readable text and controls stay whole and inside their containers.
• NFR-3 — Dark mode (explicit). Theme toggle across public and protected surfaces; preference persists; brand colours survive the switch.
• NFR-4 — SEO (explicit). Landing page and Pricing page carry titles, meta descriptions, canonical URLs and structured metadata; protected pages are excluded from indexing.
• NFR-5 — Error handling and loading states (explicit). Every data surface defines loading, empty, success, error and recovery states (Section 2c).
• NFR-6 — Security and privacy (required_inference). Protected surfaces require an authenticated session; one-tap links are token-validated and scoped to a single appointment; platform administration is role-restricted.
• NFR-7 — Mobile access (feature reference). The product is accessible on mobile devices, consistent with the responsive requirement.
• NFR-8 — Delivery reliability (required_inference). Reminder dispatch, cancellation alerting and waitlist messaging run as background automation with observable delivery status and retry on failure.
• NFR-9 — Pricing constraint (explicit). Subscription tiers sit within $29–$99/month, with additional charges for high SMS/WhatsApp volume.
• NFR-10 — Niche focus (explicit). The product targets one niche first — preferably physiotherapy clinics, dental clinics or salons.

10. Tech Stack

• Frontend. React web application with responsive layouts, dark mode, SEO metadata for public pages, and loading/error states throughout.
• Backend. Python/FastAPI service exposing REST APIs for authentication, calendar connections, reminders, appointment responses, cancellations, waitlist, analytics, billing and administration.
• Database. Relational database (PostgreSQL) with a documented schema covering businesses, users, calendar connections, appointments, reminder rules, message templates, responses, cancellation alerts, waitlist entries, subscriptions, usage records and platform events; seeded sample data.
• Background automation. Scheduled worker within the backend process for calendar sync, reminder dispatch, cancellation alerting and waitlist messaging.
• External services. Google Calendar (OAuth), SMS/WhatsApp/email delivery providers, Stripe subscriptions and customer portal.
• Deployment. Docker and docker-compose for the frontend, backend and database; environment variables documented in a .env template; README covering setup, schema, APIs and sample data.
• Validation note. The product may initially be validated manually using n8n before the full software is relied upon.

11. Assumptions and Constraints

Constraints (explicit).

• Target one niche first — preferably physiotherapy clinics, dental clinics or salons.
• Price at $29–$99/month, with additional charges for high SMS/WhatsApp volume.
• Business model is a recurring SaaS subscription.
• AI-based no-show risk scoring, smart reminder timing, personalized messages and automatic waitlist offers are later-phase features, not part of the MVP.
• MVP scope is calendar integration, automated reminders, one-tap confirm/reschedule/cancel links, cancellation alerts, a simple no-show dashboard and an optional waitlist.
• The product may initially be validated manually using n8n before full software is built.
• Everything should be production-ready.

Future requirements (excluded from current pages and acceptance).

• AI-based no-show risk scoring.
• Smart reminder timing.
• Personalized messages.
• Automatic waitlist offers.

Assumptions (narrow, labeled).

• Google Calendar is the first calendar integration; other booking systems follow the same connection pattern.
• SMS, WhatsApp and email are delivered through third-party providers configured via environment variables.
• Stripe is the sole billing provider.
• The optional waitlist and optional deposit/payment-detail collection are off until the owner enables them.
• Sample data is seeded for demonstration and does not represent real customers.

12. Glossary

• No-show — an appointment the customer neither attended nor cancelled in advance.
• Recovered slot — a cancelled or missed appointment time that is refilled or rescheduled.
• One-tap link — a tokenized link in a confirmation or reminder message that opens Appointment Response without an account.
• Appointment Response — the public page where a customer confirms, reschedules or cancels.
• Cancellation alert — the immediate notification to the business when a cancellation occurs.
• Waitlist — the optional list of customers available to fill emptied slots.
• Reminder rule — the configured timing and channel for automated confirmations and reminders.
• Message template — the customizable text used for confirmations, reminders and fill-slot messages.
• Revenue protected — the dashboard figure representing value retained by recovered slots.
• Tenant business — a subscribing business account on the platform.
• Platform Administrator — the role that operates the SaaS and oversees tenants via the Admin dashboard.